JP2021511578A - 認可取り消しの方法および装置 - Google Patents

Abstract

本願は、認可取り消し方法および装置を開示し、通信分野に関する。本方法は、第1のエンティティによって、第2のエンティティから認可取り消し要求メッセージを受信する段階であって、認可取り消し要求メッセージはAPI呼び出しエンティティの識別子を担持する、段階と；第1のエンティティによって、認可取り消し要求メッセージに基づいて、認可取り消し応答メッセージを第2のエンティティに送信する段階とを含む。この方法では、API呼び出し認可管理が改善され、API呼び出し認可が適時に取り消されることができ、それにより、すでにAPI呼び出し認可をもっていないAPI呼び出しエンティティがAPIを呼び出すことによって引き起こされる資源の浪費を回避する。たとえば、API呼び出しエンティティがもとの認証でAPIを呼び出し、AEFが該API呼び出しのためにサービス論理を実行するが、該API呼び出しは最終的には失敗する。結果として、AEFの処理資源が浪費される。さらに、AEFは、すでにAPI呼び出し認可をもっていないAPI呼び出しエンティティのAPI呼び出しのためのサービス論理を実行することを防止され、それにより、CAPIFシステムの作業効率が改善される。

Description

本願は、通信技術の分野に関し、特に、認可取り消し方式および装置に関する。

共通APIフレームワーク（Common API Framework、CAPIF）システムでは、アプリケーション・プログラミング・インターフェース（Application Programming Interface、API）呼び出しエンティティは、CAPIFシステム内の共通APIフレームワーク・コア機能（CAPIF Core Function、CCF）からAPI呼び出し認可を取得し、次いで、API呼び出しエンティティは、該認可を用いてAPI呼び出しを1回または複数回実行することができる。

CAPIFには多くのAPI呼び出しエンティティおよびAPIがあり、CAPIFにおけるAPI露出機能（API exposing function、AEF）上に種々のAPIが位置されうる。そのため、API呼び出し認可管理は比較的複雑である。たとえば、認可が期限切れになることもあり、あるいは無効にされることもある。しかし、従来技術では、API呼び出しエンティティの認可プロセスのみが提供されている。よって、さらなる改善が要求される。

本願の実施形態は、API呼び出し認可管理が改善でき、CAPIFシステムの効率が改善されるように、認可取り消し方法を提供する。

前述の目的を達成するために、本願の実施形態において以下の技術的解決策が使用される。

第1の側面によれば、認可取り消し方法が提供される。本方法は：第1のエンティティによって、第2のエンティティからの認可取り消し要求メッセージを受信する段階であって、前記認可取り消し要求メッセージがAPI呼び出しエンティティの識別子を担持する、段階と；前記認可取り消し要求メッセージに基づいて、第1のエンティティによって、認可取り消し応答メッセージを第2のエンティティに送信する段階とを含む。本方法では、API呼び出し認可管理が改善され、API呼び出し認可を適時に取り消すことができるようにする。それにより、すでにAPI呼び出し認可をもたなくなっているAPI呼び出しエンティティ（すなわち、該API呼び出しエンティティのAPI呼び出し認可は無効化されたか、または期限切れになっている）によるAPIの呼び出しによって引き起こされる資源の無駄を回避する。たとえば、API呼び出しエンティティは元の認可を用いてAPIを呼び出し、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的には失敗する。結果として、AEFの処理資源が浪費される。さらに、AEFは、すでにAPI呼び出し認可をもっていないAPI呼び出しエンティティのAPI呼び出しのためのサービス論理を実行することを防がれ、それによりCAPIFシステムの作業効率が改善される。

第1の側面を参照し、第1の側面の第1の可能な実装において、本方法は、認可取り消し要求メッセージがさらにAPI識別子を担持するとき、API呼び出しエンティティによって前記API識別子に対応するAPIを呼び出す認可を第1のエンティティによって取り消すこと；または、認可取り消し要求メッセージがさらにAPI識別子およびAEF識別子を担持するとき、API呼び出しエンティティによって、AEF識別子に対応するAEF上の、API識別子に対応するAPIを呼び出す認可を第1のエンティティによって取り消すことをさらに含む。認可取り消し要求メッセージは、API呼び出しエンティティのAPI呼び出し認可を柔軟に取り消すために使用されてもよい。

第1の側面を参照し、第1の側面の第2の可能な実装において、認可取り消し要求メッセージはAPI識別子を担持せず、本方法はさらに：API呼び出しエンティティによって、API呼び出しエンティティに対応する共通APIフレームワーク・コア機能CCF上のすべてのAPIを呼び出す認可を第1のエンティティによって取り消すこと；または、認可取り消し要求メッセージがさらにAEF識別子を担持するとき、API呼び出しエンティティによって、AEF識別子に対応するAEF上のすべてのAPIを呼び出す認可を第1のエンティティによって取り消すこと；または、認可取り消し要求メッセージがさらに特定の値を担持するとき、API呼び出しエンティティによって、API呼び出しエンティティに対応するCCF上のすべてのAPIを呼び出す認可を第1のエンティティによって取り消すことを含む。認可取り消し要求メッセージは、異なるスケールで認可を柔軟に取り消すために使用されてもよく、たとえば、CCF上のすべてのAPIを呼び出す認可を取り消すために使用されてもよく、あるいは、AEF上のすべてのAPIを呼び出す認可を取り消すために使用されてもよい。

第1の側面または前述の可能な実装のいずれかを参照し、第1の側面の第3の可能な実装において、本方法は、さらに：第1のエンティティによって、API呼び出しエンティティに認可取り消し指示メッセージを送信することを含む。このように、API呼び出しエンティティは、API呼び出しエンティティの認可情報を適時に知ることができ、それにより、次の二つの場合を避ける：API呼び出しエンティティによるAPIの呼び出しのための認可情報が無効にされた／取り消されたことをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出すため、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的に失敗し、結果として、AEFの処理資源が無駄になる。さらに、API呼び出しエンティティの認可が無効にされるまたは期限切れになることをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出そうと試みるため、API呼び出しエンティティの処理資源が無駄になる。

第1の側面または前述の可能な実装のいずれかを参照し、第1の側面の第4の可能な実装において、第1のエンティティはAEFであり、第2のエンティティはAPI呼び出しエンティティに対応するCCFである；または、第1のエンティティはAPI呼び出しエンティティに対応するCCFであり、第2のエンティティはAEFである。

第1の側面の第4の可能な実装を参照し、第1の側面の第5の可能な実装において、第1のエンティティはAPI呼び出しエンティティに対応するCCFであり、第2のエンティティはAEFであり、API呼び出しエンティティによってAPI呼び出しエンティティに対応するCCF上のすべてのAPIを呼び出す認可を第1のエンティティによって取り消した後、この方法はさらに：第1のエンティティによって、認可取り消し通知メッセージを、CCFに対応するAEFに送信することを含む。ここで、認可取り消し通知メッセージは、API呼び出しエンティティの識別子を担持する。このようにして、AEFは、API呼び出しエンティティの認可情報を適時に知ることができ、それにより、次の場合を避けることができる：API呼び出しエンティティがもとの認可を用いてAPIを呼び出したときでも、AEFは依然としてAPI呼び出しのためのサービス論理を実行し、結果として、AEFの処理資源が浪費される。

第2の側面によれば、認可取り消し方法が提供される。本方法は：第2のエンティティによって、認可取り消し要求メッセージを第1のエンティティに送信する段階であって、前記認可取り消し要求メッセージはAPI呼び出しエンティティの識別子を担持する、段階と；第2のエンティティによって、第1のエンティティからの認可取り消し応答メッセージを受信する段階であって、前記認可取り消し応答メッセージは、認可取り消しが成功または失敗することを示すために使用される、段階とを含む。本方法では、API呼び出し認可管理が改善され、API呼び出し認可を適時に取り消すことができるようにする。それにより、API呼び出し認可をすでにもっていないAPI呼び出しエンティティ（すなわち、該API呼び出しエンティティの認可が無効化されたか、または期限切れになっている）によってAPIを呼び出すことによって引き起こされる資源の無駄を回避する。たとえば、API呼び出しエンティティがもとの認可を用いてAPIを起動し、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的には失敗する。結果として、AEFの処理資源が浪費される。さらに、AEFは、API呼び出し認可をすでにもっていないAPI呼び出しエンティティのAPI呼び出しのためのサービス論理を実行することを防がれ、それによりCAPIFシステムの作業効率が改善される。

第2の側面を参照して、第2の側面の第1の可能な実装において、第2のエンティティによって第1のエンティティに認可取り消し要求メッセージを送信することは：第2のエンティティによって、API呼び出しエンティティの認可取り消し関連情報に基づいて、認可取り消し要求メッセージを第1のエンティティに送信することを含む。API呼び出しエンティティのための認可取り消しを実装するために、API呼び出しエンティティの状態がリアルタイムで監視される。

第2の側面の第1の可能な実装を参照し、第2の側面の第2の可能な実装において、認可取り消し関連情報は、API呼び出し失敗の回数を含み、第2のエンティティによって、API呼び出しエンティティの認可取り消し関連情報に基づいて、認可取り消し要求メッセージを第1のエンティティに送信することは、API呼び出し失敗の回数が閾値を超えるとき、認可取り消し要求メッセージを第1のエンティティに送信することを含む。第2の側面または第2の側面の前述の可能な実装のいずれかを参照し、第2の側面の第3の可能な実装において、第1のエンティティはAEFであり、第2のエンティティはCCFであるか、または、第1のエンティティはCCFであり、第2のエンティティはAEFである。

第2の側面の第3の可能な実装を参照し、第2の側面の第4の可能な実装では、第2のエンティティはAEFであり、第1のエンティティはCCFであり、本方法はさらに：第2のエンティティによって、API呼び出しエンティティからのAPI呼び出し要求メッセージを受信する段階と；API呼び出しエンティティが、そのAPI呼び出し要求メッセージが呼び出すことを要求するために使われているAPIを呼び出す認可をもたないとき、第2のエンティティによってAPI呼び出し拒否メッセージをAPI呼び出しエンティティに送信する段階とを含む。AEFは、認可をもたないAPI呼び出しエンティティによって送信されたAPI呼び出し要求メッセージを拒否し、それにより、API呼び出しの処理効率を改善し、AEFの処理資源を節約する。

第2の側面の第3の可能な実装を参照し、第2の側面の第5の可能な実装において、本方法は、さらに：第2のエンティティによって、認可取り消し指示メッセージをAPI呼び出しエンティティに送信することを含む。このように、API呼び出しエンティティは、API呼び出しエンティティの認可情報を適時に知ることができ、それにより、次の二つの場合を回避する：API呼び出しエンティティによるAPIの呼び出しのための認可情報が無効にされた／取り消されたことをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出すため、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的に失敗し、結果として、AEFの処理資源が無駄になる。さらに、API呼び出しエンティティの認可が無効にされるまたは期限切れになることをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出そうと試みるため、API呼び出しエンティティの処理資源が無駄になる。

第3の側面によれば、認可取り消し方法が提供される。本方法は：AEFによって、API呼び出しエンティティの認可取り消し関連情報を取得する段階と；API呼び出しエンティティの認可取り消し関連情報に基づいて、API呼び出しエンティティのAPI呼び出し認可を取り消す段階とを含む。API呼び出しエンティティのための認可取り消しを実装するために、API呼び出しエンティティの状態がリアルタイムで監視される。

第3の側面を参照し、第3の側面の第1の可能な実装において、本方法は、さらに、AEFによって、CCFに認可取り消し通知メッセージを送信することを含む。このようにして、CCFは、API呼び出しエンティティの認可情報を適時に知り、CCF上のAPI呼び出しエンティティの認可を更新することができ、それにより、API呼び出しエンティティはCCFとともに再度認可プロセスを実行できる。

第3の側面または第3の側面の第1の可能な実装を参照し、第3の側面の第2の可能な実装において、本方法は、さらに：AEFによって、認可取り消し指示メッセージをAPI呼び出しエンティティに送信することを含む。このようにして、API呼び出しエンティティは、API呼び出しエンティティの認可情報を適時に知ることができ、それにより、次の二つの場合を回避する：API呼び出しエンティティによるAPIの呼び出しのための認可情報が無効にされた／取り消されたことをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出すため、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的に失敗し、結果として、AEFの処理資源が無駄になる。さらに、API呼び出しエンティティの認可が無効にされるまたは期限切れになることをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出そうと試みるため、API呼び出しエンティティの処理資源が無駄になる。

第3の側面または第3の側面の前記可能な実装のいずれかを参照し、第3の側面の第3の可能な実装において、本方法は、さらに：API呼び出しエンティティによって、APIを呼び出す認可をCCFから取得することを含む。APIのセキュリティを確保するために、APIを呼び出す前に、API呼び出しエンティティは、APIを呼び出す認可をCCFから取得する。

第4の側面によれば、認可取り消し方法が提供される。本方法は：AEFによって、認可取り消し通知メッセージをCCFから受信し、AEFによって、認可取り消し通知メッセージに基づいて、API呼び出しエンティティのAPI呼び出し認可情報を更新することを含む。このようにして、AEFは、API呼び出しエンティティの認可情報を適時に知ることができ、それにより、次の場合を回避する：API呼び出しエンティティがもとの認可を用いてAPIを呼び出すときでも、AEFは依然としてAPI呼び出しのためのサービス論理を実行し、結果として、AEFの処理資源が浪費される。

第5の側面によれば、認可取り消し方法が提供される。本方法は、API呼び出しエンティティによって、第1のエンティティからの認可取り消し指示メッセージを受信する段階と；API呼び出しエンティティによって、認可取り消し指示メッセージに基づいて、API呼び出し認可情報を更新する段階とを含む。このようにして、API呼び出しエンティティは、API呼び出しエンティティの認可情報を適時に知ることができ、それにより、次の二つの場合を回避する：API呼び出しエンティティによるAPIの呼び出しのための認可情報が無効にされた／取り消されたことをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出すため、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的には失敗し、結果として、AEFの処理資源が無駄になる。さらに、API呼び出しエンティティの認可が無効にされるまたは期限切れになることをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出そうと試みるため、API呼び出しエンティティの処理資源が無駄になる。

第6の側面によれば、装置が提供される。本装置は、第1の側面の方法のステップを実行するように構成されたユニットまたは手段（means）を含む。本装置は、AEFまたはCCFのような第1のエンティティであってもよく、または少なくとも1つの処理要素、チップ、またはシステムオンチップであってもよい。

第7の側面によれば、装置が提供される。本装置は、第2の側面の方法のステップを実行するように構成されたユニットまたは手段（means）を含む。本装置は、AEFまたはCCFのような第2のエンティティであってもよく、または少なくとも1つの処理要素、チップ、またはシステムオンチップであってもよい。

第8の側面によれば、装置が提供される。本装置は、第3の側面の方法のステップを実行するように構成されたユニットまたは手段（means）を含む。本装置は、AEFであってもよく、または少なくとも1つの処理要素、チップ、またはシステムオンチップであってもよい。

第9の側面によれば、装置が提供される。本装置は、第4の側面の方法のステップを実行するように構成されたユニットまたは手段（means）を含む。本装置は、AMFのようなAEFであってもよく、または少なくとも1つの処理要素、チップ、またはシステムオンチップであってもよい。

第10の側面によれば、装置が提供される。本装置は、第5の側面または第5の側面の可能な設計における方法のステップを実行するように構成されたユニットまたは手段（means）を含む。本装置は、API呼び出しエンティティであってもよく、または少なくとも1つの処理要素、チップ、またはシステムオンチップであってもよい。

第11の側面によれば、装置が提供される。本装置は、プロセッサを含み、前記プロセッサは、メモリに結合され、前記メモリは、プログラムを記憶するように構成され、前記プロセッサは、前記メモリに記憶された前記プログラムを呼び出して、第1の側面の方法を実行する。本装置は、第1のエンティティであってもよく、または少なくとも1つの処理要素またはチップであってもよい。

第12の側面によれば、装置が提供される。本装置は、プロセッサを含み、前記プロセッサは、メモリに結合され、前記メモリは、プログラムを記憶するように構成され、前記プロセッサは、前記メモリに記憶された前記プログラムを呼び出して、第2の側面の方法を実行する。本装置は、第2のエンティティであってもよく、または少なくとも1つの処理要素、チップ、またはシステムオンチップであってもよい。

第13の側面によれば、装置が提供される。本装置は、プロセッサを含み、前記プロセッサは、メモリに結合され、前記メモリは、プログラムを記憶するように構成され、前記プロセッサは、前記メモリに記憶された前記プログラムを呼び出して、第3の側面の方法を実行する。本装置は、AEFであってもよく、または少なくとも1つの処理要素、チップ、またはシステムオンチップであってもよい。

第14の側面によれば、装置が提供される。本装置は、プロセッサを含み、前記プロセッサは、メモリに結合され、前記メモリは、プログラムを記憶するように構成され、前記プロセッサは、前記メモリに記憶された前記プログラムを呼び出して、第4の側面の方法を実行する。本装置は、AEFであってもよく、または少なくとも1つの処理要素、チップ、またはシステムオンチップであってもよい。

第15の側面によれば、装置が提供される。本装置は、プロセッサを含み、前記プロセッサは、メモリに結合され、前記メモリは、プログラムを記憶するように構成され、前記プロセッサは、前記メモリに記憶された前記プログラムを呼び出して、第5の側面の方法を実行する。本装置は、API呼び出しエンティティであってもよく、または少なくとも1つの処理要素、チップ、またはシステムオンチップであってもよい。

第16の側面によれば、プログラムが提供され、ここで、プロセッサによって実行されるとき、該プログラムは、第1の側面における任意の方法を実行するために使用される。

第17の側面によれば、コンピュータ可読記憶媒体が提供される。記憶媒体は、第16の側面のプログラムを含む。

第18の側面によれば、プログラムが提供され、ここで、プロセッサによって実行されるとき、該プログラムは、第2の側面における任意の方法を実行するために使用される。

第19の側面によれば、コンピュータ可読記憶媒体が提供される。記憶媒体は、第18の側面のプログラムを含む。

第20の側面によれば、プログラムが提供され、ここで、プロセッサによって実行されるとき、プログラムは、第3の側面における任意の方法を実行するために使用される。

第21の側面によれば、コンピュータ可読記憶媒体が提供される。記憶媒体は、第20の側面のプログラムを含む。

第22の側面によれば、プログラムが提供され、ここで、プロセッサによって実行されるとき、該プログラムは、第4の側面における任意の方法を実行するために使用される。

第23の側面によれば、コンピュータ可読記憶媒体が提供される。記憶媒体は、第22の側面のプログラムを含む。

第24の側面によれば、プログラムが提供される。ここで、プロセッサによって実行されるときに、該プログラムは、第5の側面における任意の方法を実行するために使用される。

第25の側面によれば、コンピュータ可読記憶媒体が提供される。記憶媒体は、第24の側面のプログラムを含む。

本願のある実施形態による共通APIフレームワークの概略図である。 本願のある実施形態による認可取り消し方法のフローチャートである。 本願のある実施形態による別の認可取り消し方法のフローチャートである。 本願のある実施形態による別の認可取り消し方法のフローチャートである。 本願のある実施形態による別の認可取り消し方法のフローチャートである。 本願のある実施形態による別の認可取り消し方法のフローチャートである。 本願のある実施形態による別の認可取り消し方法のフローチャートである。 本願のある実施形態による別の認可取り消し方法のフローチャートである。 本願のある実施形態による装置の概略構造図である; 本願のある実施形態による別の装置の概略構造図である; 本願のある実施形態による別の装置の概略構造図である; 本願のある実施形態による別の装置の概略構造図である; 本願のある実施形態による別の装置の概略構造図である。 本願のある実施形態による装置のハードウェアの概略構造図である。

本願に記載されるシステムアーキテクチャおよびサービスシナリオは、本願における技術的解決策をより明確に記述するために意図されており、本願において提供される技術的解決策を限定することは意図されていない。当業者は、システムアーキテクチャが進化し、新たなサービスシナリオが出現するにつれて、本願において提供される技術的解決策は、同様の技術的課題にも適用可能であることを知りうる。

図1は、CAPIFを示す。ネットワーク構造は、4Gまたは5G通信システムに適用されうる。明らかに、ネットワーク構造は、代替的に、別の規格の通信システムに適用されてもよい。制限は課されない。CAPIFにおける構成要素は、以下のように簡単に説明される。

API呼び出しエンティティ（API invoker）は、API呼び出し者とも呼ばれ、一般に、公衆陸上移動ネットワーク（public land mobile network、PLMN）事業者とのサービス契約に署名するサードパーティー・アプリケーション、たとえば、マシンツーマシン（machine to machine、M2M）アプリケーション、モノのインターネット（Internet of Things、IoT）アプリケーション、またはビークル対万物（vehicle-to-everything、V2X）アプリケーションである。これらのアプリケーションは、端末装置上で動作することもあれば、ネットワーク装置上で動作することもある。たとえば、API呼び出しエンティティは、PLMN内の装置であってもよく、たとえば、4G通信システムにおける移動管理エンティティ（mobility management entity、MME）、無線アクセスネットワーク（radio access network、RAN）ノード、またはポリシーおよび課金規則機能（policy and charging rules function、PCRF）であってもよく、または5G通信システムにおけるアクセスおよび移動管理機能（access and mobility management function、AMF）、セッション管理機能（session management function、SMF）、ユーザープレーン機能（User Plane Function、UPF）、ポリシー制御機能（policy control function、PCF）、またはアプリケーション機能（application function、AF）であってもよい。API呼び出しエンティティは、API呼び出しエンティティの識別子および／または他の情報の認証を通してAPI呼び出しエンティティの認証を実装すること、APIを呼び出す前にAPIを呼び出す認可を取得すること、APIを発見すること、APIを呼び出すことなどのために使用されうる。

CCFは：API呼び出しエンティティの識別子および他の情報に基づいてAPI呼び出しエンティティを認証すること、たとえば、API呼び出しエンティティが認可されているかどうかをチェックすること；API呼び出しエンティティとの相互認証をサポートすること；API呼び出しエンティティがAPIを呼び出す前にAPI呼び出しエンティティのためにAPI呼び出し認可情報を提供すること；API発見を公開し、保存し、サポートすること；PLMN事業者のポリシーに基づいてAPIアクセス制御を実行すること；API呼び出しログを保存し、および該ログを、該ログを取得することを認可された機能エンティティのために提供すること；API呼び出しログ（log）に基づいて課金を実行すること；API呼び出しを監視すること；API呼び出し者を登録すること；構成ポリシーを保存すること；呼び出しおよびログの監査をサポートすること、などを行なうために使用されうる。

AEFはAPIを提供してもよく、API呼び出しエンティティがAPIを呼び出すための入口として使用されてもよい。たとえば、AEFは、API呼び出しエンティティの識別子およびCCFによって提供された情報に基づいてAPI呼び出しエンティティを認証し、CCFによって提供された認証情報を受け取り、API呼び出しログをCCFに同期させる。

API公開機能（API publishing function、APF）は、API呼び出しエンティティがAPIを発見できるように、APIを公開する機能を提供するために使用される。

API管理機能（API management function、AMF）は、API管理を提供する、たとえば、CCFによって提供されるAPI呼び出しログを監査すること、CCFによって報告されるイベントを監視すること、CCFのためにアクセスおよび課金ポリシーを構成すること、API状態を監視すること、およびAPI呼び出しエンティティを登録することを行なうために使用される。

CAPIF APIは、CCFによって提供されるAPIであり、API呼び出しエンティティによって発見されて呼び出されることができ、主に、登録タイプのAPI、セキュリティ認証タイプのAPI、API発見タイプのAPIなど、いくつかの一般的なタイプのAPIを含む。

サービスAPIは、AEFによって露出されるAPIであり、AEF上のAPIと呼ぶことができ、API呼び出しエンティティによって発見されて呼び出されることができる。サービスAPIは、主に、いくつかの特定のサービスタイプのAPIを含み、事業者によって提供される資源やサービスを使用するために、API呼び出しエンティティによって使用されうる。たとえば、QoS制御タイプのAPI、ブロードキャストタイプのAPI、IoTタイプのAPIを含む。

本願において、「例」または「たとえば」のような語は、例、例解または説明を与えることを表わすために用いられる。本願において「例」または「たとえば」として記載されているいかなる実施形態または設計も、他の実施形態または設計よりも好ましい、またはより多くの利点を有するものと解釈されるべきではない。正確には、「例」または「たとえば」のような語の使用は、関連概念を特定の方法で提示するために意図されている。「の」、「相応する（correspondingまたはrelevant）」および「対応する（corresponding）」は、時に交換可能に用いられることがある。相違が強調されないときは、表現された意味は一貫していることに注意すべきである。「Aおよび／またはB」は、AおよびBの少なくとも1つを意味する。

本願では、「認可」が独立して現われる場合、たとえば、API呼び出しエンティティの認可のように、認可はAPI呼び出しエンティティによってAPIを呼び出すことの認可を意味しうる。制限は課されない。CCF上のすべてのAPIは、CCFによって管理されるAEF上のすべてのAPI（すなわち、サービスAPI）を含んでいてもよく、またはCAPIF APIを含んでいてもよい。制限は課されない。

本願の実施形態における用語およびステップを相互に参照することができることを注意しておくべきである。同じ記述は繰り返されない。実施形態におけるステップを実行する序列は、交換されてもよい。制限は課されない。

図2に示されるように、本願のある実施形態は、認可取り消し方法を提供する。本方法は、図1に示す枠組みに適用されてもよく、具体的には、以下のように記述される。

201. 第1のエンティティが、第2のエンティティからの認可取り消し要求メッセージを受信する。

認可取り消し要求メッセージは、API呼び出しエンティティの識別子を伝達してもよい。さらに、認可取り消し要求メッセージは、具体的には、API呼び出し者認可取り消し要求（revoke API invoker authorization request）であってもよい。

API呼び出しエンティティの識別子は、API呼び出しエンティティを示すために使用されうる。

具体的には、識別子はAPI呼び出しエンティティの名前であってもよく、名前は文字、数字、およびシンボルの組み合わせであってもよく、一様資源位置指定子（Uniform Resource Locator、URL）であってもよく、完全修飾ドメイン名（fully qualified domain name、FQDN）であってもよく、またはアプリケーション（Application）の識別子であってもよく；または識別子は、API呼び出しエンティティのアドレス、たとえばIPv4アドレスおよび／またはIPv6アドレスであってもよい。

任意的に、認可取り消し要求メッセージは、次の情報：API識別子、AEF識別子、特定の値、または取り消し原因値のうちの少なくとも1つの情報をさらに担持する。

具体的には、AEF識別子はAEFを指示するために使用されてもよく、AEFの名前または番号、たとえばURLまたはFQDNであってもよく、またはAEFのアドレス、たとえばIPv4アドレスおよび／またはIPv6アドレスであってもよい。

API識別子は、API、たとえば、APIの名前、または、001のようなAPIの番号を示すために使用されてもよい。制限は課されない。APIの名前の例は次のとおり：
製品名：Google Calendar API；
サービス名：calendar.googleapis.com；
パケット名：google.calendar.v3；
インターフェース名：google.calendar.v3.CalendarService；
資源ディレクトリ：//google/calendar/v3；または
API名：calendar〔カレンダー〕。

取り消し原因値は、認可取り消し原因を示すために使用されてもよい。たとえば、API呼び出し拒否の回数が事前設定された閾値より多いか、または、誤ったAPI呼び出しの回数が事前設定された閾値より多い。制限は課されない。

一例では、認可取り消し要求メッセージは、API呼び出しエンティティによってAPI識別子に対応するAPIを呼び出す認可を取り消すことを要求する、すなわち、API呼び出しエンティティによってAPI識別子に対応するAPIを呼び出す許可を取り消すことを要求するために使用されてもよい。この場合、認可取り消し要求メッセージはAPI識別子を含むことがある。制限は課されない。

別の例では、認可取り消し要求メッセージは、API呼び出しエンティティによってAPI呼び出しエンティティに対応するCCF上のすべてのAPIを呼び出す認可を取り消すことを要求するために使用されてもよい。この場合、認可取り消し要求メッセージは、特定の値を担持してもよい。たとえば、特定の値は、認可取り消し要求メッセージにおける特定の位置に担持される；または、認可取り消し要求メッセージに担持されるAPI識別子が特定の値に設定される。明らかに、認可取り消し要求メッセージはAPI識別子を担持しなくてもよい。制限は課されない。

さらに別の例では、認可取り消し要求メッセージは、API呼び出しエンティティによってAEF上のすべてのAPIを呼び出す認可を取り消すことを要求するために使用されてもよい。この場合、認可取り消し要求メッセージは、API識別子を担持しなくてもよいが、AEF識別子を担持し、AEF識別子はAEFを示すために使用される。制限は課されない。

第1のエンティティはAEFであってもよく、第2のエンティティはCCFであってもよい；または第1のエンティティはCCFであり、第2のエンティティはAEFである。具体的には、CCFは、API呼び出しエンティティに対応するCCF、たとえば、API呼び出しエンティティを管理するCCFであってもよい。

具体的には、API呼び出しエンティティは、CAPIFシステムに登録されるために、CCFとともに登録手順を実行してもよく、CCFは、API呼び出しエンティティのAPI呼び出しを管理してもよい。たとえば、CCFはAPI呼び出しエンティティによって送信されたAPI発見要求メッセージを受信し、API発見要求メッセージに基づいて、API呼び出しエンティティのために、APIと、該APIが位置するAEFに関する情報とを提供する。一つのAPI呼び出しエンティティが、複数のCAPIFシステムに登録されてもよい。一般に、CAPIFシステムは、1つのCCFのみを含み、複数のAEFを含んでいてもよい。すなわち、1つのAPI呼び出しエンティティが1つのCCFに対応する。1つのCAPIFシステム内に複数のCCFがあるとき、API呼び出しエンティティは、それらのCCFのうちの1つを使ってCAPIFシステムに登録されてもよい。この場合、API呼び出しエンティティに対応するCCFは、登録を実行するためにAPI呼び出しエンティティによって使用されるCCFであってもよい。制限は課されない。

202. 第1のエンティティが、認可取り消し要求メッセージに基づいて、認可取り消し応答メッセージを第2のエンティティに送信する。

任意的に、認可取り消し応答メッセージは、認可取り消し結果を示すために使用される。たとえば、認可取り消しは成功する、または失敗する。認可取り消し応答メッセージは、具体的には、API呼び出し者認可取り消し応答（revoke API invoker authorization response）であってもよい。具体的には、認可取り消し要求メッセージが2つ以上のAPI呼び出しエンティティのAPI呼び出し認可を取り消すよう要求するために使用される場合には、認可取り消し応答メッセージは、対応する認可取り消し結果を含んでいてもよい。たとえば、API呼び出しエンティティ1の認可は成功裏に取り消され、API呼び出しエンティティ2の認可は取り消されない。制限は課されない。

任意的に、認可取り消し応答メッセージは、第1のエンティティが認可取り消し要求メッセージを受信したことを示すために、認可取り消し要求メッセージに応答するためにのみ使用される。一例では、第1のエンティティが認可取り消し要求メッセージを受信したとき、第1のエンティティが認可取り消し要求メッセージに対応するAPIを呼び出すための認可についてAPI呼び出しエンティティと交渉しているなら、第1のエンティティは、認可取り消しが失敗したことを示すために使用される認可取り消し応答メッセージを第2のエンティティに送信してもよい。

任意的に、本方法は、以下をさらに含む。

203. 認可取り消し要求メッセージに基づいて、API呼び出しエンティティのAPI呼び出し認可を取り消す。

一例では、認可取り消し要求メッセージがAPI識別子をさらに担持するとき、本方法はさらに、第1のエンティティが、API呼び出しエンティティによってAPI識別子に対応するAPIを呼び出すための認可を取り消すことを含む。換言すれば、認可取り消し要求メッセージに基づいてAPI呼び出しエンティティのAPI呼び出し認可を取り消す前述のステップは、具体的には、API呼び出しエンティティによってAPI識別子に対応するAPIを呼び出す認可を取り消すこと、またはAPI呼び出しエンティティのAPIアクセス許可（またはアクセス認可）を取り消すことであってもよい。

別の例では、認可取り消し要求メッセージがAPI識別子およびAEF識別子をさらに担持するとき、本方法はさらに、第1のエンティティが、API呼び出しエンティティによって、AEF識別子に対応するAEF上にあり、かつAPI識別子に対応するAPIを呼び出す認可を取り消すことを含む。換言すれば、認可取り消し要求メッセージに基づいてAPI呼び出しエンティティのAPI呼び出し認可を取り消す前述のステップは、具体的には、API呼び出しエンティティによって、AEF識別子に対応するAEF上にあり、かつ、API識別子に対応するAPIを呼び出す認可を取り消すことであってもよい。

別の例では、認可取り消し要求メッセージがAPI識別子を担持しないとき、本方法はさらに、第1のエンティティが、API呼び出しエンティティによって、API呼び出しエンティティに対応するCCF上のすべてのAPIを呼び出す認可を取り消すことを含む。換言すれば、認可取り消し要求メッセージに基づいてAPI呼び出しエンティティのAPI呼び出し認可を取り消す前述のステップは、具体的には、API呼び出しエンティティによって、API呼び出しエンティティに対応するCCF上のすべてのAPIを呼び出す認可を取り消すことであってもよい。

別の例では、認可取り消し要求メッセージがAPI識別子を担持せず、認可取り消し要求メッセージがさらにAEF識別子を担持するとき、本方法は、第1のエンティティが、API呼び出しエンティティによってAEF識別子に対応するAEF上のすべてのAPIを呼び出す認可を取り消すことを含む。換言すれば、認可取り消し要求メッセージに基づいてAPI呼び出しエンティティのAPI呼び出し認可を取り消す前述のステップは、具体的には、API呼び出しエンティティによってAEF識別子に対応するAEF上のすべてのAPIを呼び出す認可を取り消すことであってもよい。

さらに別の例では、認可取り消し要求メッセージがAPI識別子を担持せず、認可取り消し要求メッセージがさらに特定の値を担持するとき、あるいは認可取り消し要求メッセージがAPI識別子を担持し、API識別子が特定の値として設定されているとき、本方法はさらに、第1のエンティティが、API呼び出しエンティティによって、API呼び出しエンティティに対応するCCF上のすべてのAPIを呼び出す認可を取り消すことを含む。換言すれば、認可取り消し要求メッセージに基づいてAPI呼び出しエンティティのAPI呼び出し認可を取り消す前述のステップは、具体的には、API呼び出しエンティティによって、API呼び出しエンティティに対応するCCF上のすべてのAPIを呼び出す認可を取り消すことであってもよい。

API識別子に対応するAPIは、API識別子によって示されるAPIであってもよい。AEF識別子に対応するAEFは、AEF識別子によって示されるAEFであってもよい。

取り消しとは、第1のエンティティが、API呼び出しエンティティの関連情報をローカルに記憶されたブラックリストに追加する、API呼び出しエンティティの関連情報をローカルに記憶されたホワイトリストから削除する、あるいはAPI呼び出しエンティティの関連情報を無効にすることを意味しうる。ブラックリストまたはホワイトリストは、API呼び出しエンティティがAPI呼び出し認可をもつかどうかを判定するために使用されてもよく、API呼び出しエンティティがAPI呼び出し許可をもつかどうかを判定するために使用されてもよい。

本願で言及される取り消しは、無効化、取り下げまたはキャンセルに置き換えられてもよいことを注意しておくべきである。本願で言及される認可は、許可、アクセス認可、アクセス許可、または許可、またはアクセス許可を意味しうる。本願において言及される呼び出しは、アクセスに置き換えられてもよい。制限は課されない。

一例では、API呼び出しエンティティがAPI呼び出し認可をもたない、またはAPIアクセス許可をもたないことを示すための情報は、ブラックリストの形で記憶される。表1を参照すると、ブラックリストはAPIに基づいていてもよい。あるいはまた、表2を参照すると、ブラックリストはAPI呼び出しエンティティに基づいてもよい。

API#1は番号1を付けられたAPIであってもよく、API#2は番号2を付けられたAPIであってもよく、AEF#1は番号1を付けられたAEFであってもよい。

別の例では、API呼び出しエンティティがAPI呼び出し認可をもつ、または、API呼び出しエンティティがAPIアクセス許可をもつことを示すために使用される情報は、ホワイトリストの形で記憶される。詳細は記載していない。

なお、ステップ203は、ステップ202の前に実行されてもよく、あるいはステップ202の後に実行されてもよいことを注意しておくべきである。明らかに、ステップ203が実行されるとき、認可取り消し応答メッセージは、認可取り消しが成功することを示すために使用されうる。さらに、第1のエンティティがCCFであるとき、ステップ203は実行されなくてもよい。

本実施形態において提供される方法では、第1のエンティティは、第2のエンティティからの認可取り消し要求メッセージを受信し、ここで、認可取り消し要求メッセージは、API呼び出しエンティティの識別子を担持し；第1のエンティティは、認可取り消し要求メッセージに基づいて、認可取り消し応答メッセージを第2のエンティティに送信する。よって、API呼び出し認可管理が改善され、API呼び出し認可が適時に取り消されることができ、それにより、API呼び出し認可をすでにもっていないAPI呼び出しエンティティ（すなわち、該API呼び出しエンティティの認可が無効にされているか、または失効している）によってAPIを呼び出すことによって引き起こされる資源の浪費を回避する。たとえば、API呼び出しエンティティはもとの認証を用いてAPIを呼び出し、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的には失敗する。結果として、AEFの処理資源が浪費される。さらに、AEFは、API呼び出し認可をもたないAPI呼び出しエンティティのAPI呼び出しのためのサービス論理を実行することを防がれ、それにより、CAPIFシステムの作業効率を改善する。

任意的に、前述の実施形態の第1の実施シナリオにおいて、本方法は、さらに以下を含む：第1のエンティティが、認可取り消し指示メッセージをAPI呼び出しエンティティに送信する。

任意的に、認可取り消し指示メッセージは、次の情報：API識別子、AEF識別子、特定の値、または取り消し原因値のうちの少なくとも1つの情報を担持する。API識別子、AEF識別子、特定の値、および取り消し原因値は、ステップ201で認可取り消し要求メッセージにおいて担持される関連する内容と同じであってもよく、あるいは異なっていてもよい。制限は課されない。たとえば、認可取り消し指示メッセージに担持されるAPI識別子は、認可取り消し要求メッセージに含まれるAPI識別子と同じであってもよく、あるいは異なっていてもよい。制限は課されない。

認可取り消し指示メッセージは、以下のイベントを示すために使用されてもよい：
（1）API呼び出しエンティティによって特定のAPIを呼び出す認可が取り消される；または
（2）API呼び出しエンティティによってAEF上のすべてのAPIを呼び出す認可が取り消される；または
（3）API呼び出しエンティティによってCCF上のすべてのAPIを呼び出す認可が取り消される。

具体的には、認可取り消し指示メッセージがイベント（1）を示すために使用されるとき、認可取り消し指示メッセージは、特定のAPIの識別子を担持してもよい。認可取り消し指示メッセージがイベント（2）を示すために使用されるとき、認可取り消し指示メッセージはAEF識別子を担持してもよく、AEF識別子はAEFを示すために使用される。認可取り消し指示メッセージがイベント（3）を示すために使われるとき、認可取り消し指示メッセージはAPI識別子を担持しなくてもよく、あるいは特定の値を担持してもよい。詳細は、認可取り消し要求メッセージと同様である。詳細については、認可取り消し要求メッセージの関連する記述を参照されたい。詳細を再び述べることはしない。

ある実装においては、認可取り消し指示メッセージは、API（これは、取り消し指示メッセージにおいて言及されるAPIであってもよい）を呼び出すための最新の認可情報をAPI呼び出しエンティティがCCFから要求する手順にリダイレクトするようAPI呼び出しエンティティをトリガーしてもよく（たとえば、API呼び出し認可情報を要求するために使用される要求メッセージをCCFに送信するようAPI呼び出しエンティティをトリガーしてもよく）、またはAPI呼び出しエンティティがCCFとともにセキュリティ認証を実行する手順にリダイレクトするようにしてもよく、それにより、API呼び出しエンティティは、まず最新のAPI呼び出し認可情報を取得することを強制される、または、API呼び出しエンティティは、API呼び出しエンティティが認可ユーザーであることを再認証を通じて判別した後でのみ、その後のAPI呼び出しを実行するように強制される。

認可取り消し指示メッセージは、API呼び出しエンティティがAPI呼び出しエンティティによって取得された最新のAPI呼び出し認可情報に基づいてAPI呼び出し手順を開始できるように、API呼び出しエンティティのAPI呼び出し認可が取り消されたことを示すために使用されてもよいことが理解されうる。よって、無効にされた認可情報を用いてAPI呼び出し要求メッセージが送信されるために引き起こされるAPI呼び出し失敗が回避され、不必要な情報交換が減り、それにより、資源が節約でき、効率が改善できる。

認可取り消し指示メッセージは、API呼び出し者認可取り消し通知（revoke API invoker authorization notify）メッセージであってもよい。

一例では、第1のエンティティは、ステップ203の後、認可取り消し指示メッセージをAPI呼び出しエンティティに送信する。

第1の実装シナリオで提供された方法では、API呼び出しエンティティはAPI呼び出しエンティティの認可情報を適時に知ることができ、それによって次の二つの場合を回避する：API呼び出しエンティティによるAPIの呼び出しのための認可情報が無効にされた／取り消されたことをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出すため、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的には失敗し、結果として、AEFの処理資源が無駄になる。さらに、API呼び出しエンティティの認可が無効にされるまたは期限切れになることをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出そうと試みるため、API呼び出しエンティティの処理資源が無駄になる。

任意的に、前述の実施形態の第2の実装シナリオでは、第1のエンティティはAPI呼び出しエンティティに対応するCCFであり、第2のエンティティはAEFであり、第1のエンティティがAPI呼び出しエンティティによってAPI呼び出しエンティティに対応するCCF上のすべてのAPIを呼び出す認可を取り消した後、本方法は、さらに以下を含む：
第1のエンティティは、認可取り消し通知メッセージをCCFに対応するAEFに送信する。

認可取り消し通知メッセージは、API呼び出しエンティティのAPI呼び出し認可が取り消されたことを通知するために使用されてもよく、認可取り消し通知メッセージはAPI呼び出しエンティティの識別子を担持しうる。

さらに、認可取り消し通知メッセージは、API識別子および／または認可取り消し原因値をさらに担持してもよい。

一例では、認可取り消し通知メッセージは、API呼び出しエンティティによって特定のAPIを呼び出す認可が取り消されたことを通知するために使用されてもよい。この場合、認可取り消し通知メッセージはさらにAPI識別子を担持してもよく、API識別子は特定のAPIを示すために使用される。

さらに、認可取り消し通知メッセージは、具体的には、API呼び出し者認可取り消し通知であってもよい。

CCFに対応するAEFは、CCFによって管理されるすべてのAEFであってもよいし、CCFによって管理されるすべてのAEFのうち第2のエンティティ以外のAEFであってもよいし、あるいはCCFによって管理されるAEF内にあり、API呼び出しエンティティに関連するAEFであってもよい。具体的には、API呼び出しエンティティは、API発見プロセスを使用して、少なくとも1つのAPIと、該少なくとも1つのAPIが位置するAEFに関する情報とを、CCFから取得する。たとえば、API呼び出しエンティティは、API発見要求メッセージをCCFに送信し、CCFは、API発見要求メッセージに基づいて、API呼び出しエンティティのために、APIと、該APIが位置するAEFに関する情報とを提供する。AEFに関する前記情報に対応するAEFは、CCFによって管理される一つまたは複数のAEFであってもよく、AEFに関する前記情報に対応するAEFは、CCFによって管理されるAEF内にあり、API呼び出しエンティティに関連するAEFと称されてもよい。制限は課されない。

CCFによって管理されるAEF内にあり、API呼び出しエンティティに関連するAEFは、API発見プロセスにおいてAPI呼び出しエンティティによって取得された前記少なくとも1つのAPIにおける呼び出されたAPIが位置しているAEFを含んでいてもよく、あるいは、API発見プロセスにおいてAPI呼び出しエンティティによって取得されたAPIにおける呼び出されていないAPIが位置している含んでいてもよいことを注意しておくべきである。制限は課されない。

対応して、第2のエンティティは、認可取り消し通知メッセージに基づいて、API呼び出しエンティティの認可情報を更新してもよい。

具体的には、第2のエンティティがAPI呼び出しエンティティの認可を記憶していなかった場合、第2のエンティティはAPI呼び出しエンティティの認可情報を記憶する。それにより、AEFは、AEFによって取得されるAPI呼び出しエンティティの最新の認可情報に基づいて、API呼び出しエンティティのAPI呼び出しに対して適切な動作を実行する。たとえば、API呼び出しエンティティによって特定のAPIを呼び出す認可が取り消されるとき、AEFは、特定のAPIを呼び出すAPI呼び出しエンティティの要求を直接拒否してもよい。

第2の実装シナリオで提供される方法では、AEFは、API呼び出しエンティティの認可情報を適時に知ることができ、それにより、次の場合を回避する：API呼び出しエンティティがもとの認可を用いてAPIを呼び出すときでも、AEFは依然としてAPI呼び出しのためのサービス論理を実行してしまい、結果としてAEFの処理資源が浪費される。

第1実装シナリオおよび第2実装シナリオが組み合わされてもよいことを注意しておくべきである。制限は課されない。

図3に示されるように、本願のある実施形態は、別の認可取り消し方法を提供する。本方法は、図1に示される枠組みに適用されてもよく、具体的には、以下のように記述される。

301. 第2のエンティティが、認可取り消し要求メッセージを第1のエンティティに送信する。

認可取り消し要求メッセージは、API呼び出しエンティティの識別子を担持してもよい。

第1のエンティティはAEFであってもよく、第2のエンティティはCCFであってもよい；あるいは、第1のエンティティがCCFであってもよく、第2のエンティティがAEFであってもよい。具体的には、CCFはAPI呼び出しエンティティに対応するCCFであってもよい。詳細については、図2に示される実施形態における関連する説明を参照されたい。詳細を再び述べることはしない。

302. 第2のエンティティが、第1のエンティティから認可取り消し応答メッセージを受信する。

認可取り消し応答メッセージについては、図2に示される実施形態における関連する記述を参照されたい。たとえば、認可取り消し応答メッセージは、認可取り消しが成功するまたは失敗することを示すために使用されてもよい。

任意的に、ステップ301は、以下を含む：第2のエンティティが、API呼び出しエンティティの認可取り消し関連情報に基づいて、認可取り消し要求メッセージを第1のエンティティに送信する。API呼び出しエンティティのための認可取り消しを実装するために、API呼び出しエンティティの状態がリアルタイムで監視される。

一例では、認可取り消し関連情報が事前設定された条件を満たすとき、第2のエンティティは、認可取り消し要求メッセージを第1のエンティティに送信する。

認可取り消し関連情報は、次の情報：API呼び出し拒否の回数、誤ったAPI呼び出しの回数、またはAPI呼び出し成功の回数のうちの少なくとも1つの情報を含みうる。具体的には、API呼び出し拒否の回数は、API呼び出しエンティティによるAPIの呼び出しが拒否される回数、すなわち、APIの呼び出しが拒否される回数であってもよく；または、API呼び出しエンティティによるすべてのAPIの呼び出しが事前に設定された時間期間内に拒否される回数であってもよい。誤ったAPI呼び出しの回数は、API呼び出しエンティティが誤ってAPIを呼び出す回数、すなわち、APIが誤って呼び出される回数であってもよく；または、API呼び出しエンティティが事前設定された時間期間内にすべてのAPIを誤って呼び出す回数であってもよい。制限は課されない。

誤ったAPIの呼び出しは、不適切なパラメータを使用してAPIを呼び出すことを意味しうる。たとえば、APIの入力パラメータは文字列型であり、API呼び出しエンティティがAPIを呼び出すとき、入力パラメータ値が数値である。別の例として、APIは3つの入力パラメータをもち、API呼び出しエンティティがAPIを呼び出すときに、3つより多くの入力パラメータがある。

一例では、認可取り消し関連情報は、API呼び出し失敗の回数を含む。API呼び出しの失敗の回数が閾値を超えると、第2のエンティティは認可取り消し要求メッセージを第1のエンティティに送信する。

別の例では、API呼び出しの失敗の回数と誤ったAPI呼び出しの回数との和が閾値を超えた場合、第2のエンティティが認可取り消し要求メッセージを第1のエンティティに送信する。

さらに別の例では、API呼び出し成功の回数が上限に達する、またはAPI呼び出し成功の回数が事前設定された時間期間内に上限に達する場合、第2のエンティティは認可取り消し要求メッセージを第1のエンティティに送信する。

任意的に、認可取り消し要求メッセージはさらに、次の情報：API識別子、AEF識別子、特定の値、または取り消し原因値のうちの少なくとも1つの情報を担持する。詳細については、図2に示される実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

本実施形態において提供される方法では、第2のエンティティは、認可取り消し要求メッセージを第1のエンティティに送信し、ここで、認可取り消し要求メッセージは、API呼び出しエンティティの識別子を担持し；第2のエンティティは、認可取り消し応答メッセージを第1のエンティティから受信し、ここで、認可取り消し応答メッセージは、認可取り消しが成功または失敗することを示すために使用される。この方法では、API呼び出し認可管理が改善され、API呼び出し認可が適時に取り消されることができ、それにより、API呼び出し認可をすでにもっていないAPI呼び出しエンティティ（換言すれば、該API呼び出しエンティティの認可が無効にされた、または期限切れになった）によってAPIを呼び出すことによって引き起こされる資源の無駄を回避する。たとえば、API呼び出しエンティティはもとの認証を用いてAPIを呼び出し、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的には失敗する。結果として、AEFの処理資源が浪費される。さらに、AEFは、API呼び出し認可をすでにもっていないAPI呼び出しエンティティのAPI呼び出しのためのサービス論理を実行することを防止され、それによりCAPIFシステムの作業効率が改善される。

任意的に、前述の実施形態の第1の実装シナリオにおいて、第2のエンティティはAEFであり、第1のエンティティはCCFであり、本方法はさらに下記を含む：
第2のエンティティが、API呼び出しエンティティからAPI呼び出し要求メッセージを受信し；第2のエンティティが、API呼び出し要求メッセージに基づいてAPI呼び出し要求メッセージを拒否する。

API呼び出し要求メッセージは、API呼び出しエンティティが呼び出すことを要求するAPIに対応するAPI識別子を担持してもよい。

第2のエンティティがAPI呼び出し要求メッセージに基づいてAPI呼び出し要求メッセージを拒否することは、下記を含んでいてもよい：
API呼び出しエンティティが、API呼び出し要求メッセージが呼び出すことを要求するために使用されているAPIを呼び出す認可をもたないとき、第2のエンティティはAPI呼び出し要求メッセージを拒否する。

具体的には、第2のエンティティがAPI呼び出し要求メッセージを拒否することは、第2のエンティティがAPI呼び出しエンティティにAPI呼び出し拒否メッセージを送信すること、またはAPI呼び出しエンティティに応答メッセージを送信しないことなどを含みうる。制限は課されない。

一例では、API呼び出し要求メッセージは、API#1を呼び出すことを要求する。しかしながら、AEFは、API呼び出しエンティティがAPI#1を呼び出す権限をもたないこと、すなわち、API呼び出しエンティティがAPI#1にアクセスする権限をもたないことを見出す。この場合、AEFはAPI呼び出しエンティティによって送信されたAPI呼び出し要求メッセージを拒否するために、API呼び出し拒否メッセージをAPI呼び出しエンティティに直接送信してもよい。

具体的には、AEFは、ブラックリストまたはホワイトリストをローカルに記憶していてもよく、すなわち、APIごとにブラックリストまたはホワイトリストがある。たとえば、AEFがブラックリストがAPI呼び出しエンティティの識別子を含んでいると判断したとき、AEFはAPI呼び出しエンティティによって送信されたAPI呼び出し要求メッセージを拒否する。

ブラックリストおよびホワイトリストの両方とも、たとえば、API#1：API呼び出し者1およびAPI呼び出し者2のようにAPIによってインデックス付けされてもよく、あるいは、API呼び出し者1:API#1およびAPI#3のように、API呼び出しエンティティによってインデックス付けされてもよい。詳細については、図2に示される実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

第1の実装シナリオでは、AEFは認可をもたないAPI呼び出しエンティティによって送信されたAPI呼び出し要求メッセージを拒否し、それにより、API呼び出しの処理効率を改善し、AEFの処理資源を節約する。

任意的に、前述の実施形態の第2の実装シナリオでは、本方法は、下記をさらに含む：
第2のエンティティが、認可取り消し指示メッセージをAPI呼び出しエンティティに送信する。

認可取り消し指示メッセージについては、図2に示される実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

一例では、第2のエンティティは、認可取り消し応答メッセージに基づいて、認可取り消し指示メッセージをAPI呼び出しエンティティに送信する。たとえば、認可取り消し応答メッセージがAPI呼び出しエンティティの認可が成功裏に取り消されたことを示すために使用される場合、第2のエンティティは認可取り消し指示メッセージをAPI呼び出しエンティティに送信する。認可取り消し応答メッセージがAPI呼び出しエンティティの認可が取り消され損なったことを示すために使用される場合は、第2のエンティティは認可取り消し指示メッセージをAPI呼び出しエンティティに送信しない。

別の例では、第2のエンティティは、認可取り消し通知メッセージに基づいて、認可取り消し指示メッセージをAPI呼び出しエンティティに送信する。たとえば、認可取り消し応答メッセージが認可取り消し要求メッセージに応答するためのみに使用される、すなわち、第1のエンティティが認可取り消し要求メッセージを受信したことを示すために使用される場合、第2のエンティティは、第1のエンティティによって送信された認可取り消し通知メッセージを受信し（本実施形態では第3の実装シナリオを参照）、次いで、認可取り消し通知メッセージに基づいて、認可取り消し指示メッセージをAPI呼び出しエンティティに送信してもよい。

認可取り消し指示メッセージがAPI呼び出しエンティティに送信されるので、API呼び出しエンティティは、API呼び出しエンティティの認可情報を適時に知ることができ、それにより、次の二つの場合を回避する：API呼び出しエンティティによるAPIの呼び出しのための認可情報が無効にされた／取り消されたことをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出すため、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的には失敗し、結果として、AEFの処理資源が無駄になる。さらに、API呼び出しエンティティの認可が無効にされるまたは期限切れになることをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出そうと試みるため、API呼び出しエンティティの処理資源が無駄になる。

任意的に、前述の実施形態の第3の実装シナリオでは、第2のエンティティはAEFであり、第1のエンティティはCCFであり、本方法はさらに下記を含む：
第2のエンティティが、第1のエンティティから認可取り消し通知メッセージを受信し、認可取り消し通知メッセージに基づいてAPI呼び出しエンティティの認可情報を更新する。

具体的には、第2のエンティティがAPI呼び出しエンティティの認可を記憶していなかった場合、第2のエンティティはAPI呼び出しエンティティの認可情報を記憶する。たとえば、認可情報をブラックリストやホワイトリストに記憶する。それにより、AEFは、AEFによって取得されたAPI呼び出しエンティティの最新の認可情報に基づいて、API呼び出しエンティティのAPI呼び出し時に適切な動作を実行する。たとえば、API呼び出しエンティティによる特定のAPIを呼び出す認可が取り消されたとき、AEFは、その特定のAPIを呼び出すそのAPI呼び出しエンティティの要求を直接拒否してもよい。

第1のエンティティは、第2のエンティティがAPI呼び出しエンティティの認可情報を適時に更新できるように、認可取り消し通知メッセージを第2のエンティティに送信する。たとえば、第2のエンティティがAEFであるとき、AEFはAPI呼び出しエンティティの認可情報を適時に知ることができ、それにより、次の場合を回避する：API呼び出しエンティティがもとの認可を用いてAPIを呼び出すときでも、AEFは依然としてAPI呼び出しのためのサービス論理を実行してしまい、結果として、AEFの処理資源が浪費される。

別の例として、第2のエンティティがCCFであるとき、CCFは、認可取り消し通知メッセージに基づいて、CCFに記憶されているAPI呼び出しエンティティの認可情報を適時に更新してもよく、それにより、API呼び出し認可をCCFから取得するときにAPI呼び出しエンティティが最新の認可情報を入手できない場合に引き起こされる低効率や資源の浪費といった問題を回避する。

前述の実装シナリオのうちの2つを組み合わせてもよいし、前述の実装シナリオのうちの3つを組み合わせてもよいことを注意しておくべきである。制限は課されない。

図4に示されるように、本願のある実施形態は、さらに別の認可取り消し方法を提供する。この方法は、図1に示される枠組みに適用されてもよく、具体的には、以下のように記述される。

401. AEFが、API呼び出しエンティティの認可取り消し関連情報に基づいて、認可取り消し要求メッセージをCCFに送信する。

認可取り消し要求メッセージは、API呼び出しエンティティの識別子を担持してもよい。詳細については、前述の実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

認可取り消し関連情報については、図3に示される実施形態における関連記述を参照されたい。詳細を再び述べることはしない。

具体的には、ステップ401は、認可取り消し関連情報が事前設定された条件を満たすとき、AEFが、認可取り消し要求メッセージをCCFに送信することを含んでいてもよい。

一例では、API呼び出しエンティティのAPI呼び出し拒否の回数が事前設定された閾値を超えるとき、AEFは認可取り消し要求メッセージをCCFに送信し、ここで、認可取り消し要求メッセージはAPI呼び出しエンティティの識別子を担持する。閾値は、AEF上であらかじめ構成設定されていてもよいし、あるいはCCFによってAEFのために構成設定されてもよい。API呼び出し拒否の回数は、特定のAPIを呼び出すことが拒否される回数であってもよいし、あるいは制限されなくてもよい。

別の例では、API呼び出しエンティティの誤ったAPI呼び出しの回数が事前設定された閾値を超えるとき、AEFは認可取り消し要求メッセージをCCFに送信し、ここで、認可取り消し要求メッセージはAPI呼び出しエンティティの識別子を担持する。閾値は、AEF上であらかじめ構成設定されていてもよいし、あるいはCCFによってAEFのために構成設定されてもよい。

誤ったAPI呼び出しの回数は、特定のAPIが誤って呼び出される回数であってもよく、あるいは制限されなくてもよい。

さらに別の例では、API呼び出しエンティティの誤ったAPI呼び出しの回数が第1閾値を超え、かつAPI呼び出しエンティティのAPI呼び出し拒否の回数が第2閾値を超えるとき、AEFは認可取り消し要求メッセージをCCFに送信し、ここで、認可取り消し要求メッセージはAPI呼び出しエンティティの識別子を担持する。同様に、誤ったAPI呼び出しの回数は、特定のAPIが誤って呼び出される回数であってもよく、あるいは制限されなくてもよい。

認可取り消し要求メッセージは、次の情報：API識別子、AEF識別子、特定の値、または取り消し原因値のうちの少なくとも1つの情報を伝えてもよい。AEF識別子は、ステップ401においてAEFを示すために使用されてもよい。詳細については、図2に示される実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

402. CCFが、認可取り消し要求メッセージに基づいて、認可取り消し応答メッセージをAEFに送信する。

認可取り消し応答メッセージについては、図2に示される実施形態における関連する記述を参照されたい。たとえば、認可取り消し応答メッセージは、認可取り消し結果を示すために、すなわち、認可取り消しが成功または失敗することを示すために使用されてもよい。

一例では、CCFがAEFによって送られた認可取り消し要求メッセージを受信し、ここで、認可取り消し要求メッセージは、特定のAPIを呼び出す認可を取り消すことを要求するために使用される、とき、CCFが該特定のAPIを呼び出す認可についてAPI呼び出しエンティティとすでに交渉しているならば、CCFは、認可取り消しが失敗したことを示すために使用される認可取り消し応答メッセージをAEFに送信する。

対応して、AEFは、認可取り消し応答メッセージを受信する。さらに、AEFは、認可取り消し応答メッセージに基づいて、API呼び出しエンティティのAPI呼び出し認可情報を更新してもよい。

403. CCFが、認可取り消し指示メッセージをAPI呼び出しエンティティに送信する。

認可取り消し指示メッセージは、以下のイベントを示すために使用されうる：
（1）API呼び出しエンティティによって特定のAPIを呼び出す認可が取り消される；または
（2）API呼び出しエンティティによってAEF上のすべてのAPIを呼び出す認可が取り消される；または
（3）API呼び出しエンティティによってCCF上のすべてのAPIを呼び出す権限が取り消される。

任意的に、認可取り消し指示メッセージは、次の情報：API識別子、AEF識別子、特定の値、または取り消し原因値のうちの少なくとも1つの情報を担持する。

具体的には、認可取り消し指示メッセージがイベント（1）を示すために使用されるとき、認可取り消し指示メッセージは、特定のAPIの識別子を担持してもよい。認可取り消し指示メッセージがイベント（2）を示すために使用されるときは、認可取り消し指示メッセージはAEF識別子を担持してもよく、そしてAEF識別子はAEFを示すために使用される。認可取り消し指示メッセージがイベント（3）を示すために使われるときは、認可取り消し指示メッセージはAPI識別子を担持しなくてもよく、あるいは特定の値を担持してもよい。詳細は、認可取り消し要求メッセージと同様である。詳細については、認可取り消し要求メッセージの関連する記述を参照されたい。詳細を再び述べることはしない。

対応して、API呼び出しエンティティは認可取り消し指示メッセージを受信する。さらに、API呼び出しエンティティは、認可取り消し指示メッセージに基づいてAPI呼び出し認可情報を更新してもよい。

ステップ403〜406はすべて任意のステップであることを注意しておくべきである。

任意的に、API呼び出しエンティティによってCCF上のすべてのAPIを呼び出す認可が取り消される場合については、ステップ404が実行される。

404. CCFが、認可取り消し通知メッセージを別のAEFに送信する。

認可取り消し通知メッセージは、API呼び出しエンティティのAPI呼び出し認可が取り消されたことを前記別のAEFに通知するために使用されてもよい。それにより、前記別のAEFも、API呼び出しエンティティのAPI呼び出し要求を直接拒否することができ、API呼び出し失敗によって引き起こされるシステム資源の無駄を減らす。認可取り消し通知メッセージは、API呼び出しエンティティの識別子を担持してもよく、あるいはAPI識別子および／または認可取り消し原因値を担持してもよい。詳細については、図2に示される実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

前記別のAEFは、CCFによって管理されるAEF内のステップ401におけるAEF以外のAEFであってもよく、あるいは、CCFによって管理されるAEF内のステップ401におけるAEF以外の、API呼び出しエンティティに関連するAEFであってもよい。詳細については、図2に示される実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

対応して、前記別のAEFは、認可取り消し通知メッセージを受信する。さらに、前記別のAEFは、認可取り消し通知メッセージに基づいて、API呼び出しエンティティのAPI呼び出し認可情報を更新してもよい。

405. API呼び出しエンティティが、API呼び出し要求メッセージをAEFに送信する。

API呼び出し要求メッセージは、API呼び出しエンティティが呼び出すことを要求するAPIに対応するAPI識別子を担持してもよい。

具体的には、API呼び出しエンティティは、API呼び出しエンティティに記憶されているAPI呼び出し認可情報に基づいて、API呼び出し要求メッセージをAEFに送信してもよい。制限は課されない。

406. AEFが、API呼び出し要求メッセージに基づいて要求メッセージを拒否する。

要求を拒否することは、API呼び出しエンティティに拒否メッセージを送信することであってもよく、またはAPI呼び出しエンティティに応答メッセージを送信しないことであってもよい。制限は課されない。

ステップ406については、図3に示される実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

任意的に、ステップ403の前に、本方法はさらに、CCFが、認可取り消し要求メッセージに基づいて、API呼び出しエンティティのAPI呼び出し認可を取り消すことを含む。詳細については、ステップ203における関連する記述を参照されたい。詳細は述べない。

本実施形態において提供される方法では、AEFは、認可取り消し要求メッセージをCCFに送信し、ここで、認可取り消し要求メッセージは、API呼び出しエンティティの識別子を担持し；AEFは、CCFから認可取り消し応答メッセージを受信し、ここで、認可取り消し応答メッセージは、認可取り消しが成功または失敗することを示すために使用される。この方法では、API呼び出し認可管理が改善され、API呼び出し認可を適時に取り消すことができるようにする。それにより、API呼び出し認可をすでにもっていないAPI呼び出しエンティティ（すなわち、該API呼び出しエンティティの認可が無効化されたか、または失効している）によってAPIを呼び出すことによって引き起こされる資源の無駄を回避する。たとえば、API呼び出しエンティティはもとの認証を用いてAPIを呼び出し、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的には失敗する。結果として、AEFの処理資源が浪費される。さらに、AEFは、API呼び出し認可をすでにもっていないAPI呼び出しエンティティのAPI呼び出しのためのサービス論理を実行することを防止され、それによりCAPIFシステムの作業効率が改善される。

図5に示されるように、本願のある実施形態は、さらに別の認可取り消し方法を提供する。この方法は、図1に示される枠組みに適用されてもよく、具体的には、以下のように記述される。

501. CCFが、API呼び出しエンティティの認可取り消し関連情報に基づいて、認可取り消し要求メッセージをAEFに送信する。

認可取り消し要求メッセージは、API呼び出しエンティティの識別子を担持してもよい。詳細については、図2に示される実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

認可取り消し関連情報について、およびAPI呼び出しエンティティの認可取り消し関連情報に基づいて認可取り消し要求メッセージをどのように送信するかについては、前述の諸実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

任意的に、ステップ501の前に、本方法はさらに、CCFが、AEFによって報告されたAPI呼び出し情報、たとえば、API呼び出しの総回数、API呼び出し失敗の回数、またはAPI呼び出し成功の回数を受信することであって、API呼び出し情報は、認可取り消し関連情報を得るために使用されてもよい、こと；または、CCFが、AEFによって報告された認可取り消し関連情報を受信することを含む。

一例では、API呼び出しにおいて例外が発生するとき、たとえば、API呼び出しエンティティが誤ってAPIを呼び出すとき、AEFはエラー情報をCCFに報告する。このようにして、CCFは、CCFによって管理されるシステム全体におけるAPI呼び出しエンティティのAPI呼び出し状態を取得してもよい。それにより、API呼び出しエンティティのAPI呼び出し認可が、API呼び出し状態に基づいて取り消される。

502. AEFが、認可取り消し要求メッセージに基づいて、API呼び出しエンティティのAPI呼び出し認可を取り消す。

ステップ502では、API呼び出しエンティティのAPI呼び出し認可の取り消しは、以下のようであってもよい：
API呼び出しエンティティによって特定のAPIを呼び出す認可を取り消す；または
API呼び出しエンティティによってAEF上のすべてのAPIを呼び出す認可を取り消す。

一例では、認可取り消し要求メッセージはAPI識別子をさらに担持し、AEFはAPI呼び出しエンティティによってAPI識別子に対応するAPIを呼び出す認可を取り消す。

別の例では、認可取り消し要求メッセージは、さらに、API識別子と、ステップ502においてAEFを示すために使用されるAEF識別子とを担持し、AEFは、API呼び出しエンティティによって、API識別子に対応し、AEF上にあるAPIを呼び出す許可を取り消す。

さらに別の例では、認可取り消し要求メッセージがAPI識別子を担持しないとき、または認可取り消し要求メッセージがAPI識別子を担持しないが、ステップ502においてAEFを示すために使用されるAEF識別子を担持するとき、または認可取り消し要求メッセージがさらに特定の値を担持するとき、AEFは、API呼び出しエンティティによってAEF上のすべてのAPIを呼び出す認可を取り消す。

前述の取り消しは、AEFにローカルに記憶されたブラックリストにAPI呼び出しエンティティの関連レコードを追加するか、またはAEFにローカルに記憶されたホワイトリストからAPI呼び出しエンティティの関連レコードを削除することによって具体的に実現されうる。詳細については、図2に示される実施形態における関連する記述を参照されたい。制限は課されない。

503. AEFが、認可取り消し応答メッセージをCCFに送信する。

認可取り消し応答メッセージは、認可取り消し結果を含んでいてもよい。詳細については、図2に示される実施形態における関連する記述を参照されたい。たとえば、認可取り消し応答メッセージは、認可取り消しが成功または失敗することを示すために使用される。

一例では、API識別子によって示される、AEF上のAPIの使用が停止する場合（たとえば、APIが存在しない、またはAPIが廃用にされた場合）、AEFはCCFに、認可取り消しが失敗することを示す取り消し応答メッセージを返す。

504. CCFが、API呼び出しエンティティに認可取り消し指示メッセージを送信する。

対応して、API呼び出しエンティティは認可取り消し指示メッセージを受信する。さらに、API呼び出しエンティティは、認可取り消し指示メッセージに基づいてAPI呼び出し認可情報を更新してもよい。

ステップ504については、ステップ403における関連する記述を参照されたい。さらに、ステップ504は、AEFがAPI呼び出しエンティティに認可取り消し指示メッセージを送信するステップと置き換えてもよい。制限は課されない。

ステップ504〜506は任意的なステップであることを注意しておくべきである。具体的には、ステップ505および506は、ステップ504が実行されないときに実行されてもよい。制限は課されない。

505. API呼び出しエンティティが、API呼び出し要求メッセージをAEFに送信する。

API呼び出し要求メッセージは、API呼び出しエンティティが呼び出すことを要求するAPIに対応するAPI識別子を担持していてもよい。

506. AEFが、API呼び出し要求メッセージに基づいて要求メッセージを拒否する。

要求を拒否することは、API呼び出しエンティティに拒否メッセージを送信することであってもよく、あるいはAPI呼び出しエンティティに応答メッセージを送信しないことであってもよい。制限は課されない。

ステップ506については、図3において示される実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

この実施形態において提供される方法では、CCFは、認可取り消し要求メッセージをAEFに送信し、ここで、認可取り消し要求メッセージは、API呼び出しエンティティの識別子を担持し；AEFは、認可取り消し応答メッセージをCCFに送信し、ここで、認可取り消し応答メッセージは、認可取り消しが成功または失敗することを示すために使用される。本方法では、API呼び出し認可管理が改善され、API呼び出し認可を適時に取り消すことができるようにする。それにより、すでにAPI呼び出し認可をもっていないAPI呼び出しエンティティ（すなわち、該API呼び出しエンティティの認可が無効化されたか、または失効した）によってAPIを呼び出すことによって引き起こされる資源の無駄を回避する。たとえば、API呼び出しエンティティはもとの認可をもってAPIを呼び出し、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的には失敗する。結果として、AEFの処理資源が浪費される。さらに、AEFは、すでにAPI呼び出し認可をもたないAPI呼び出しエンティティのAPI呼び出しのためのサービス論理を実行することを防止され、それによりCAPIFシステムの作業効率が改善される。

図6に示されるように、本願のある実施形態は、さらに別の認可取り消し方法を提供する。本方法は、図1に示される枠組みに適用されてもよく、具体的には、以下のように記述される。

601. AEFが、API呼び出しエンティティの認可取り消し関連情報に基づいて、API呼び出しエンティティのAPI呼び出し認可を取り消す。

具体的には、ステップ601は、認可取り消し関連情報が事前設定された条件を満たすとき、AEFが、API呼び出しエンティティのAPI呼び出し認可を取り消すことを含んでいてもよい。

認可取り消し関連情報、取り消しなどについては、前述の諸実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

602. AEFが、認可取り消し通知メッセージをCCFに送信する。

認可取り消し通知メッセージは、以下のイベントを示すために使用されてもよい：
（1）API呼び出しエンティティによって特定のAPIを呼び出す認可が取り消される；または
（2）API呼び出しエンティティによってAEF上のすべてのAPIを呼び出す認可が取り消される。

任意的に、認可取り消し通知メッセージは、次の情報：API識別子、AEF識別子、特定の値、または取り消し原因値のうちの少なくとも1つの情報を担持する。

具体的には、認可取り消し通知メッセージがイベント（1）を示すために使用されるときは、認可取り消し通知メッセージは特定のAPIの識別子を担持してもよい；または
認可取り消し通知メッセージがイベント（2）を示すために使用されるときは、認可取り消し通知メッセージはAEF識別子を担持してもよく、AEF識別子はAEFを示すために使用される；または認可取り消し通知メッセージが特定の値を担持する；または認可取り消し通知メッセージが特定の値およびAEF識別子を担持し、特定の値とAEF識別子の組み合わせが、API呼び出しエンティティによってAEF上のすべてのAPIを呼び出す認可が取り消されることを通知するために使用される。

認可取り消し通知メッセージは、API呼び出しエンティティのAPI呼び出し認可管理を一緒に実装するために、API呼び出しエンティティとAPI呼び出し関係をもつ別のAEFと認可要求手順を実行するようCCFをトリガーしてもよい。認可取り消し通知メッセージは、具体的には、API呼び出し者認可取り消し通知（revoke API invoker authorization notify）メッセージであってもよい。

603. AEFが、API呼び出しエンティティに認可取り消し指示メッセージを送信する。

対応して、API呼び出しエンティティは認可取り消し指示メッセージを受信する。さらに、API呼び出しエンティティは、認可取り消し指示メッセージに基づいてAPI呼び出し認可情報を更新してもよい。

ある実装では、認可取り消し指示メッセージは、API呼び出しエンティティがCCFから新しいAPI呼び出し認可を要求するページにリダイレクトするか、またはAPI呼び出しエンティティがCCFとセキュリティ認証を実行するページにリダイレクトするよう、API呼び出しエンティティをトリガーしてもよい。それにより、API呼び出しエンティティは、まず最新のAPI呼び出し認可情報を取得することを強制されるか、または、APIは、API呼び出しエンティティが認可されたユーザーであることを再認証を通じて判別した後でのみ、その後のAPI呼び出しを実行するよう強制される。

任意的に、認可取り消し指示メッセージは、次の情報：API識別子、AEF識別子、特定の値、または取り消し原因値のうちの少なくとも1つの情報を担持する。

認可取り消し指示メッセージは、以下のイベントを示すために使用されてもよい：
（1）API呼び出しエンティティによって特定のAPIを呼び出す認可が取り消される；または
（2）API呼び出しエンティティによってAEF上のすべてのAPIを呼び出す認可が取り消される。

具体的には、認可取り消し指示メッセージがイベント（1）を示すために使用されるときは、認可取り消し指示メッセージは特定のAPIの識別子を担持してもよい；または
認可取り消し指示メッセージがイベント（2）を示すために使用されるときは、認可取り消し指示メッセージはAEF識別子を担持してもよく、AEF識別子がAEFを示すために使用される；または認可取り消し指示メッセージは特定の値を担持する；または、認可取り消し指示メッセージは特定の値およびAEF識別子を担持し、特定の値とAEF識別子の組み合わせが、API呼び出しエンティティによってAEF上のすべてのAPIを呼び出す認可が取り消されることを示すために使用される。

AEFは、API呼び出しエンティティのAPI呼び出し認可が取り消されたことを示すために、認可取り消し指示メッセージをAPI呼び出しエンティティに送信する。それにより、API呼び出しエンティティがAPI呼び出しエンティティによって取得された新しいAPI呼び出し認可情報に基づいてAPI呼び出し手順を開始できる。よって、無効にされた認可情報を用いてAPI呼び出し要求が開始されたために引き起こされる呼び出し拒否または呼び出し失敗が回避され、不必要な情報交換が回避され、それにより資源が節約でき、効率が改善できる。

認可取り消し指示メッセージは、具体的には、API呼び出し者認可取り消し通知（revoke API invoker authorization notify）メッセージであってもよい。

代替的に、ステップ603は、次のようなものであってもよい：CCFが、認可取り消し指示メッセージをAPI呼び出しエンティティに送信する。たとえば、認可取り消し通知メッセージを受信した後、CCFは認可取り消し指示メッセージをAPI呼び出しエンティティに送信する。さらに、任意的に、ステップ601の前に、この方法はさらに、AEFがAPI呼び出しエンティティの認可取り消し関連情報を取得することを含んでもいてもよい。

ステップ602およびステップ603は両方とも任意的なステップであることを注意しておくべきである。両ステップが実施されてもよく、または両ステップのうちの1つのみが実行されてもよく、または両ステップのいずれも実行されなくてもよい。制限は課されない。

任意的に、本方法は、以下をさらに含む：
604. API呼び出しエンティティが、APIを呼び出す認可をCCFから取得する。

ステップ604におけるAPIは、前述の諸ステップにおけるAPIと同じであってもよく、たとえば、APIは、前述の諸ステップにおけるAPIと同じであってもよく、または、前述の諸ステップにおけるAPIと部分的に同じであってもよく；または、APIは、前述の諸ステップにおけるAPIとは異なっていてもよい。制限は課されない。

6041. API呼び出しエンティティが、API認可取得要求メッセージを送信する。

API認可取得要求メッセージは、APIを呼び出すための認可を取得するために使用される。メッセージはAPI呼び出しエンティティの識別子を含んでいてもよい。任意的に、メッセージはAPIの識別子をさらに含む。

6042. CCFが、API呼び出しエンティティを認証する。

具体的には、ステップ6042は、CCFが、ユーザーが要求されたAPIを呼び出す許可を有するかどうかをチェックし；ユーザーが要求されたAPIを呼び出す許可を有する場合に認証が成功することを含んでいてもよい。

6043. CCFは、API呼び出しエンティティのサブスクリプション情報に基づいて、API呼び出しエンティティに、APIを呼び出す認可に関する情報を送信する。

一例では、API呼び出しエンティティのサブスクリプション情報、たとえばAPI呼び出しエンティティの識別子や時刻に基づいて、CCFはランダム文字列またはトークン（Token）を生成したり、またはAPI呼び出しエンティティとAPI呼び出しとの間のローカルに維持されるマッピング関係テーブルを更新したりしてもよい。次いで、CCFは、API呼び出しエンティティに対して、APIを呼び出す認可に関する前記情報を送信する。

APIを呼び出す認可に関する前記情報は、API呼び出しエンティティがAPIを呼び出すかアクセスする許可をもっていることを示すために使用されてもよく、具体的には、CCFによって生成され、API呼び出しエンティティに送信される前記ランダム文字列または前記トークン、または、CCF上でローカルに維持されている、API呼び出しエンティティとAPIの間の前記マッピング関係テーブルであってもよい。

本実施形態において提供される方法では、AEFは、API呼び出しエンティティの認可取り消し関連情報に基づいて、API呼び出しエンティティのAPI呼び出し認可を取り消し、認可取り消し通知メッセージをCCFに送信する。よって、API呼び出し認可管理が改善され、それによりAPI呼び出し認可をすでにもっていないAPI呼び出しエンティティ（すなわち、該API呼び出しエンティティの認可が無効にされているか、または期限切れになっている）によってAPIを呼び出すことによって引き起こされる資源の浪費を回避する。たとえば、API呼び出しエンティティがもとの認証でAPIを呼び出し、AEFはAPI呼び出しのためにサービス論理を実行するが、API呼び出しは最終的には失敗する。結果として、AEFの処理資源が浪費される。さらに、AEFは、すでにAPI呼び出し認可をもたないAPI呼び出しエンティティのAPI呼び出しのためのサービス論理を実行することを防止され、それによりCAPIFシステムの作業効率が改善される。

図7に示されるように、本願のある実施形態は、さらに別の認可取り消し方法を提供する。この方法は、図1に示される枠組みに適用されてもよく、具体的には、以下のように記述される。

701. AEFが、CCFからの認可取り消し通知メッセージを受信する。

認可取り消し通知メッセージは、API呼び出しエンティティの識別子を担持する。詳細については、前述の諸実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

702. AEFが、認可取り消し通知メッセージに基づき、API呼び出しエンティティのAPI呼び出し認可情報を更新する。

一例では、認可取り消し通知メッセージはAPI呼び出しエンティティの識別子を担持し、AEFはAPI呼び出しエンティティに関連するすべてのAPIの認可情報を更新してもよい。たとえば、AEFはAPI呼び出しエンティティがいかなるAPIを呼び出す許可ももたないことを記録し、これは具体的には、ブラックリストまたはホワイトリストを更新することによって実施されうる。制限は課されない。

別の例では、認可取り消し通知メッセージはAPI呼び出しエンティティの識別子とAPI識別子とを担持し、AEFはAPI識別子に対応するAPIの認可情報を更新してもよい。たとえば、ブラックリストがAPIに基づいている場合、API呼び出しエンティティの識別子は、ブラックリストにおけるAPI識別子に対応するAPIの関連する内容に追加されてもよい。制限は課されない。

この実施形態において提供される方法では、AEFは、CCFから認可取り消し通知メッセージを受信し、認可取り消し通知メッセージに基づいてAPI呼び出しエンティティのAPI呼び出し認可情報を更新する。それにより、AEFはAPI呼び出しエンティティの認可情報を適時に知ることができ、それにより、次の場合を回避する：API呼び出しエンティティがもとの認可をもってAPIを呼び出すときに、AEFが依然としてAPI呼び出しのためのサービス論理を実行してしまい、結果として、AEFの処理資源が無駄になる。

図8に示されるように、本願のある実施形態は、さらに別の認可取り消し方法を提供する。本方法は、図1に示す枠組みに適用されてもよく、具体的には、以下のように記述される。

801. API呼び出しエンティティが、第1のエンティティからの認可取り消し指示メッセージを受信する。

第1のエンティティは、AEFまたはCCFであってもよい。制限は課されない。

また、認可取り消し指示メッセージについては、前述の諸実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

802. API呼び出しエンティティが、認可取り消し指示メッセージに基づいてAPI呼び出し認可情報を更新する。

一例では、API呼び出しエンティティは、認可取り消し指示メッセージに基づいて、API呼び出し認可情報を記録してもよい。

さらに、本方法は、下記をさらに含んでいてもよい：
803. API呼び出しエンティティが、ローカルに記憶されているAPI呼び出し認可情報に基づいて、API呼び出し要求メッセージをAEFに送信する。

API呼び出し要求メッセージについては、前述の諸実施形態における関連する記述を参照されたい。詳細を再び述べることはしない。

本願で言及される「レコード」は「ストア」に置き換えてもよいことを注意しておくべきである。また、前述の更新動作の実行主体が、更新される必要のある関連情報を記憶していない場合には、「更新する」は「記憶する」に置き換えてもよい。制限は課されない。

この実施形態において提供される方法では、API呼び出しエンティティは、第1のエンティティから認可取り消し指示メッセージを受信し、認可取り消し指示メッセージに基づいてAPI呼び出し認可情報を更新する。それにより、API呼び出しエンティティは、API呼び出しエンティティの認可情報を適時に知ることができ、それにより、次の二つの場合を回避する：API呼び出しエンティティによるAPIの呼び出しのための認可情報が無効にされた／取り消されたことをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出すため、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的には失敗し、結果として、AEFの処理資源が無駄になる。さらに、API呼び出しエンティティの認可が無効にされるまたは期限切れになることをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出そうと試みるため、API呼び出しエンティティの処理資源が無駄になる。

図9に示されるように、本願のある実施形態は、装置を提供する。本装置は、第1のエンティティであってもよく、または第1のエンティティ内に位置されてもよく、たとえば、チップ上の一つまたは複数のチップまたはシステムであってもよい。本装置は、図2に示される実施形態における第1のエンティティの動作を実行するように構成されてもよく、または図4に示される実施形態におけるCCFの動作を実行するように構成されてもよく、または図5に示される実施形態におけるAEFの動作を実行するように構成されてもよい。制限は課されない。

本装置は、具体的には、受信ユニット901および処理ユニット902を含んでいてもよい。詳細は、次のとおり。

受信ユニット901は、第2のエンティティから認可取り消し要求メッセージを受信するように構成される。ここで、認可取り消し要求メッセージはAPI呼び出しエンティティの識別子を担持する。

処理ユニット902は、受信ユニット901によって受信された認可取り消し要求メッセージに基づいて、認可取り消し応答メッセージを第2のエンティティに送信するように構成される。

認可取り消し要求メッセージは、次の情報：API識別子、AEF識別子、特定の値、または取り消し原因値のうちの少なくとも1つの情報をさらに担持してもよい。取り消し原因値は、認可取り消し原因を示すために使用される。

任意的に、処理ユニット901は、以下のようにさらに構成される：
認可取り消し要求メッセージがAPI識別子をさらに担持するときは、API呼び出しエンティティによってAPI識別子に対応するAPIを呼び出すための認可を取り消す；または
認可取り消し要求メッセージがAPI識別子およびAEF識別子をさらに担持するときは、API呼び出しエンティティによって、AEF識別子に対応するAEF上にあり、API識別子に対応するAPIを呼び出す認可を取り消す。

任意的に、認可取り消し要求メッセージはAPI識別子を担持せず、処理ユニット902はさらに以下のように構成される：
API呼び出しエンティティによってAPI呼び出しエンティティに対応するCCF上のすべてのAPIを呼び出す認可を取り消す；または
認可取り消し要求メッセージがさらにAEF識別子を担持するときは、API呼び出しエンティティによってAEF識別子に対応するAEF上のすべてのAPIを呼び出す認可を取り消す；または
認可取り消し要求メッセージがさらに特定の値を担持するときは、API呼び出しエンティティによって、API呼び出しエンティティに対応するCCF上のすべてのAPIを呼び出す認可を取り消す。

任意的に、本装置はさらに、以下を含む：
認可取り消し指示メッセージをAPI呼び出しエンティティに送信するように構成された送信ユニット903。

認可取り消し指示メッセージは、次の情報：API識別子、AEF識別子、特定の値、または取り消し原因値のうちの少なくとも1つの情報を担持してもよい。

任意的に、第1のエンティティはAEFであり、第2のエンティティはAPI呼び出しエンティティに対応するCCFである；または、第1のエンティティがAPI呼び出しエンティティに対応するCCFであり、第2のエンティティがAEFである。

任意的に、第1のエンティティはAPI呼び出しエンティティに対応するCCFであり、第2のエンティティはAEFであり、処理ユニットは以下のようにさらに構成される：
API呼び出しエンティティによってAPI呼び出しエンティティに対応するCCF上のすべてのAPIを呼び出す認可を取り消した後、認可取り消し通知メッセージをCCFに対応するAEFに送信する。ここで、認可取り消し通知メッセージはAPI呼び出しエンティティの識別子を担持する。

この実施形態で提供される装置は、第2のエンティティから認可取り消し要求メッセージを受信する段階であって、認可取り消し要求メッセージは、API呼び出しエンティティの識別子を担持する、段階と；認可取り消し要求メッセージに基づいて認可取り消し応答メッセージを第2のエンティティに送信する段階とを実行する。よって、API呼び出し認可管理が改善され、それによりAPI呼び出し認可が適時に取り消されることができ、それにより、API呼び出し認可をすでにもっていないAPI呼び出しエンティティ（すなわち、該API呼び出しエンティティの許可は無効にされているか、または失効している）によってAPIを呼び出すことによって引き起こされる資源の浪費を回避する。たとえば、API呼び出しエンティティはもとの認証でAPIを呼び出し、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的には失敗する。結果として、AEFの処理資源が浪費される。さらに、AEFは、API呼び出し認可をすでにもっていないAPI呼び出しエンティティのAPI呼び出しのためのサービス論理を実行することを防止され、それによりCAPIFシステムの作業効率が改善される。

図10に示すように、本願の一実施形態は、別の装置を提供する。本装置は、第2のエンティティであってもよく、または、第2のエンティティ内に位置されてもよく、たとえば、一つまたは複数のチップまたはシステムオンチップであってもよい。本装置は、図3に示される実施形態における第2のエンティティの動作を実行するように構成されてもよく、または図4に示される実施形態におけるAEFの動作を実行するように構成されてもよく、または図5に示される実施形態におけるCCFの動作を実行するように構成されてもよい。制限は課されない。

本装置は、具体的には、送信ユニット1001および受信ユニット1002を含んでいてもよい。詳細は、次のとおり。

送信ユニット1001は、第1のエンティティに認可取り消し要求メッセージを送信するように構成される。ここで、認可取り消し要求メッセージがAPI呼び出しエンティティの識別子を運ぶ。

受信ユニット1002は、第1のエンティティからの認可取り消し応答メッセージを受信するように構成される。ここで、認可取り消し応答メッセージは、認可取り消しが成功または失敗することを示すために使用される。

任意的に、装置はさらに：
API呼び出しエンティティの認可取り消し関連情報に基づいて、送信ユニットを使用することによって、認可取り消し要求メッセージを第1のエンティティに送信するように構成されている処理ユニット1003を含む。

任意的に、認可取り消し関連情報は、API呼び出し失敗の回数を含んでいてもよく、処理ユニット1003は、以下のようにさらに：
API呼び出しの失敗の回数が閾値を超えた場合、送信ユニットを使用して認可取り消し要求メッセージを第1のエンティティに送信するように構成される。

任意的に、認可取り消し要求メッセージは、次の情報：API識別子、AEF識別子、特定の値、または取り消し原因値のうちの少なくとも1つの情報をさらに運ぶ。取り消し原因値は、認可取り消し原因を示すために使用される。

任意的に、第1のエンティティはAEFであり、第2のエンティティはCCFである；または第1のエンティティはCCFであり、第2のエンティティはAEFである。

任意的に、第2のエンティティはAEFであり、第1のエンティティはCCFである。

受信ユニット1001はさらに、API呼び出しエンティティからのAPI呼び出し要求メッセージを受信するように構成される。

送信ユニット1002はさらに、API呼び出しエンティティが、API呼び出し要求メッセージが呼び出すことを要求するために使用されるAPIを呼び出す認可をもたないとき、API呼び出し拒否メッセージをAPI呼び出しエンティティに送信するように構成される。

任意的に、送信ユニット1002は、さらに、API呼び出しエンティティに認可取り消し指示メッセージを送信するように構成される。

この実施形態で提供される装置は、認可取り消し要求メッセージを第1のエンティティに送信し、ここで、認可取り消し要求メッセージはAPI呼び出しエンティティの識別子を運び、第1のエンティティから認可取り消し応答メッセージを受信する。ここで、認可取り消し応答メッセージは、認可取り消しが成功または失敗することを示すために使用される。よって、API呼び出し認可管理が改善され、すでにAPI呼び出し認可をもっていないAPI呼び出しエンティティ（すなわち、そのAPI呼び出しエンティティの認可が無効にされているか、または失効している）がAPIを呼び出すことによって生じる資源の浪費を回避する。たとえば、API呼び出しエンティティはもとの認証を用いてAPIを呼び出し、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的には失敗する。結果として、AEFの処理資源が浪費される。さらに、AEFは、すでにAPI呼び出し認可をもっていないAPI呼び出しエンティティのAPI呼び出しのためのサービス論理を実行することを防止され、それによってCAPIFシステムの作業効率が改善される。

図11に示されるように、本願のある実施形態は、さらに別の装置を提供する。本装置は、AEFであってもよく、またはAEF内に位置されてもよく、たとえば、一つまたは複数のチップまたはシステムオンチップであってもよい。本装置は、図7に示される実施形態における方法を実行するように構成されてもよい。本装置は、受信ユニット1101および処理ユニット1102を含んでいてもよい。詳細は、次のとおり。

受信ユニット1101は、CCFからの認可取り消し通知メッセージを受信するように構成される。

処理ユニット1102は、認可取り消し通知メッセージに基づいて、API呼び出しエンティティのAPI呼び出し認可情報を更新するように構成される。

図12に示されるように、本願のある実施形態は、さらに別の装置を提供する。本装置は、API呼び出しエンティティであってもよく、またはAPI呼び出しエンティティ内に位置していてもよく、たとえば、一つまたは複数のチップまたはシステムオンチップであってもよい。本装置は、図8に示される実施形態における方法を実行するように構成されてもよい。本装置は、受信ユニット1201および処理ユニット1202を含んでいてもよい。詳細は、次のとおり。

受信ユニット1201は、第1のエンティティからの認可取り消し指示メッセージを受信するように構成される。

処理ユニット1202は、認可取り消し指示メッセージに基づいてAPI呼び出し認可情報を更新するように構成される。

第1のエンティティは、AEFまたはCCFでありうる。制限は課されない。

この実施形態において提供される装置は、第1のエンティティから認可取り消し指示メッセージを受信し、認可取り消し指示メッセージに基づいてAPI呼び出し情報を更新する。それにより、API呼び出しエンティティがAPI呼び出しエンティティの認可情報を適時に知ることができ、それにより、次の二つの場合を避ける：API呼び出しエンティティによるAPIの呼び出しのための認可情報が無効にされた／取り消されたことをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出すため、AEFはAPI呼び出しのためのサービス論理を実行するが、API呼び出しは最終的に失敗し、結果として、AEFの処理資源が無駄になる。さらに、API呼び出しエンティティの認可が無効にされるまたは期限切れになることをAPI呼び出しエンティティが知ることができないときに、API呼び出しエンティティが依然としてもとの認可を用いてAPIを呼び出そうと試みるため、API呼び出しエンティティの処理資源が無駄になる。

図13に示されるように、本願のある実施形態は、さらに別の装置を提供する。本装置は、AEFであってもよく、またはAEF内に位置されてもよく、たとえば、一つまたは複数のチップまたはシステムオンチップであってもよい。本装置は、図6に示される実施形態におけるAEFの動作を実行するように構成されてもよい。本装置は、処理ユニット1301および送信ユニット1302を含んでいてもよい。詳細は、次のとおり。

処理ユニット1301は、API呼び出しエンティティの認可取り消し関連情報に基づいて、API呼び出しエンティティのAPI呼び出し認可を取り消すように構成される。

送信ユニット1302は、CCFに認可取り消し通知メッセージを送信するように構成される。送信ユニット1302は、さらに、API呼び出しエンティティに認可取り消し指示メッセージを送信するように構成される。

本実施形態において提供される装置によれば、API呼び出しエンティティの状態は、API呼び出しエンティティについての認可取り消しを実装するためにリアルタイムでモニタリングされる。

本願の受信ユニットは、通信インターフェースで置き換えられてもよく、送信ユニットは通信インターフェースで置き換えられてもよいことを注意しておくべきである。通信インターフェースは、有線または無線方式で通信を実行してもよい。上述の装置がチップまたはシステムオンチップであるとき、上述の通信インターフェースは、入出力インターフェースであってもよく、またはバス・インターフェースであってもよい。また、受信ユニットと入れ替える通信インターフェースと、送信ユニットと入れ替える通信インターフェースは、同じであっても異なっていてもよい。制限は課されない。処理ユニットは、たとえば、中央処理ユニット（Central Processing Unit、CPU）であってもよく、特定用途向け集積回路（Application Specific Integrated Circuit、ASIC）であってもよく、または本発明の実施形態を実装するように構成された一つまたは複数の集積回路、たとえば、一つまたは複数のマイクロプロセッサ（Digital Signal Processor、DSP）または一つまたは複数のフィールドプログラマブルゲートアレイ（Field Programmable Gate Array、FPGA）であってもよい。制限は課されない。

図14に示されるように、ある実施形態は、さらに別の装置を提供する。本装置は、プロセッサ1401および通信インターフェース1402を含んでいてもよい。プロセッサ1401は、メモリに結合される。プロセッサ1401は、メモリ内のプログラムを呼び出すように構成され、前述の実施形態の各装置、たとえば、第1のエンティティ、AEF、CCF、またはAPI呼び出しエンティティの動作を実行するように構成される。

一つまたは複数のプロセッサ1401が存在してもよい。詳細については、前述の関連する記述を参照されたい。

通信インターフェース1402は、メモリと通信するためにプロセッサ1401によって使用される。

任意的に、本装置はメモリ1403を含む。メモリ1403は、プロセッサ1401に結合されており、具体的には一つまたは複数のメモリ1403があってもよい。メモリ1403は、静的情報および命令を記憶することができる読み出し専用メモリ（Read-Only Memory、ROM）または別の型の静的記憶装置、または情報および命令を記憶することができるランダムアクセスメモリ（Random Access Memory、RAM）または別の型の動的記憶装置であってもよく；または電気的に消去可能なプログラマブル読出し専用メモリ（Electrically Erasable Programmable Read-Only Memory、EEPROM）、コンパクトディスク読出し専用メモリ（Compact Disc Read-Only Memory、CD-ROM）または別のコンパクトディスク記憶、光ディスク記憶（コンパクトディスク、レーザーディスク、光ディスク、デジタル多用途ディスク、ブルーレイディスク等を含む）、磁気ディスク記憶媒体または別の磁気記憶デバイス、または予期されるプログラムコードを命令またはデータ構造の形で搬送または記憶するために使用でき、コンピュータによってアクセスされることができる他の任意の媒体であってもよい。しかしながら、メモリ1403は、これらに限定されない。

メモリ1403およびプロセッサ1401は、通信インターフェース1402を使用することによって互いに通信しうる。制限は課されない。

本願のある実施形態は、プログラムを提供する。プロセッサによって実行されるとき、プログラムは、前述の諸実施形態における装置の方法を実行するために使用される。

本願のある実施形態は、前述のプログラムを含むコンピュータ可読記憶媒体を提供する。

本願のある実施形態は、第1のエンティティおよび第2のエンティティを含むシステムを提供する。第1のエンティティは、図2に示される実施形態における動作を実行するように構成されてもよく、第2のエンティティは、図3に示される実施形態における動作を実行するように構成されてもよい。さらに、システムは、API呼び出しエンティティをさらに含んでいてもよい。API呼び出しエンティティは、図8に示される実施形態において対応するアクションを実行するように構成されてもよい。詳細を再び述べることはしない。

本願のある実施形態は、AEFおよびCCFを含む別のシステムを提供する。AEFおよびCCFは、それぞれ、図6に示す実施形態における対応する動作を実行するように構成されてもよい。

本願に開示される内容を参照して記載された方法またはアルゴリズムのステップは、ハードウェアを使用して実装されてもよく、またはソフトウェア命令を実行することによってプロセッサによって実装されてもよい。ソフトウェア命令は、対応するソフトウェア・モジュールを含んでいてもよい。ソフトウェア・モジュールは、ランダムアクセスメモリ（RAM）、フラッシュ・メモリ、読み出し専用メモリ、消去可能なプログラマブル読み出し専用メモリ（EPROM）、電気的に消去可能なプログラマブル読み出し専用メモリ（EEPROM）、レジスタ、ハードディスク、リムーバブル・ハードディスク、コンパクトディスク読み出し専用メモリ（CD-ROM）、または当該技術分野で周知の他の任意の形の記憶媒体に記憶されてもよい。例示的な記憶媒体はプロセッサに結合され、よって、プロセッサが記憶媒体から情報を読み出すことができ、記憶媒体に情報を書き込むことができる。もちろん、記憶媒体は、プロセッサの構成要素であってもよい。プロセッサおよび記憶媒体は、ASIC内に位置されてもよい。さらに、ASICは、コア・ネットワーク・インターフェース装置内に位置されてもよい。もちろん、プロセッサおよび記憶媒体は、コア・ネットワーク・インターフェース装置内に個別の構成要素として存在してもよい。

さらに、表示または議論された相互結合または直接結合または通信接続は、いくつかのインターフェースを使用することによって実装されてもよい。装置またはユニット間の間接的な結合または通信接続は、電気的または他の形で実施されてもよい。

以上の実装の記述に基づき、当業者は、本願は、必要なユニバーサル・ハードウェアに加えてソフトウェアを使用することによって、またはハードウェアのみを使用することによって、実装されうることを明確に理解しうる。ほとんどの状況では、前者がよりよい実装である。そのような理解に基づいて、本願の技術的解決策は本質的に、または先行技術に寄与する部分は、ソフトウェア製品の形で実装されてもよい。コンピュータソフトウェア製品は、コンピュータのフロッピーディスク、ハードディスク、または光ディスクのような読み出し可能な記憶媒体に記憶され、コンピュータ装置（これはパーソナルコンピュータ、サーバー、ネットワーク装置などであってもよい）に本願の諸実施形態に記載される方法を実行するように指示するためのいくつかの命令を含む。

Claims (41)

1. 認可取り消し方法であって：
   第1のエンティティによって、第2のエンティティからの認可取り消し要求メッセージを受信する段階であって、前記認可取り消し要求メッセージはAPI呼び出しエンティティの識別子を担持する、段階と；
   前記第1のエンティティによって、前記認可取り消し要求メッセージに基づいて、認可取り消し応答メッセージを第2のエンティティに送信する段階とを含む、
   方法。
2. 前記認可取り消し要求メッセージは、さらに、次の情報：アプリケーション・プログラミング・インターフェースAPI識別子、API露出機能AEF識別子、または取り消し原因値のうちの少なくとも1つの情報を担持し、前記取り消し原因値は、認可取り消し原因を示すために使用される、請求項１に記載の方法。
3. 前記認可取り消し要求メッセージがさらに前記API識別子を担持するとき、前記認可取り消し要求メッセージは、前記API呼び出しエンティティによって前記API識別子に対応するAPIを呼び出すための認可を取り消すよう要求するために使用される、請求項２に記載の方法。
4. 当該方法がさらに：
   前記API呼び出しエンティティによって前記API識別子に対応するAPIを呼び出すための認可を、前記第1のエンティティによって取り消す段階を含む、
   請求項３に記載の方法。
5. 前記認可取り消し要求メッセージが、API呼び出し者認可取り消し要求（revoke API invoker authorization request）である、請求項１ないし４のうちいずれか一項に記載の方法。
6. 当該方法がさらに：
   前記第1のエンティティによって、前記API呼び出しエンティティに認可取り消し指示メッセージを送信する段階を含む、
   請求項１ないし５のうちいずれか一項に記載の方法。
7. 前記認可取り消し指示メッセージが、次の情報：API識別子、AEF識別子、または取り消し原因値のうちの少なくとも1つの情報を担持する、請求項６に記載の方法。
8. 前記認可取り消し指示メッセージが、API呼び出し者認可取り消し通知（revoke API invoker authorization notify）メッセージである、請求項６または７に記載の方法。
9. 前記第1のエンティティがAEFであり、前記第2のエンティティが前記API呼び出しエンティティに対応する共通APIフレームワーク・コア機能CCFである；または前記第1のエンティティが前記API呼び出しエンティティに対応するCCFであり、前記第2のエンティティがAEFである、請求項１ないし８のうちいずれか一項に記載の方法。
10. 認可取り消し方法であって：
    第2のエンティティによって、認可取り消し要求メッセージを第1のエンティティに送信する段階であって、前記認可取り消し要求メッセージは、アプリケーション・プログラミング・インターフェースAPI呼び出しエンティティの識別子を担持する；段階と；
    前記第2のエンティティによって、前記第1のエンティティからの認可取り消し応答メッセージを受信する段階であって、前記認可取り消し応答メッセージは、認可取り消しが成功または失敗することを示すために使用される、段階とを含む、
    方法。
11. 第2のエンティティによって、認可取り消し要求メッセージを第1のエンティティに送信する前記段階が：
    前記第2のエンティティによって、前記API呼び出しエンティティの認可取り消し関連情報に基づいて、前記認可取り消し要求メッセージを前記第1のエンティティに送信することを含む、
    請求項１０に記載の方法。
12. 前記認可取り消し関連情報は：API呼び出し失敗の回数を含み、前記第2のエンティティによって、前記API呼び出しエンティティの認可取り消し関連情報に基づいて、前記認可取り消し要求メッセージを前記第1のエンティティに送信することは：
    API呼び出し失敗の回数が閾値を超えるときに、前記認可取り消し要求メッセージを前記第1のエンティティに送信することを含む、
    請求項１１に記載の方法。
13. 前記認可取り消し要求メッセージは、さらに、次の情報：API識別子、API露出機能AEF識別子、または取り消し原因値のうちの少なくとも1つの情報を含み、前記取り消し原因値は、認可取り消し原因を示すために使用される、請求項１０ないし１２のうちいずれか一項に記載の方法。
14. 前記認可取り消し要求メッセージがさらに前記API識別子を担持するとき、前記認可取り消し要求メッセージは、前記API呼び出しエンティティによって前記API識別子に対応するAPIを呼び出すための認可を取り消すことを要求するために使用される、請求項１３に記載の方法。
15. 前記認可取り消し要求メッセージがAPI呼び出し者認可取り消し要求（revoke API invoker authorization request）である、請求項１０ないし１４のうちいずれか一項に記載の方法。
16. 前記第1のエンティティがAEFであり、前記第2のエンティティが共通APIフレームワーク・コア機能CCFである；または前記第1のエンティティがCCFであり、前記第2のエンティティがAEFである、請求項１０ないし１５のうちいずれか一項に記載の方法。
17. 前記第2のエンティティがAEFであり、前記第1のエンティティがCCFであり、当該方法がさらに：
    前記第2のエンティティによって、前記API呼び出しエンティティからAPI呼び出し要求メッセージを受信する段階と；
    前記API呼び出し要求メッセージが呼び出すことを要求するために使用されるAPIを呼び出すための認可を前記API呼び出しエンティティがもたないとき、前記第2のエンティティによって、API呼び出し拒否メッセージを前記API呼び出しエンティティに送信する段階とを含む、
    請求項１６に記載の方法。
18. 当該方法が、さらに：
    前記第2のエンティティによって、前記API呼び出しエンティティに認可取り消し指示メッセージを送信する段階を含む、
    請求項１６または１７に記載の方法。
19. 装置であって、当該装置は、第1のエンティティである、または前記第1のエンティティ内に位置し、当該装置は：
    第2のエンティティからの認可取り消し要求メッセージを受信するように構成された受信ユニットであって、前記認可取り消し要求メッセージはアプリケーション・プログラミング・インターフェースAPI呼び出しエンティティの識別子を担持する、受信ユニットと；
    前記受信ユニットによって受信された認可取り消し要求メッセージに基づいて、認可取り消し応答メッセージを前記第2のエンティティに送信するように構成された処理ユニットとを有する、
    装置。
20. 前記認可取り消し要求メッセージは、さらに、次の情報：API識別子、API露出機能AEF識別子、または取り消し原因値のうちの少なくとも1つの情報を担持し、前記取り消し原因値は、認可取り消し原因を示すために使用される、請求項１９に記載の装置。
21. 前記認可取り消し要求メッセージがさらに前記API識別子を担持するとき、前記認可取り消し要求メッセージは、前記API呼び出しエンティティによって前記API識別子に対応するAPIを呼び出すための認可を取り消すよう要求するために使用される、請求項２０に記載の装置。
22. 前記処理ユニットがさらに：
    前記API呼び出しエンティティによって前記API識別子に対応するAPIを呼び出すための認可を取り消すように構成されている、
    請求項２１に記載の装置。
23. 前記認可取り消し要求メッセージが、API呼び出し者認可取り消し要求（revoke API invoker authorization request）である、請求項１９ないし２２のうちいずれか一項に記載の装置。
24. 当該装置がさらに：
    前記API呼び出しエンティティに認可取り消し指示メッセージを送信するよう構成された送信ユニットを有する、
    請求項１９ないし２３のうちいずれか一項に記載の装置。
25. 前記認可取り消し指示メッセージが、次の情報：API識別子、AEF識別子、または取り消し原因値のうちの少なくとも1つの情報を担持する、請求項２４に記載の装置。
26. 前記認可取り消し指示メッセージが、API呼び出し者認可取り消し通知（revoke API invoker authorization notify）メッセージである、請求項２４または２５に記載の装置。
27. 前記第1のエンティティがAEFであり、前記第2のエンティティが前記API呼び出しエンティティに対応する共通APIフレームワーク・コア機能CCFである；または前記第1のエンティティが前記API呼び出しエンティティに対応するCCFであり、前記第2のエンティティがAEFである、請求項１９ないし２６のうちいずれか一項に記載の装置。
28. 装置であって、当該装置は第2のエンティティである、または前記第2のエンティティ内に位置し、当該装置は：
    第1のエンティティに認可取り消し要求メッセージを送信するように構成された送信ユニットであって、前記認可取り消し要求メッセージはアプリケーション・プログラミング・インターフェースAPI呼び出しエンティティの識別子を担持する、送信ユニットと；
    前記第1のエンティティからの認可取り消し応答メッセージを受信するように構成された受信ユニットであって、前記認可取り消し応答メッセージは、認可取り消しが成功または失敗することを示すために使用される、受信ユニットとを有する、
    装置。
29. 当該装置がさらに：
    前記API呼び出しエンティティの認可取り消し関連情報に基づいて、前記送信ユニットを使用することによって、前記認可取り消し要求メッセージを前記第1のエンティティに送信するように構成された処理ユニットを有する、
    請求項２８に記載の装置。
30. 前記認可取り消し関連情報は：API呼び出し失敗の回数を含み、前記処理ユニットは：
    API呼び出し失敗の回数が閾値を超えるときに、前記送信ユニットを使用することによって、前記認可取り消し要求メッセージを前記第1のエンティティに送信するように構成されている、
    請求項２９に記載の装置。
31. 前記認可取り消し要求メッセージは、さらに、次の情報：API識別子、API露出機能AEF識別子、または取り消し原因値のうちの少なくとも1つの情報を含み、前記取り消し原因値は、認可取り消し原因を示すために使用される、請求項２８ないし３０のうちいずれか一項に記載の装置。
32. 前記認可取り消し要求メッセージがさらに前記API識別子を担持するとき、前記認可取り消し要求メッセージは、前記API呼び出しエンティティによって前記API識別子に対応するAPIを呼び出すための認可を取り消すことを要求するために使用される、請求項３１に記載の装置。
33. 前記認可取り消し要求メッセージがAPI呼び出し者認可取り消し要求（revoke API invoker authorization request）である、請求項２８ないし３２のうちいずれか一項に記載の装置。
34. 前記第1のエンティティがAEFであり、前記第2のエンティティが共通APIフレームワーク・コア機能CCFである；または前記第1のエンティティがCCFであり、前記第2のエンティティがAEFである、請求項２８ないし３３のうちいずれか一項に記載の装置。
35. 前記第2のエンティティがAEFであり、前記第1のエンティティがCCFであり；
    前記受信ユニットがさらに、前記API呼び出しエンティティからAPI呼び出し要求メッセージを受信するように構成されており；
    前記送信ユニットがさらに：前記API呼び出し要求メッセージが呼び出すことを要求するために使用されるAPIを呼び出すための認可を前記API呼び出しエンティティがもたないとき、API呼び出し拒否メッセージを前記API呼び出しエンティティに送信するように構成されている、
    請求項３４に記載の装置。
36. 前記送信ユニットがさらに：
    前記API呼び出しエンティティに認可取り消し指示メッセージを送信するよう構成されている、
    請求項３４または３５に記載の装置。
37. 装置であって、当該装置は第1のエンティティである、または前記第1のエンティティ内に位置し、当該装置はプロセッサ、メモリ、およびバスを有しており、
    前記プロセッサと前記メモリは、前記バスを使用して互いに通信し；
    前記メモリはプログラムを記憶するように構成されており；
    前記プロセッサは、前記メモリに記憶されたプログラムを実行して、請求項１ないし９のうちいずれか一項に記載の方法を実行するように構成されている、
    装置。
38. 装置であって、当該装置は第2のエンティティである、または前記第2のエンティティ内に位置し、当該装置はプロセッサ、メモリ、およびバスを有しており、
    前記プロセッサと前記メモリは、前記バスを使用して互いに通信し；
    前記メモリはプログラムを記憶するように構成されており；
    前記プロセッサは、前記メモリに記憶されたプログラムを実行して、請求項１０ないし１８のうちいずれか一項に記載の方法を実行するように構成されている、
    装置。
39. 記憶媒体であって、当該記憶媒体は、プログラムを記憶するように構成されており、
    前記プログラムは、請求項１ないし１８のうちいずれか一項に記載の方法を実行するために、プロセッサによって使用される、
    記憶媒体。
40. 請求項１ないし１８のうちいずれか一項に記載の方法を実行するために、プロセッサによって使用されるプログラムコードを有するコンピュータプログラム製品。
41. 通信システムであって、当該システムは、第1のエンティティおよび第2のエンティティを含み、
    前記第1のエンティティが、請求項１ないし９のうちいずれか一項に記載の方法を実行するように構成されており；
    前記第2のエンティティが、請求項１０ないし１８のうちいずれか一項に記載の方法を実行するように構成されている、
    システム。

Images