RU2792657C2 - Способ вызова сервисного api и соответствующее устройство - Google Patents

Abstract

Группа изобретений относится к области технологий связи и предоставляет способ вызова сервисного интерфейса прикладного программирования (API). Техническим результатом является обеспечение возможности успешного вызова сервисного API при обновлении метода безопасности. Способ содержит этапы, на которых отправляют посредством инициатора второй запрос вызова в субъект функции предоставления API с использованием исходного метода безопасности, причем второй запрос вызова используется для вызова сервисного API; принимают посредством инициатора ответное сообщение на второй запрос вызова от субъекта функции предоставления API, причем ответное сообщение на второй запрос вызова содержит значение причины, и значение причины указывает то, что не удается вызвать сервисный API из-за несоответствия метода безопасности; получают посредством инициатора новый метод безопасности субъекта функции предоставления API; и отправляют посредством инициатора первый запрос вызова в субъект функции предоставления API с использованием нового метода безопасности, при этом первый запрос вызова содержит имя сервисного API, и первый запрос вызова используется для вызова сервисного API. 9 н. и 25 з.п. ф-лы, 10 ил.

Description

[0001] Настоящая заявка испрашивает приоритет на основании патентной заявки Китая №201810312734.1, поданной в Национальное управление интеллектуальной собственности Китая 9 апреля 2018 г. и озаглавленной «SERVICE API INVOKING METHOD AND RELATED APPARATUS», которая полностью включена в настоящий документ посредством ссылки.

Область техники

[0002] Настоящая заявка относится к области коммуникационных технологий и, в частности, к способу вызова служебного API и соответствующему устройству.

Уровень техники

[0003] Проект партнерства 3-го поколения (3^rd Generation Partnership Project, 3GPP) определяет множество спецификаций, относящихся к восходящему (northbound) интерфейсу прикладного программирования (application programming interface, API). Чтобы избежать повторения и несогласованности между различными спецификациями API, 3GPP рассматривает возможность разработки общей инфраструктуры API (common API framework, CAPIF), которая имеет общие характеристики, применимые ко всем восходящим API. Обычно CAPIF развертывается в сети оператора связи.

[0004] Фиг.1 - схематическая диаграмма архитектуры, основывающейся на CAPIF. Архитектура, показанная на Фиг.1, в основном включает в себя следующие сетевые элементы:

[0005] Сторона, вызывающая API (инициатор API, API invoker): инициатор API обычно предоставляется сторонним поставщиком приложений, у которого есть сервисное соглашение с сетью оператора связи.

[0006] Сервисный API (service API): сервисный API - это интерфейс, через который сервис предоставляется для инициатора API.

[0007] Субъект функции ядра CAPIF (CAPIF core function): субъект функции ядра CAPIF является центральным хранилищем всех политик сервисных API, а также центром инициатора API и сервисного API для аутентификации и авторизации.

[0008] API CAPIF: API CAPIF - это интерфейс, посредством использования которого для инициатора API предоставляется вход субъекта функции ядра CAPIF.

[0009] Субъект функции предоставления API (API exposing function, AEF): субъект функции предоставления API - это вход для поставщика сервисов, позволяющий открывать сервисы для внешних систем. Инициатор API может использовать, посредством использования субъекта AEF, сервис, предоставляемый поставщиком сервисов.

[0010] Субъект функции публикации API (API publishing function): субъект функции публикации API может публиковать информацию о сервисном API для субъекта функции ядра CAPIF, с тем чтобы инициатор API находил информацию о сервисном API в субъекте функции ядра CAPIF.

[0011] Субъект функции управления API (API management function): субъект функции управления API управляет сервисным API, например, отслеживая состояние сервисного API и записывая информацию о вызовах.

[0012] На Фиг.1 домен доверия наземной мобильной сети общего пользования (public land mobile network trust domain, PLMN trust domain) представляет собой область, которой доверяет наземная мобильная сеть общего пользования. Домен поставщика API (API provider domain) представляет собой область, в которой находится поставщик API.

[0013] Отношение соединения между вышеупомянутыми сетевыми элементами следующее:

[0014] Интерфейс между инициатором API вне домена доверия PLMN и субъектом функции ядра CAPIF является интерфейсом CAPIF-1e, а интерфейс между инициатором API вне домена доверия PLMN и субъектом AEF - интерфейсом CAPIF-2e. Интерфейс между инициатором API в домене доверия PLMN и субъектом функции ядра CAPIF является интерфейсом CAPIF-1, и интерфейс между инициатором API и субъектом AEF - интерфейсом CAPIF-2. Интерфейс между субъектом функции ядра CAPIF и субъектом AEF - это интерфейс CAPIF-3, интерфейс между субъектом функции ядра CAPIF и субъектом функции публикации API - это интерфейс CAPIF-4, и интерфейс между субъектом функции ядра CAPIF и функцией управления API - это интерфейс CAPIF-5.

[0015] В настоящее время, прежде чем инициатор API вызовет сервисный API, инициатор API и субъект функции ядра CAPIF согласовывают метод безопасности, используемый между инициатором API и субъектом AEF. Затем при вызове сервисного API инициатор API вызывает сервисный API из субъекта AEF, используя метод безопасности. Однако случай, в котором метод безопасности обновляется, не учитывается в существующем способе, если метод безопасности обновлен, но инициатор API все еще использует исходный метод безопасности для вызова сервисного API, сервисный API не может быть успешно вызван.

Сущность изобретения

[0016] Варианты осуществления настоящей заявки предоставляют способ вызова сервисного API и соответствующее устройство, чтобы избежать проблемы, заключающейся в том, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0017] Согласно первому аспекту, вариант осуществления настоящей заявки предоставляет способ вызова сервисного API. Метод безопасности, применяемый к субъекту функции предоставления API, обновляется с исходного метода безопасности на новый метод безопасности, и метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором. Способ включает в себя этапы, на которых: получают посредством инициатора новый метод безопасности субъекта функции предоставления API; и отправляют посредством инициатора первый запрос вызова в субъект функции предоставления API с использованием нового метода безопасности, причем первый запрос вызова включает в себя имя сервисного API, и первый запрос вызова используется для вызова сервисного API.

[0018] То, что метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором, может включать в себя следующее: метод безопасности субъекта функции предоставления API используется для аутентификации, авторизации и защиты между субъектом функции предоставления API и инициатором.

[0019] В соответствии с решением согласно этому варианту осуществления настоящей заявки, когда обновляется метод безопасности субъекта функции предоставления API, инициатор может получить новый метод безопасности субъекта функции предоставления API и вызвать сервисный API из субъекта функции предоставления API с помощью нового метода безопасности, чтобы избежать проблемы, заключающейся в том, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0020] В возможной конструкции инициатор может получить новый метод безопасности субъекта функции предоставления API следующими путями: В соответствии с первым путем, инициатор получает новый метод безопасности от субъекта функции ядра общей инфраструктуры API (CAPIF); и, в соответствии со вторым путем, инициатор получает новый метод безопасности от субъекта функции предоставления API.

[0021] В одном примере, когда используется первый путь, до того, как инициатор получит новый метод безопасности от субъекта функции ядра общей инфраструктуры API (CAPIF), инициатор может дополнительно запросить новый метод безопасности у субъекта функции ядра CAPIF. Например, инициатор может отправить запрос получения в субъект функции ядра CAPIF, где запрос получения используется для запрашивания нового метода безопасности.

[0022] В другом примере, когда используется второй путь, до того, как инициатор получит новый метод безопасности субъекта функции предоставления API, инициатор может дополнительно отправить запрос согласования метода безопасности в субъект функции предоставления API, каковой запрос согласования метода безопасности включает в себя список методов безопасности, поддерживаемых инициатором, и список методов безопасности включает в себя новый метод безопасности. Соответственно, инициатор может получить ответ по согласованию метода безопасности от субъекта функции предоставления API, где ответ по согласованию метода безопасности включает в себя новый метод безопасности.

[0023] В этой конструкции и в двух предыдущих примерах этой конструкции перед тем, как инициатор получит новый метод безопасности субъекта функции предоставления API, инициатор может дополнительно отправить второй запрос вызова в субъект функции предоставления API с использованием исходного метода безопасности, где второй запрос вызова используется для вызова сервисного API; и получить ответное сообщение на второй запрос вызова от субъекта функции предоставления API, где ответное сообщение на второй запроса вызова включает в себя значение причины, и значение причины используется для указания того, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0024] В еще одном примере, когда используется второй путь, до того, как инициатор получит новый метод безопасности от субъекта функции предоставления API, инициатор может дополнительно отправить третий запрос вызова в субъект функции предоставления API с использованием исходного метода безопасности, причем третий запрос вызова используется для вызова сервисного API. Соответственно, инициатор может получить ответное сообщение на третий запрос вызова от субъекта функции предоставления API, при этом ответное сообщение на третий запрос вызова включает в себя новый метод безопасности и значение причины, где значение причины используется для указания того, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0025] В возможной конструкции инициатор может дополнительно получить ответное сообщение на первый запрос вызова от субъекта функции предоставления API, где ответное сообщение на первый запрос вызова используется для указания того, что сервисный API успешно вызван.

[0026] Согласно второму аспекту, вариант осуществления настоящей заявки обеспечивает другой способ вызова сервисного интерфейса прикладного программирования (API). Метод безопасности, применяемый к субъекту функции предоставления API, обновляется с исходного метода безопасности на новый метод безопасности, и метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором. Способ включает в себя этапы, на которых: принимают посредством субъекта функции ядра общей инфраструктуры API (CAPIF) запрос обновления для функции предоставления API от субъекта функции публикации API, причем запрос обновления включает в себя новый метод безопасности функции предоставления API; и сохраняют посредством субъекта функции ядра CAPIF новый метод безопасности.

[0027] При этом то, что метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором, может включать в себя следующее: метод безопасности субъекта функции предоставления API используется для аутентификации, авторизации и защиты между субъектом функции предоставления API и инициатором.

[0028] В возможной конструкции субъект функции ядра CAPIF может дополнительно посылать новый метод безопасности в инициатор.

[0029] В возможной конструкции запрос обновления может дополнительно включать в себя информацию указания, где информация указания используется для предписания субъекту функции ядра CAPIF отправить новый метод безопасности в инициатор.

[0030] В другой возможной конструкции, прежде чем субъект функции ядра CAPIF отправит новый метод безопасности в инициатор, субъект функции ядра CAPIF может дополнительно принимать запрос получения от инициатора, где запрос получения используется для запрашивания нового метода безопасности.

[0031] В возможной конструкции субъект функции ядра CAPIF может сохранять соответствие между инициатором, новым методом безопасности и субъектом функции предоставления API.

[0032] Согласно третьему аспекту, вариант осуществления настоящей заявки предоставляет еще один способ вызова сервисного интерфейса прикладного программирования (API). Метод безопасности, применяемый к субъекту функции предоставления API, обновляется с исходного метода безопасности на новый метод безопасности, и метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором. Способ включает в себя этапы, на которых: принимают посредством субъекта функции предоставления API первый запрос вызова, отправленный инициатором с использованием нового метода безопасности, где первый запрос вызова включает в себя имя сервисного API, и первый запрос вызова используется для вызова сервисного API; и проверяют, посредством субъекта функции предоставления API, инициатор с использованием нового метода безопасности.

[0033] При этом то, что метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором, может включать в себя следующее: метод безопасности субъекта функции предоставления API используется для аутентификации, авторизации и защиты между субъектом функции предоставления API и инициатором.

[0034] В возможной конструкции, прежде чем субъект функции предоставления API примет первый запрос вызова, отправленный инициатором с использованием нового метода безопасности, субъект функции предоставления API может дополнительно отправить новый метод безопасности в инициатор.

[0035] В примере, перед тем как субъект функции предоставления API отправит новый метод безопасности в инициатор, субъект функции предоставления API может дополнительно принять запрос согласования метода безопасности от инициатора, причем запрос согласования метода безопасности включает в себя список методов безопасности, поддерживаемых инициатором, и список методов безопасности включает в себя новый метод безопасности; и отправить ответ по согласованию метода безопасности в инициатор, где ответ по согласованию метода безопасности включает в себя новый метод безопасности.

[0036] В возможной конструкции, прежде чем субъект функции предоставления API отправит новый метод безопасности в инициатор, субъект функции предоставления API может дополнительно принять второй запрос вызова, отправленный инициатором с использованием исходного метода безопасности, при этом второй запрос вызова используется для вызова сервисного API; и отправить ответное сообщение на второй запрос вызова в инициатор, где сообщение ответа второго запроса вызова используется для указания того, что сервисный API не может быть вызван.

[0037] В примере ответное сообщение на второй запрос вызова включает в себя значение причины, и значение причины используется для указания того, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0038] В возможной конструкции, прежде чем субъект функции предоставления API отправит новый метод безопасности в инициатор, субъект функции предоставления API может дополнительно принять третий запрос вызова, отправленный инициатором с использованием исходного метода безопасности, при этом третий запрос вызова используется для вызова сервисного API. Соответственно, субъект функции предоставления API может отправить ответное сообщение на третий запрос вызова в инициатор, где ответное сообщение на третий запрос вызова включает в себя новый метод безопасности субъекта функции предоставления API и значение причины, причем значение причины используется для указания того, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0039] В возможной конструкции субъект функции предоставления API может дополнительно отправлять ответное сообщение на первый запрос вызова в инициатор, где ответное сообщение на первый запрос вызова используется для указания того, что сервисный API успешно вызван.

[0040] Согласно четвертому аспекту, вариант осуществления настоящей заявки предоставляет способ вызова сервисного API. Метод безопасности, применяемый к сервисному интерфейсу прикладного программирования (API), обновляется с исходного метода безопасности на новый метод безопасности. Способ включает в себя этапы, на которых: принимают посредством инициатора новый метод безопасности сервисного API; и отправляют посредством инициатора первый запрос вызова в субъект функции предоставления API с использованием нового метода безопасности, при этом первый запрос вызова включает в себя имя сервисного API, и первый запрос вызова используется для вызова сервисного API.

[0041] В соответствии с решением в этом варианте осуществления настоящей заявки, когда метод безопасности сервисного API обновляется, инициатор может получить новый метод безопасности сервисного API вовремя и вызвать сервисный API из субъекта функции предоставления API используя новый метод безопасности, чтобы избежать проблемы, заключающейся в том, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0042] В возможной конструкции инициатор может получить новый метод безопасности сервисного API следующими путями: в соответствии с первым путем, инициатор получает новый метод безопасности от субъекта функции ядра общей инфраструктуры API (CAPIF); и, в соответствии со вторым путем: инициатор получает новый метод безопасности от субъекта функции предоставления API.

[0043] В одном примере, когда используется первый путь, до того, как инициатор получит новый метод безопасности от субъекта функции ядра общей инфраструктуры API (CAPIF), инициатор может дополнительно запросить новый метод безопасности у субъекта функции ядра CAPIF. Например, инициатор может отправить запрос получения в субъект функции ядра CAPIF, каковой запрос получения используется для запрашивания нового метода безопасности.

[0044] В другом примере, когда используется второй путь, до того, как инициатор получит новый метод безопасности сервисного API, инициатор может дополнительно отправить запрос согласования метода безопасности в субъект функции предоставления API, каковой запрос согласования метода безопасности включает в себя список методов безопасности, поддерживаемых инициатором, и список методов безопасности включает в себя новый метод безопасности. Соответственно, инициатор может принять ответ по согласованию метода безопасности от субъекта функции предоставления API, где ответ по согласованию метода безопасности включает в себя новый метод безопасности.

[0045] В этой схеме и в двух предыдущих примерах этой схемы перед тем, как инициатор получит новый метод безопасности сервисного API, инициатор может дополнительно отправить второй запрос вызова в субъект функции предоставления API с использованием исходного метода безопасности, прием второй запрос вызова используется для вызова сервисного API; и принять ответное сообщение на второй запрос вызова от субъекта функции предоставления API, где ответное сообщение на второй запрос вызова включает в себя значение причины, и значение причины используется для указания того, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0046] В еще одном примере, когда используется второй путь, до того, как инициатор получит новый метод безопасности от субъекта функции предоставления API, инициатор может дополнительно отправить третий запрос вызова в субъект функции предоставления API с использованием исходного метода безопасности, причем третий запрос вызова используется для вызова сервисного API. Соответственно, инициатор может принять ответное сообщение на третий запрос вызова от субъекта функции предоставления API, где ответное сообщение на третий запрос вызова включает в себя новый метод безопасности и значение причины, и значение причины используется для указания того, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0047] В возможной конструкции инициатор может дополнительно принимать ответное сообщение на первый запрос вызова от субъекта функции предоставления API, где ответное сообщение на первый запрос вызова используется для указания того, что сервисный API успешно вызван.

[0048] Согласно пятому аспекту, вариант осуществления настоящей заявки предоставляет еще один способ вызова сервисного интерфейса прикладного программирования (API). Метод безопасности, применяемый к сервисному интерфейсу прикладного программирования (API), обновляется с исходного метода безопасности на новый метод безопасности. Способ включает в себя этапы, на которых: принимают посредством субъекта функции ядра общей инфраструктуры API (CAPIF) запрос обновления для функции предоставления API от субъекта функции публикации API, при этом запрос обновления включает в себя новый метод безопасности сервисного API; и сохраняют посредством субъекта функции ядра CAPIF новый метод безопасности.

[0049] В возможной конструкции субъект функции ядра CAPIF может дополнительно посылать новый метод безопасности в инициатор.

[0050] В возможной конструкции запрос обновления может дополнительно включать в себя информацию указания, где информация указания используется для предписания субъекту функции ядра CAPIF отправить новый метод безопасности в инициатор.

[0051] В другой возможной конструкции, прежде чем субъект функции ядра CAPIF отправит новый метод безопасности в инициатор, субъект функции ядра CAPIF может дополнительно принять запрос получения от инициатора, где запрос получения используется для запрашивания нового метода безопасности.

[0052] В возможной конструкции субъект функции ядра CAPIF может сохранять соответствие между идентификатором инициатора, новым методом безопасности и именем сервисного API. Например, субъект функции ядра CAPIF может сохранять соответствие между идентификатором инициатора, новым методом безопасности, именем сервисного API и субъектом функции предоставления API.

[0053] Согласно шестому аспекту, вариант осуществления настоящей заявки предоставляет еще один способ вызова сервисного интерфейса прикладного программирования (API). Метод безопасности, применяемый к сервисному интерфейсу прикладного программирования (API), обновляется с исходного метода безопасности на новый метод безопасности. Способ включает в себя этапы, на которых: принимают посредством субъекта функции предоставления API первый запрос вызова, отправленный инициатором с использованием нового метода безопасности, где первый запрос вызова включает в себя имя сервисного API, и первый запрос вызова используется для вызова сервисного API; и проверяют посредством субъекта функции предоставления API инициатор с использованием нового метода безопасности.

[0054] В возможной конструкции, прежде чем субъект функции предоставления API примет первый запрос вызова, отправленный инициатором с использованием нового метода безопасности, субъект функции предоставления API может дополнительно отправить новый метод безопасности в инициатор.

[0055] В примере, перед тем как субъект функции предоставления API отправит новый метод безопасности в инициатор, субъект функции предоставления API может дополнительно принять запрос согласования метода безопасности от инициатора, где запрос согласования метода безопасности включает в себя список методов безопасности, поддерживаемых инициатором, и список методов безопасности включает в себя новый метод безопасности; и отправить ответ по согласованию метода безопасности в инициатор, где ответ по согласованию метода безопасности включает в себя новый метод безопасности.

[0056] В возможной конструкции, прежде чем субъект функции предоставления API отправит новый метод безопасности в инициатор, субъект функции предоставления API может дополнительно принять второй запрос вызова, отправленный инициатором с использованием исходного метода безопасности, где второй запрос вызова используется для вызова сервисного API; и отправить ответное сообщение на второй запрос вызова в инициатор, где ответное сообщение на второй запрос вызова используется для указания того, что сервисный API не может быть вызван.

[0057] В примере ответное сообщение на второй запрос вызова включает в себя значение причины, и значение причины используется для указания того, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0058] В возможной конструкции, прежде чем субъект функции предоставления API отправит новый метод безопасности в инициатор, субъект функции предоставления API может дополнительно принять третий запрос вызова, отправленный инициатором с использованием исходного метода безопасности, где третий запрос вызова используется для вызова сервисного API. Соответственно, субъект функции предоставления API может отправить ответное сообщение на третий запрос вызова в инициатор, где ответное сообщение на третий запрос вызова включает в себя новый метод безопасности субъекта функции предоставления API и значение причины, и значение причины используется для указания того, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0059] В возможной конструкции субъект функции предоставления API может дополнительно отправлять ответное сообщение на первый запрос вызова в инициатор, при этом ответное сообщение на первый запрос вызова используется для указания того, что сервисный API успешно вызван.

[0060] Согласно седьмому аспекту, вариант осуществления настоящей заявки предоставляет устройство. Устройство имеет функцию реализации функционирования инициатора в вышеупомянутом проекте способа. Функция может быть реализована посредством аппаратных средств или может быть реализована посредством исполнения аппаратными средствами соответствующего программного обеспечения. Аппаратные средства или программное обеспечение включают в себя один или более модулей, соответствующих вышеуказанной функции. Например, устройство может быть инициатором или может быть микросхемой в инициаторе.

[0061] В возможной конструкции устройство является инициатором, при этом инициатор включает в себя процессор, и процессор сконфигурирован для поддержки инициатора при выполнении соответствующей функции в вышеупомянутом способе. Кроме того, инициатор может дополнительно включать в себя интерфейс связи, причем интерфейс связи сконфигурирован для поддержки связи между инициатором и субъектом плоскости пользователя из состава централизованного блока или связи между инициатором и другим сетевым элементом. Кроме того, инициатор может дополнительно включать в себя память, причем память приспособлена для соединения с процессором и в памяти хранятся программные инструкции и данные, которые необходимы инициатору.

[0062] Согласно восьмому аспекту, вариант осуществления настоящей заявки предоставляет устройство. Устройство имеет функцию реализации функционирования субъекта функции ядра CAPIF в вышеупомянутом проекте способа. Функция может быть реализована посредством аппаратных средств или может быть реализована посредством исполнения аппаратными средствами соответствующего программного обеспечения. Аппаратные средства или программное обеспечение включают в себя один или несколько модулей, соответствующих вышеуказанной функции. Например, устройство может быть субъектом функции ядра CAPIF или может быть микросхемой в субъекте функции ядра CAPIF.

[0063] В возможной конструкции устройство является субъектом функции ядра CAPIF, при этом субъект функции ядра CAPIF включает в себя процессор, причем процессор сконфигурирован для поддержки субъекта функции ядра CAPIF при выполнении соответствующей функции в вышеупомянутом способе. Кроме того, субъект функции ядра CAPIF может дополнительно включать в себя интерфейс связи, причем интерфейс связи сконфигурирован для поддержки связи между субъектом функции ядра CAPIF и субъектом плоскости пользователя из состава централизованного блока или связи между субъектом функции ядра CAPIF и другим сетевым элементом. Кроме того, субъект функции ядра CAPIF может дополнительно включать в себя память, причем память приспособлена для соединения с процессором и в памяти хранятся программные инструкции и данные, которые необходимы для субъекта функции ядра CAPIF.

[0064] Согласно девятому аспекту, вариант осуществления настоящей заявки предоставляет устройство. Устройство имеет функцию реализации функционирования субъекта функции предоставления API в вышеупомянутом проекте способа. Функция может быть реализована посредством аппаратных средств или может быть реализована посредством исполнения аппаратными средствами соответствующего программного обеспечения. Аппаратные средства или программное обеспечение включают в себя один или несколько модулей, соответствующих вышеуказанной функции. Например, устройство может быть субъектом функции предоставления API или может быть микросхемой в субъекте функции предоставления API.

[0065] В возможной конструкции устройство представляет собой субъект функции предоставления API, причем субъект функции предоставления API включает в себя процессор, при этом процессор сконфигурирован для поддержки субъекта функции предоставления API при выполнении соответствующей функции в вышеупомянутом способе. Кроме того, субъект функции предоставления API может дополнительно включать в себя интерфейс связи, причем интерфейс связи сконфигурирован для поддержки связи между субъектом функции предоставления API и субъектом плоскости пользователя из состава централизованного блока или связи между субъектом функции предоставления API и другим сетевым элементом. Кроме того, субъект функции предоставления API может дополнительно включать в себя память, при этом память приспособлена для соединения с процессором и в памяти хранятся программные инструкции и данные, которые необходимы для субъекта функции предоставления API.

[0066] Согласно десятому аспекту, вариант осуществления настоящей заявки обеспечивает систему связи. Система включает в себя инициатор и субъект функции предоставления API согласно вышеизложенным аспектам. В качестве альтернативы, система включает в себя инициатор, субъект функции предоставления API и субъект функции ядра CAPIF в соответствии с вышеизложенными аспектами.

[0067] Согласно одиннадцатому аспекту, вариант осуществления настоящей заявки предоставляет компьютерный носитель данных, приспособленный для хранения инструкций компьютерного программного обеспечения, используемых инициатором. Инструкции компьютерного программного обеспечения включают в себя программу, разработанную для реализации функционирования инициатора согласно первому или четвертому аспектам.

[0068] Согласно двенадцатому аспекту, вариант осуществления настоящей заявки предоставляет компьютерный носитель данных, приспособленный для хранения инструкций компьютерного программного обеспечения, используемых субъектом функции предоставления API. Инструкции компьютерного программного обеспечения включают в себя программу, разработанную для реализации функционирования субъекта функции предоставления API согласно третьему или шестому аспектам.

[0069] Согласно тринадцатому аспекту, вариант осуществления настоящей заявки предоставляет компьютерный носитель данных, приспособленный для хранения инструкций компьютерного программного обеспечения, используемых вышеупомянутым субъектом функции ядра CAPIF. Инструкции компьютерного программного обеспечения включают в себя программу, предназначенную для реализации функционирования вышеупомянутого субъекта функции ядра CAPIF согласно второму или четвертому аспектам.

[0070] Согласно четырнадцатому аспекту, вариант осуществления настоящей заявки предоставляет систему микросхем, применяемую для инициатора. Система микросхем включает в себя по меньшей мере один процессор, память и интерфейсную схему. Память, приемопередатчик и по меньшей мере один процессор соединены между собой с помощью линии, и в памяти хранится инструкция. Инструкция исполняется по меньшей мере одним процессором для выполнения операции инициатора согласно вышеупомянутому способу.

[0071] Согласно пятнадцатому аспекту, вариант осуществления настоящей заявки предоставляет систему микросхем, применяемую для субъекта функции предоставления API. Система микросхем включает в себя по меньшей мере один процессор, память и интерфейсную схему. Память, приемопередатчик и по меньшей мере один процессор соединены между собой с помощью линии, и по меньшей мере одна память хранит инструкцию. Инструкция исполняется процессором для выполнения операции субъекта функции предоставления API согласно вышеупомянутому способу.

[0072] Согласно шестнадцатому аспекту, вариант осуществления настоящей заявки предоставляет систему микросхем, применяемую для субъекта функции ядра CAPIF. Система микросхем включает в себя по меньшей мере один процессор, память и интерфейсную схему. Память, приемопередатчик и по меньшей мере один процессор соединены между собой с помощью линии, и по меньшей мере одна память хранит инструкцию. Инструкцию исполняется процессором для выполнения операции субъекта функции ядра CAPIF согласно вышеупомянутому способу.

[0073] По сравнению с предшествующим уровнем техники, в решениях согласно вариантам осуществления настоящей заявки, после обновления метода безопасности субъекта функции предоставления API, инициатор может получить новый метод безопасности субъекта функции предоставления API вовремя и вызывать сервисный API с использованием нового метода безопасности, чтобы избежать проблемы, заключающейся в том, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0074] Фиг.1 - схематическая диаграмма основывающейся на CAPIF архитектуры согласно варианту осуществления настоящей заявки;

[0075] Фиг.2 - схематическая коммуникационная диаграмма вызова API;

[0076] Фиг.3A - схематическая коммуникационная диаграмма способа вызова сервисного API согласно варианту осуществления настоящей заявки;

[0077] Фиг.3B - схематическая коммуникационная диаграмма другого способа вызова сервисного API согласно варианту осуществления настоящей заявки;

[0078] Фиг.4 - схематическая коммуникационная диаграмма еще одного способа вызова сервисного API согласно варианту осуществления настоящей заявки;

[0079] Фиг.5 - схематическая коммуникационная диаграмма еще одного способа вызова сервисного API согласно варианту осуществления настоящей заявки;

[0080] Фиг.6 - схематическая коммуникационная диаграмма еще одного способа вызова сервисного API согласно варианту осуществления настоящей заявки;

[0081] Фиг.7 - схематическая коммуникационная диаграмма еще одного способа вызова сервисного API согласно варианту осуществления настоящей заявки;

[0082] Фиг.8 - схематическая блок-схема устройства согласно варианту осуществления настоящей заявки; а также

[0083] Фиг.9 - структурная схема устройства в соответствии с вариантом осуществления настоящей заявки.

Описание вариантов осуществления

[0084] Ниже описаны технические решения согласно вариантам осуществления настоящей заявки со ссылкой на прилагаемые чертежи в вариантах осуществления настоящей заявки.

[0085] Сетевые архитектуры и сценарии применений, которые описаны в вариантах осуществления настоящей заявки, предназначены для более четкого описания технических решений согласно вариантам осуществления настоящей заявки, но не предназначены для ограничения технических решений, предоставляемых согласно вариантам осуществления настоящей заявки. Для специалиста в данной области техники должно быть понятно, что по мере развития сетевых архитектур и появления новых сценариев применения технические решения, представленные в вариантах осуществления настоящей заявки, также применимы к аналогичной технической проблеме.

[0086] Решения согласно вариантам осуществления настоящей заявки могут быть применены к сетевой архитектуре, показанной на Фиг.1. Сетевая архитектура подробно описана в разделе “Уровень техники”, и подробности здесь снова не описываются. В настоящее время в сетевой архитектуре, показанной на Фиг.1, API обычно вызывается посредством использования процедуры, показанной на Фиг.2. Как показано на Фиг.2, процесс вызова выглядит следующим образом.

[0087] Этап 201: Функция публикации API отправляет запрос публикации сервисного API в функцию ядра CAPIF, каковой запрос несет информацию API. Информация API может включать в себя имя API, тип API, информацию об интерфейсе, метод безопасности и т.п.

[0088] Этап 202: Функция ядра CAPIF сохраняет информацию API.

[0089] Этап 203: Функция ядра CAPIF отправляет ответ касаемо публикации сервисного API в функцию публикации API.

[0090] Если функция ядра CAPIF успешно принимает и сохраняет информацию API, функция ядра CAPIF уведомляет, используя ответ касаемо публикации, функцию публикации API о том, что информация API опубликована успешно. Если функции ядра CAPIF не удается принять информацию API или не удается сохранить информацию API, функция ядра CAPIF уведомляет, используя ответ касаемо публикации, функцию публикации API о том, что информацию API не удается опубликовать.

[0091] Этап 204: Инициатор API отправляет запрос обнаружения сервисного API в функцию ядра CAPIF, каковой запрос переносит тип API и информацию об интерфейсе.

[0092] Запрос обнаружения сервисного API используется для запрашивания информации API.

[0093] Этап 205: Функция ядра CAPIF отправляет ответ на запрос обнаружения сервисного API в инициатор API, каковой ответ переносит информацию API.

[0094] Кроме того, функция ядра CAPIF выбирает один метод безопасности и отправляет метод безопасности в инициатор API. Например, метод безопасности - это метод безопасности для конкретного сервисного API, который используется между инициатором API и AEF. В качестве альтернативы, метод безопасности может быть методом безопасности AEF и используется между инициатором API и AEF.

[0095] Этап 206: Инициатор API отправляет запрос вызова сервисного API в AEF. Запрос вызова сервисного API несет информацию API.

[0096] Можно понять, что, поскольку поставщик сервисов открывает сервис для инициатора API посредством использования сервисного API в AEF, инициатор API обычно вызывает сервисный API посредством отправки запроса в AEF.

[0097] Этап 207: AEF получает метод безопасности, соответствующий имени API и информации об интерфейсе, которые включены в информацию API.

[0098] В частности, AEF получает от функции ядра CAPIF метод безопасности, соответствующий имени API и информации об интерфейсе, которые включены в информацию API.

[0099] Этап 208: AEF отправляет ответ на вызов сервисного API в инициатор API.

[0100] В частности, когда вызывается сервисный API, полученный метод безопасности используется для аутентификации, авторизации и защиты между инициатором API и AEF. Если аутентификация и авторизация прошли успешно, инициатор API отправляет ответ на вызов сервисного API.

[0101] Предыдущая процедура представляет собой процедуру, в которой инициатор API вызывает сервисный API в первый раз. Инициатор API должен сначала, от функции ядра CAPIF, найти информацию о сервисном API и получить метод безопасности. После этого инициатор API может напрямую вызывать сервисный API без дальнейшей необходимости получать метод безопасности посредством использования функции ядра CAPIF.

[0102] Однако в вышеупомянутом процессе вызова не учитывается случай, когда обновляется метод безопасности субъекта функции предоставления API или сервисного API. Если метод безопасности субъекта функции предоставления API или сервисного API обновлен, но инициатор API все еще вызывает сервисный API с использованием метода безопасности до обновления на этапе 206, сервисный API не может быть успешно вызван. В настоящее время в отрасли не существует решения этой проблемы.

[0103] В виду этого, когда метод безопасности субъекта функции предоставления API или сервисного API обновляется, следующие варианты осуществления настоящей заявки соответственно предоставляют соответствующие способы вызова.

[0104] Когда обновляется метод безопасности субъекта функции предоставления API, вариант осуществления настоящей заявки предоставляет способ вызова сервисного API, а также инициатор, субъект функции ядра CAPIF и субъект функции предоставления API, которые основываются на данном способе. Далее описывается способ вызова сервисного API со ссылкой на Фиг.3А.

[0105] Фиг.3A - схематическая коммуникационная диаграмма способа вызова сервисного API согласно варианту осуществления настоящей заявки. Предпосылка для реализации способа, показанного на Фиг.3A, заключается в том, что метод безопасности субъекта функции предоставления API обновляется с исходного метода безопасности на новый метод безопасности. Метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором. Например, метод безопасности субъекта функции предоставления API может использоваться для аутентификации, авторизации и защиты между субъектом функции предоставления API и инициатором. Способ, показанный на Фиг.3A, включает в себя следующие этапы.

[0106] Этап 301: Субъект функции ядра CAPIF принимает запрос обновления для функции предоставления API от субъекта функции публикации API, причем запрос обновления включает в себя новый метод безопасности функции предоставления API.

[0107] В одном примере запрос обновления дополнительно включает в себя информацию указания, и информация указания используется для предписания субъекту функции ядра CAPIF отправить новый метод безопасности в инициатор.

[0108] Этап 302: Субъект функции ядра CAPIF сохраняет новый метод безопасности.

[0109] В примере субъект функции ядра CAPIF сохраняет соответствие между инициатором, новым методом безопасности и субъектом функции предоставления API.

[0110] Этап 303: Инициатор получает новый метод безопасности субъекта функции предоставления API.

[0111] В первом примере этап 303 может быть этапом 303а. Инициатор получает новый метод безопасности от субъекта функции предоставления API.

[0112] В возможной реализации перед выполнением этапа 303a инициатор может дополнительно отправить запрос согласования метода безопасности в субъект предоставления функции API, при этом запрос согласования метода безопасности включает в себя список методов безопасности, поддерживаемых инициатором, и список методов безопасности включает в себя новый метод безопасности. Соответственно, этап 303а может включать в себя следующее: Инициатор принимает ответ по согласованию метода безопасности от субъекта функции предоставления API, где ответ по согласованию метода безопасности включает в себя новый метод безопасности.

[0113] В другой возможной реализации перед выполнением этапа 303a инициатор может дополнительно отправить третий запрос вызова в субъект функции предоставления API с использованием исходного метода безопасности, где третий запрос вызова используется для вызова сервисного API. Соответственно, этап 303а может включать в себя следующее: Инициатор принимает ответное сообщение на третий запрос вызова от субъекта функции предоставления API, при этом ответное сообщение на третий запрос вызова включает в себя новый метод безопасности и значение причины, и значение причины используется для указания того, что не удается вызвать сервисный API вследствие несоответствия метода безопасности.

[0114] Во втором примере этап 303 может быть этапом 303b. Инициатор получает новый метод безопасности от субъекта функции ядра CAPIF.

[0115] В возможной реализации субъект функции ядра CAPIF может отправить новый метод безопасности в инициатор на основе информации указания в запросе обновления.

[0116] В другой возможной реализации перед выполнением этапа 303b инициатор может дополнительно запросить новый метод безопасности у субъекта функции ядра CAPIF. Например, инициатор может отправить запрос получения в субъект функции ядра CAPIF, где запрос получения используется для запрашивания нового метода безопасности.

[0117] В предыдущей возможной реализации первого примера на этом этапе и двух реализациях второго примера, перед получением нового метода безопасности субъекта функции предоставления API, инициатор может дополнительно отправить второй запрос вызова в субъект функции предоставления API посредством использования исходного метода безопасности, где второй запрос вызова используется для вызова сервисного API. Инициатор может дополнительно получить ответное сообщение на второй запрос вызова от субъекта функции предоставления API, где ответное сообщение на второй запрос вызова включает в себя значение причины, и значение причины используется для указания того, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0118] Этап 304: Инициатор отправляет первый запрос вызова в субъект функции предоставления API с использованием нового метода безопасности.

[0119] Первый запрос вызова включает в себя имя сервисного API, и первый запрос вызова используется для вызова сервисного API.

[0120] В необязательном порядке, способ, показанный на Фиг.3A, может дополнительно включать в себя следующие этапы.

[0121] Этап 305: Субъект функции предоставления API отправляет в инициатор ответное сообщение на первый запрос вызова.

[0122] Ответное сообщение на первый запрос вызова используется для указания того, что сервисный API успешно вызван.

[0123] В способе, показанном на Фиг.3A, когда обновляется метод безопасности субъекта функции предоставления API, инициатор может получить новый метод безопасности субъекта функции предоставления API вовремя и вызывать сервисный API из субъекта функции предоставления API с использованием нового метода безопасности, чтобы избежать проблемы, заключающейся в том, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0124] Когда обновляется метод безопасности сервисного API, вариант осуществления настоящей заявки предоставляет другой способ вызова сервисного API и инициатор, субъект функции ядра CAPIF и субъект функции предоставления API, которые основываются на данном способе. Далее описывается способ вызова сервисного API со ссылкой на Фиг.3B.

[0125] Фиг.3B - схематическая коммуникационная диаграмма другого способа вызова сервисного API согласно варианту осуществления настоящей заявки. Предпосылка для реализации способа, показанного на Фиг.3B, заключается в том, что метод безопасности сервисного API обновляется с исходного метода безопасности на новый метод безопасности. Способ, показанный на Фиг.3B, включает в себя следующие этапы.

[0126] Этап 311: Субъект функции ядра CAPIF принимает запрос обновления для функции предоставления API от субъекта функции публикации API, где запрос обновления включает в себя новый метод безопасности сервисного API.

[0127] В одном примере запрос обновления дополнительно включает в себя информацию указания, и информация указания используется для предписания субъекту функции ядра CAPIF отправить новый метод безопасности в инициатор.

[0128] Этап 312: Субъект функции ядра CAPIF сохраняет новый метод безопасности.

[0129] В примере субъект функции ядра CAPIF сохраняет соответствие между инициатором, новым методом безопасности и сервисным API. В конкретном примере субъект функции ядра CAPIF сохраняет соответствие между инициатором, новым методом безопасности, сервисным API и субъектом функции предоставления API.

[0130] Этап 313: Инициатор получает новый метод безопасности сервисного API.

[0131] В первом примере этап 313 может быть этапом 313a. Инициатор получает новый метод безопасности от субъекта функции предоставления API.

[0132] В возможной реализации перед выполнением этапа 313a инициатор может дополнительно отправить запрос согласования метода безопасности в субъект предоставления функции API, причем запрос согласования метода безопасности включает в себя список методов безопасности, поддерживаемых инициатором, и список методов безопасности включает в себя новый метод безопасности. Соответственно, этап 313a может включать в себя следующее: Инициатор принимает ответ по согласованию метода безопасности от субъекта функции предоставления API, где ответ по согласованию метода безопасности включает в себя новый метод безопасности.

[0133] В другой возможной реализации перед выполнением этапа 313a инициатор может дополнительно отправить третий запрос вызова в субъект функции предоставления API с использованием исходного метода безопасности, где третий запрос вызова используется для вызова сервисного API. Соответственно, этап 313a может включать в себя следующее: Инициатор принимает ответное сообщение на третий запрос вызова от субъекта функции предоставления API, где ответное сообщение на третий запрос вызова включает в себя новый метод безопасности и значение причины, и значение причины используется для указания того, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0134] Во втором примере этап 313 может быть этапом 313b. Инициатор получает новый метод безопасности от субъекта функции ядра CAPIF.

[0135] В возможной реализации субъект функции ядра CAPIF может отправить новый метод безопасности в инициатор на основе информации указания в запросе обновления.

[0136] В другой возможной реализации перед выполнением этапа 313b инициатор может дополнительно запросить новый метод безопасности у субъекта функции ядра CAPIF. Например, инициатор может отправить запрос получения в субъект функции ядра CAPIF, где запрос получения используется для запрашивания нового метода безопасности.

[0137] В предыдущей возможной реализации первого примера на этом этапе и двух реализациях второго примера, перед получением нового метода безопасности сервисного API, инициатор может дополнительно отправить второй запрос вызова в субъект функции предоставления API с использованием исходного метода безопасности, и второй запрос вызова используется для вызова сервисного API. Инициатор может дополнительно принять ответное сообщение на второй запрос вызова от субъекта функции предоставления API, где ответное сообщение на второй запрос вызова включает в себя значение причины, и значение причины используется для указания того, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0138] Этап 314: Инициатор отправляет первый запрос вызова в субъект функции предоставления API с использованием нового метода безопасности.

[0139] Первый запрос вызова включает в себя имя сервисного API, и первый запрос вызова используется для вызова сервисного API.

[0140] В необязательном порядке, способ, показанный на Фиг.3B, может дополнительно включать в себя следующие этапы.

[0141] Этап 315: Субъект функции предоставления API отправляет в инициатор ответное сообщение на первый запрос вызова.

[0142] Ответное сообщение на первый запрос вызова используется для указания того, что сервисный API успешно вызван.

[0143] В способе, показанном на Фиг.3B, когда метод безопасности сервисного API обновляется, инициатор может получить новый метод безопасности сервисного API вовремя и вызывать сервисный API из субъекта функции предоставления API с использованием нового метода безопасности, чтобы избежать проблемы, заключающейся в том, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

[0144] Следует отметить, что способы, показанные на Фиг.3A и Фиг.3B, могут выполняться отдельно или могут выполняться в комбинации. Например, когда обновляется метод безопасности субъекта функции предоставления API, может выполняться способ, показанный на Фиг.3A. Когда обновляется метод безопасности сервисного API, может выполняться способ, показанный на Фиг.3B. Когда обновляются методы безопасности как субъекта функции предоставления API, так и сервисного API, способы, показанные на Фиг.3A и Фиг.3B, могут выполняться в комбинации. Например, этап 301 может выполняться в сочетании с этапом 311, этап 302 может выполняться в сочетании с этапом 312, этап 303 может выполняться в сочетании с этапом 313, этап 304 может выполняться в сочетании с этапом 314, и этап 305 может выполняться в сочетании с этапом 315. Конечно, когда способы, показанные на Фиг.3A и Фиг.3B, выполняются в комбинации, может быть другая реализация, которая не ограничена данным вариантом осуществления настоящей заявки.

[0145] Нижеследующее описывает решения согласно вариантам осуществления настоящей заявки со ссылкой на Фиг.4 - Фиг.7. В способах, показанных на Фиг.4 - Фиг.7, на предмет содержания, которое является таким же или похожим на содержание способа, показанного на Фиг.3, следует обратиться к подробному описанию по Фиг.3A или Фиг.3B. Подробности далее не описываются. Следует отметить, что способы, показанные на Фиг.4 - Фиг.7, описываются с использованием примера, в котором обновляется метод безопасности сервисного API. При реальной работе способы, показанные на Фиг.4 - Фиг.7, также могут применяться к случаю, в котором обновляется метод безопасности субъекта функции предоставления API. В этом случае метод безопасности сервисного API в способах, показанных на Фиг.4 - Фиг.7, заменяется методом безопасности субъекта функции предоставления API. Кроме того, в вышеизложенном «исходный метод безопасности» также может быть описан как «метод безопасности до обновления», и оба могут использоваться совместно. «Новый метод безопасности» также может быть описан как «обновленный метод безопасности», и оба могут использоваться совместно.

[0146] Фиг.4 - схематическая коммуникационная диаграмма еще одного способа вызова сервисного API согласно варианту осуществления настоящей заявки. Основная идея способа, показанного на Фиг.4, заключается в следующем: После обновления метода безопасности сервисного API, если инициатор API не может вызвать сервисный API, инициатор API запрашивает обновленный метод безопасности сервисного API у функции ядра CAPIF, и затем вызывает сервисный API из AEF с использованием обновленного метода безопасности. Способ, показанный на Фиг.4, может включать в себя этапы 401-406.

[0147] Следует отметить, что до способа, показанного на Фиг.4, функция ядра CAPIF сохраняет соответствие между идентификатором инициатора API, методом безопасности до обновления и идентификатором сервисного API.

[0148] Этап 401: Обновить метод безопасности сервисного API.

[0149] Для описания используется пример, в котором обновляется метод безопасности сервисного API 1. В частности, после обновления метода безопасности сервисного API 1, сервисный API 1 уведомляет функцию ядра CAPIF об обновленном методе безопасности сервисного API 1. Сервисный API 1 может отправлять обновленный метод безопасности сервисного API 1 в функцию ядра CAPIF посредством функции публикации API. Соответственно, после приема обновленного метода безопасности сервисного API 1, функция ядра CAPIF сохраняет обновленный метод безопасности.

[0150] При сохранении обновленного метода безопасности сервисного API 1 функция ядра CAPIF может сохранять соответствие между идентификатором инициатора API, обновленным методом безопасности сервисного API 1 и именем сервисного API 1. Например, функция ядра CAPIF может заменить метод безопасности сервисного API 1 до обновления в ранее сохраненном соответствии между идентификатором инициатора API, методом безопасности сервисного API 1 до обновления и именем сервисного API 1 с обновленным методом безопасности сервисного API 1.

[0151] Например, функция публикации API может отправить запрос публикации сервисного API в функцию ядра CAPIF, каковой запрос содержит имя сервисного API 1 и обновленный метод безопасности. После приема запроса функция ядра CAPIF заменяет локально сохраненный метод безопасности, соответствующий имени сервисного API 1, на полученный обновленный метод безопасности. Кроме того, после успешного сохранения обновленного метода безопасности функция ядра CAPIF может дополнительно отправить ответ касаемо публикации сервисного API в функцию публикации API.

[0152] Этап 402: Инициатор API отправляет запрос вызова сервисного API в AEF.

[0153] Здесь инициатор API взаимодействует с AEF посредством использования метода безопасности сервисного API 1 до обновления. Например, инициатор API может выполнять аутентификацию, авторизацию и защиту с AEF посредством использования метода безопасности сервисного API 1 до обновления.

[0154] В частности, запрос вызова сервисного API использует сообщение запроса, соответствующее методу безопасности до обновления, и сообщение запроса может нести идентификатор инициатора API. Кроме того, сообщение запроса может дополнительно нести имя сервисного API 1.

[0155] Например, методом безопасности до обновления является TLS-PSK. Когда используется этот метод, запрос вызова, отправляемый инициатором API в сервисный API, является приветственным сообщением клиента, и приветственное сообщение клиента содержит ключ, предварительно назначенный для совместного использования. Инициатор API выполняет аутентификацию и устанавливает безопасное соединение с AEF, используя этот предварительно назначенный для совместного использования ключ, чтобы вызвать сервисный API 1.

[0156] Этап 403: AEF отправляет ответ о неудаче вызова сервисного API в инициатор API.

[0157] Ответ о неудаче вызова сервисного API содержит значение причины, и значение причины используется для указания того, что не удается вызвать сервисный API 1 из-за ошибки метода безопасности.

[0158] Кроме того, ответ о неудаче вызова сервисного API может дополнительно нести информацию указания, где информация указания используется для предписания инициатору API получить обновленный метод безопасности сервисного API 1 из функции ядра CAPIF.

[0159] Этап 404: Инициатор API отправляет запрос получения метода безопасности в функцию ядра CAPIF.

[0160] Запрос получения метода безопасности содержит идентификатор инициатора API. В необязательном порядке, запрос получения метода безопасности может дополнительно нести имя сервисного API 1.

[0161] Этап 405: Функция ядра CAPIF отправляет в инициатор API ответ на запрос получения метода безопасности.

[0162] Ответ на запрос получения метода безопасности содержит обновленный метод безопасности.

[0163] В одном из примеров функция ядра CAPIF может выполнять поиск, на основе инициатора API, методов безопасности всех сервисных API, соответствующих инициатору API, и отправлять методы безопасности в инициатор API. В частности, функция ядра CAPIF отправляет имена одного или нескольких сервисных API и соответствующие группы методов безопасности в инициатор API. Например, соответствующие группы могут быть представлены как (сервисный API 1, метод безопасности 1), (сервисный API 2, метод безопасности 2) или тому подобное.

[0164] Соответственно, после того, как инициатор API принимает ответ на запрос получения метода безопасности, инициатор API может узнать, в соответствии с ответом на запрос получения метода безопасности, что обновленный метод безопасности сервисного API 1 является методом 1 безопасности.

[0165] В другом примере функция ядра CAPIF может выполнять поиск, на основе идентификатора инициатора API и имени сервисного API 1, метода безопасности, который однозначно соответствует идентификатору инициатора API и имени сервисного API 1, добавлять метод безопасности в ответ на запрос получения метода безопасности и отправлять ответ на запрос получения метода безопасности в инициатор API.

[0166] Этап 406: Инициатор API отправляет запрос вызова сервисного API в AEF.

[0167] Здесь инициатор API взаимодействует с AEF, используя обновленный метод безопасности сервисного API 1.

[0168] В частности, инициатор API выполняет аутентификацию, авторизацию и защиту с AEF посредством использования обновленного метода безопасности сервисного API 1. Например, запрос вызова сервисного API несет в себе информацию аутентификации и идентификатор инициатора API, которые соответствуют обновленному методу безопасности сервисного API 1. Кроме того, запрос вызова может дополнительно нести имя сервисного API 1.

[0169] Например, обновленным методом безопасности сервисного API 1 является метод безопасности на основе шифросистем с предварительно назначенными для совместного использования ключами безопасности транспортного уровня (transport layer security pre-shared key ciphersuites, TLS-PKI)), информацией аутентификации, соответствующей обновленному методу безопасности сервисного API 1, является сертификат, который необходимо переносить в приветственном сообщении клиента, и инициатор API отправляет приветственное сообщение клиента, содержащее сертификат, в AEF для вызова сервисного API 1.

[0170] Этап 407: AEF отправляет ответ об успешном вызове сервисного API в инициатор API.

[0171] В одном примере AEF может получить обновленный метод безопасности сервисного API 1 от функции ядра CAPIF и выполнять, на основе обновленного метода безопасности, проверку по аутентификации и авторизации в отношении запроса вызова, отправленного инициатором API. Если проверка прошла успешно, AEF отправляет ответ об успешном вызове сервисного API в инициатор API.

[0172] Например, информация аутентификации, соответствующая обновленному методу безопасности, представляет собой сертификат, который необходимо переносить в приветственном сообщении клиента. Если AEF успешно выполняет проверку по аутентификации и авторизации в отношении инициатора API на основе метода безопасности TLS-PKI, соответствующего сертификату, сервисный API успешно вызывается, и AEF отправляет ответ об успешном вызове сервисного API в инициатор API.

[0173] В другом примере обновленный метод безопасности сервисного API 1 используется для аутентификации, авторизации и защиты между AEF и инициатором API. Если аутентификация и авторизация успешны, AEF отправляет ответ об успехе в инициатор API.

[0174] В другой возможной реализации этого варианта осуществления запрос получения метода безопасности на этапе 404 может быть заменен запросом обнаружения метода безопасности, и ответ на запрос получения метода безопасности на этапе 405 может быть заменен ответом на запрос обнаружения метода безопасности. Можно понять, что вышеупомянутый запрос получения метода безопасности и ответ на запрос получения метода безопасности могут быть заменены по-новому определенным сообщением. Наименование сообщения не является ограничением в этом варианте осуществления настоящей заявки. В качестве альтернативы, вышеупомянутые этап 404 и этап 405 могут быть заменены процессом согласования безопасности между инициатором API и функцией ядра CAPIF.

[0175] В частности, в процессе согласования безопасности инициатор API отправляет все методы безопасности, поддерживаемые инициатором API, в функцию ядра CAPIF, и функция ядра CAPIF сравнивает полученные методы безопасности с методами безопасности, поддерживаемыми функцией предоставления API, и выбирает метод безопасности в соответствии с политикой и отправляет метод безопасности в инициатор API для использования между инициатором API и субъектом функции предоставления API.

[0176] Фиг.5 - схематическая коммуникационная диаграмма еще одного способа вызова сервисного API согласно варианту осуществления настоящей заявки. Основная идея способа, показанного на Фиг.5, заключается в следующем: После обновления метода безопасности сервисного API функция публикации API предписывает функции ядра CAPIF осуществить активную отправку обновленного метода безопасности сервисного API в инициатор API, а затем инициатор API вызывает сервисный API из AEF, используя обновленный метод безопасности. Способ, показанный на Фиг.5, может включать в себя этапы с 501 по 507.

[0177] Этап 501: Функция публикации API отправляет запрос обновления сервисного API в функцию ядра CAPIF.

[0178] Запрос несет имя сервисного API, обновленный метод безопасности и информацию указания. Информация указания используется для предписания функции ядра CAPIF отправить обновленный метод безопасности сервисного API в инициатор API.

[0179] Этап 502: Функция ядра CAPIF обновляет информацию о сервисном API.

[0180] В частности, функция ядра CAPIF заменяет метод безопасности в информации о сервисном API, хранящейся в функции ядра CAPIF, обновленным методом безопасности.

[0181] Например, функция ядра CAPIF изначально хранит соответствие между идентификатором инициатора API, методом безопасности сервисного API до обновления и именем сервисного API. Здесь функция ядра CAPIF заменяет метод безопасности сервисного API до обновления в соответствии с обновленным методом безопасности сервисного API.

[0182] Этап 503: Функция ядра CAPIF отправляет ответ касаемо обновления сервисного API в функцию публикации API.

[0183] Этап 504: Функция ядра CAPIF отправляет обновленную информацию о сервисном API в инициатор API.

[0184] Обновленная информация о сервисном API включает в себя имя сервисного API и обновленный метод безопасности сервисного API.

[0185] Этап 505: Инициатор API отправляет подтверждение обновления метода безопасности в функцию ядра CAPIF.

[0186] Этап 506 и этап 507, соответственно, такие же или аналогичные этапам 406 и 407 на Фиг.4. За подробностями следует обратиться к подробному описанию по Фиг.4. Подробности не приводятся здесь снова.

[0187] Фиг.6 - схематическая коммуникационная диаграмма еще одного способа вызова сервисного API согласно варианту осуществления настоящей заявки. Основная идея способа, показанного на Фиг.6, заключается в следующем: После обновления метода безопасности сервисного API, когда инициатору API не удается вызвать сервисный API, AEF отправляет обновленный метод безопасности в инициатор API, и затем инициатор API вызывает сервисный API из AEF, используя обновленный метод безопасности. Способ, показанный на Фиг.6, может включать в себя этапы 601-605.

[0188] Этап 601 и этап 602, соответственно, аналогичны этапу 401 и этапу 402 на Фиг.4. За подробностями следует обратиться к подробному описанию по Фиг.4. Подробности не приводятся здесь снова.

[0189] Этап 603: AEF отправляет ответ о неудаче вызова сервисного API в инициатор API.

[0190] Ответ содержит значение причины и обновленный метод безопасности. Это значение причины используется для указания того, что не удается вызвать сервисный API из-за ошибки метода безопасности.

[0191] Этап 604 и этап 605, соответственно, такие же, как этап 406 и этап 407 на Фиг.4. За подробностями следует обратиться к подробному описанию по Фиг.4. Подробности не приводятся здесь снова.

[0192] Фиг.7 - схематическая коммуникационная диаграмма еще одного способа вызова сервисного API согласно варианту осуществления настоящей заявки. Основная идея способа, показанного на Фиг.7, заключается в следующем: После обновления метода безопасности сервисного API, когда инициатору API не удается вызвать сервисный API, инициатор API согласовывает метод безопасности с AEF и затем инициатор API вызывает сервисный API из AEF, используя согласованный метод безопасность. Способ, показанный на Фиг.7, может включать в себя этапы 701-706.

[0193] Этапы с 701 по 703, соответственно, идентичны этапам с 401 по 403 на Фиг.4. За подробностями следует обратиться к подробному описанию по Фиг.4. Подробности не приводятся здесь снова.

[0194] Этап 704: Инициатор API отправляет запрос согласования метода безопасности в AEF.

[0195] Запрос содержит методы безопасности, поддерживаемые инициатором API, например, включая метод A безопасности, метод B безопасности и метод C безопасности.

[0196] Следует отметить, что в этом варианте осуществления настоящей заявки предполагается, что метод безопасности, который может быть использован сервисным API, включает в себя только метод A безопасности, метод B безопасности и метод C безопасности.

[0197] Этап 705: AEF отправляет в инициатор API ответ касаемо согласования метода безопасности.

[0198] Ответ содержит метод C безопасности. В частности, после приема запроса согласования метода безопасности AEF определяет, что обновленный метод безопасности сервисного API является методом C безопасности, добавляет метод C безопасности в ответу касаемо согласования метода безопасности и отправляет ответ касаемо согласованию метода безопасности в инициатор API.

[0199] Этап 706: Инициатор API отправляет запрос вызова сервисного API в AEF.

[0200] Здесь инициатор API взаимодействует с AEF, используя обновленный метод безопасности (то есть метод C безопасности) сервисного API.

[0201] Этап 707: AEF отправляет ответ об успехе вызова сервисного API в инициатор API.

[0202] Конкретные процессы реализации этапа 706 и этапа 707 аналогичны процессам согласно этапу 406 и этапу 407 на Фиг.4. За подробностями следует обратиться к подробному описанию по Фиг.4. Подробности не приводятся здесь снова.

[0203] Решения, представленные в вариантах осуществления настоящей заявки, описаны выше, в основном, с точки зрения взаимодействия между различными сетевыми элементами. Можно понять, что для реализации вышеупомянутых функций инициатор, субъект функции предоставления API и субъект функции ядра CAPIF включают в себя аппаратную конструкцию и/или программный модуль, соответствующий каждой функции. Что касается блоков и этапов алгоритма, описанных в вариантах осуществления, раскрытых в этой заявке, варианты осуществления настоящей заявки могут быть реализованы в виде аппаратных средств или комбинации аппаратных средств и компьютерного программного обеспечения. Выполнение функции посредством аппаратных средств или посредством аппаратных средств, управляемых компьютерным программным обеспечением, зависит от конкретных применений и конструктивных ограничений технических решений. Специалист в данной области техники может использовать различные подходы для реализации описанных функций для каждого конкретного вариант применения, но не следует считать, что такая реализация выходит за рамки объема технических решений согласно вариантам осуществления настоящей заявки.

[0204] В вариантах осуществления настоящей заявки функциональные блоки инициатора, субъекта функции предоставления API и субъекта функции ядра CAPIF могут быть разделены в соответствии с приведенными выше примерами способов. Например, каждый функциональный блок может быть разделен в соответствии с каждой функцией, либо две или более функций могут быть интегрированы в один блок обработки. Интегральный блок может быть реализован в виде аппаратных средств или может быть реализован в виде программного функционального блока. Следует отметить, что в этом варианте осуществления настоящей заявки разделение на блоки является примерным и является просто логическим разделением согласно функциям. Во время фактической реализации может использоваться другой способ разделения.

[0205] Когда используется интегральный блок, то Фиг.8 - возможный пример блок-схемы устройства согласно варианту осуществления настоящей заявки. Устройство 800 может существовать в виде программного обеспечения, оборудования или комбинации программного обеспечения и оборудования. Фиг.8 - возможная схематическая блок-схема устройства согласно варианту осуществления настоящей заявки. Устройство 800 включает в себя блок 802 обработки и блок 803 связи. Блок 802 обработки сконфигурирован для контроля и управления функционированием устройства. Блок 803 связи сконфигурирован для поддержки связи между устройством и другим устройством. Устройство может дополнительно включать в себя блок 801 хранения данных, приспособленный для хранения программного кода и данных устройства.

[0206] Устройство 800, показанное на Фиг.8, может быть инициатором, субъектом функции предоставления API или субъектом функции ядра CAPIF согласно вариантам осуществления настоящей заявки.

[0207] Когда устройство 800, показанное на Фиг.8, является инициатором, блок 802 обработки может поддерживать устройство 800 в осуществлении функционирования, выполняемого инициатором в вышеупомянутых примерах способа. Блок 803 связи может поддерживать связь между устройством 800 и субъектом функции ядра CAPIF, связь между устройством 800 и субъектом функции предоставления API и т.п. Например, блок 803 связи поддерживает устройство 800 при выполнении этапов 303-305 по Фиг.3A, этапов 313-315 по Фиг.3B, этапов 402-407 по Фиг.4, этапов 504-507 по Фиг.5, этапов 602-605 по Фиг.6, этапов 702-707 по Фиг.7 и/или другого соответствующего процесса связи.

[0208] Когда устройство 800, показанное на Фиг.8, является субъектом функции предоставления API, блок 802 обработки может поддерживать устройство 800 в осуществлении функционирования, выполняемого субъектом функции предоставления API в вышеупомянутых примерах способа. Например, блок 802 обработки поддерживает устройство 800 при выполнении этапа 401 по Фиг.4, этапа 601 по Фиг.6, этапа 701 по Фиг.7 и/или другого процесса технологии, раскрытой в данном описании. Блок 803 связи может поддерживать связь между устройством 800 и инициатором, связь между устройством 800 и субъектом функции ядра CAPIF и т.п. Например, блок 803 связи поддерживает устройство 800 при выполнении этапов 303a, 304 и 305 по Фиг.3A и этапов 313a, 314 и 315 по Фиг.3B, этапов 402, 403, 406 и 407 по Фиг.4, этапов 506 и 507 по Фиг.5, этапов 602-605 по Фиг.6, этапов 702-707 по Фиг.7 и/или другого соответствующего процесс связи.

[0209] Когда устройство 800, показанное на Фиг.8, является субъектом функции ядра CAPIF, блок 802 обработки может поддерживать устройство 800 в осуществлении функционирования, выполняемого субъектом функции ядра CAPIF в вышеупомянутых примерах способов. Например, блок 802 обработки поддерживает устройство 800 при выполнении этапа 302 по Фиг.3A, этапа 312 по Фиг.3B, этапа 401 по Фиг.4, этапа 502 по Фиг.5, этапа 601 по Фиг.6, этапа 701 по Фиг.7 и/или другого процесса технологии, раскрытой в данном описании. Блок 803 связи может поддерживать связь между устройством 800 и инициатором, субъектом функции предоставления API, субъектом функции публикации API или т.п. Например, блок 803 связи поддерживает устройство 800 при выполнении этапов 301 и 303b по Фиг.3A, этапов 311 и 313b по Фиг.3B и этапов 404 и 405 по Фиг.4, этапа 501 и этапов 503-505 по Фиг.5 и/или другого соответствующего процесса связи.

[0210] Например, блок 802 обработки может быть процессором или контроллером, например, может быть центральным процессором (Central Processing Unit, CPU), процессором общего назначения, процессором цифровых сигналов (Digital Signal Processor, DSP), специализированной интегральной схемой (Application-Specific Integrated Circuit, ASIC), программируемой вентильной матрицей (Field Programmable Gate Array, FPGA) или другим программируемым логическим устройством, транзисторным логическим устройством, аппаратным компонентом или их комбинацией. Процессор может реализовывать или выполнять различные примерные логические блоки, модули и схемы, описанные со ссылкой на содержимое, раскрытое в настоящей заявке. Альтернативно, процессор может быть комбинацией для реализации вычислительной функции, например, комбинацией одного или нескольких микропроцессоров или комбинацией DSP и микропроцессора. Блок 803 связи может быть интерфейсом связи, где интерфейс связи - общий термин. Во время конкретной реализации интерфейс связи может включать в себя один или несколько интерфейсов. Блок 801 хранения данных может быть памятью.

[0211] Когда блок 802 обработки является процессором, блок 803 связи является интерфейсом связи, а блок 801 хранения данных - памятью, устройство в этом варианте осуществления настоящей заявки может быть устройством 900, показанным на Фиг.9.

[0212] Обращаясь к Фиг.9, устройство 900 включает в себя процессор 902 и интерфейс 903 связи. Кроме того, устройство 900 может дополнительно включать в себя память 901. В необязательном порядке, устройство 900 может дополнительно включать в себя шину 904. Интерфейс 903 связи, процессор 902 и память 901 могут быть соединены друг с другом с помощью шины 904. Шина 904 может быть шиной межсоединения периферийных компонентов (Peripheral Component Interconnect, PCI для краткости), шиной с расширенной отраслевой стандартной архитектурой (Extended Industry Standard Architecture, EISA для краткости) или т.п. Шину 904 можно разделить на адресную шину, шину данных, шину управления и т.п. Для простоты изложения используется только одна толстая линия для представления шины на Фиг.9, но это не означает, что есть только одна шина или только один тип шины.

[0213] Процессор 902 может выполнять различные функции устройства 900 путем запуска или исполнения программы, хранящейся в памяти 901.

[0214] Например, устройство 900, показанное на Фиг.9, может быть инициатором, субъектом функции ядра CAPIF или субъектом функции предоставления API согласно вариантам осуществления настоящей заявки.

[0215] Когда устройство 900 является инициатором, процессор 902 может осуществлять функционирование, выполняемое инициатором в вышеприведенных примерах способа, путем запуска или исполнения программы, хранящейся в памяти 901. Когда устройство 900 является субъектом функции ядра CAPIF, процессор 902 может осуществлять функционирование, выполняемое субъектом функции ядра CAPIF в вышеупомянутых примерах способа, путем запуска или исполнения программы, хранящейся в памяти 901.

[0216] Когда устройство 900 представляет собой субъект функции предоставления API, процессор 902 может осуществлять функционирование, выполняемое субъектом функции предоставления API в вышеупомянутых примерах способа путем запуска или исполнения программы, хранящейся в памяти 901.

[0217] Способы или этапы алгоритма, описанные в сочетании с содержимым, раскрытым в вариантах осуществления настоящей заявки, могут быть реализованы посредством аппаратных средств или могут быть реализованы посредством исполнения процессором программной инструкции. Программная инструкция может включать в себя соответствующий программный модуль. Программный модуль может храниться в оперативной памяти (random access memory, RAM), флэш-памяти, постоянном запоминающем устройстве (read only memory, ROM), стираемом программируемом постоянном запоминающем устройстве (Erasable Programmable ROM, EPROM), электрически стираемом программируемом постоянном запоминающем устройстве (Electrically EPROM, EEPROM), регистре, жестком диске, съемном жестком диске, постоянном запоминающем устройстве в виде компакт-диска (CD-ROM) или любом другом носителе данных. известном в технике. Например, носитель данных подключен к процессору, так что процессор может считывать информацию с носителя данных или записывать информацию на носитель данных. Конечно, носитель данных альтернативно может быть компонентом процессора. Процессор и носитель данных могут располагаться в ASIC. Кроме того, ASIC может быть расположена в инициаторе, в субъекте функции ядра CAPIF или в субъекте функции предоставления API. Конечно, процессор и носитель данных могут альтернативно существовать в инициаторе, субъекте функции ядра CAPIF или субъекте функции предоставления API в качестве дискретных компонентов.

[0218] Специалист в данной области техники должен понимать, что в вышеприведенных одном или нескольких примерах функции, описанные в вариантах осуществления настоящей заявки, могут быть реализованы аппаратными средствами, программным обеспечением, встроенным программным обеспечением или любой их комбинацией. Когда функции реализуются посредством программного обеспечения, эти функции могут храниться на машиночитаемом носителе или передаваться в виде одной или нескольких инструкций или кода на машиночитаемом носителе. Машиночитаемый носитель включает в себя компьютерный носитель данных и среду связи, причем среда связи включает в себя любую среду, которая позволяет передавать компьютерную программу из одного места в другое. Носитель данных может быть любым доступным носителем, который может быть доступен компьютеру общего или специального назначения.

[0219] В вышеупомянутых конкретных реализациях дополнительно подробно описаны цели, технические решения и полезные эффекты вариантов осуществления настоящей заявки. Следует понимать, что вышеприведенные описания являются лишь конкретными реализациями вариантов осуществления данной заявки, но они не предназначены для ограничения объема охраны вариантов осуществления данной заявки. Любая модификация, эквивалентная замена или улучшение, сделанные на основе технических решений согласно вариантам осуществления настоящей заявки, должны подпадать под объем охраны вариантов осуществления настоящей заявки.

Claims (63)

1. Способ вызова сервисного интерфейса прикладного программирования (API), в котором метод безопасности субъекта функции предоставления API обновляется с исходного метода безопасности на новый метод безопасности, и метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором, при этом способ содержит этапы, на которых:

отправляют (402) посредством инициатора второй запрос вызова в субъект функции предоставления API с использованием исходного метода безопасности, причем второй запрос вызова используется для вызова сервисного API;

принимают (403) посредством инициатора ответное сообщение на второй запрос вызова от субъекта функции предоставления API, причем ответное сообщение на второй запрос вызова содержит значение причины, и значение причины указывает то, что не удается вызвать сервисный API из-за несоответствия метода безопасности;

получают посредством инициатора новый метод безопасности субъекта функции предоставления API; и

отправляют (406) посредством инициатора первый запрос вызова в субъект функции предоставления API с использованием нового метода безопасности, при этом первый запрос вызова содержит имя сервисного API, и первый запрос вызова используется для вызова сервисного API.

2. Способ по п.1, в котором при упомянутом получении инициатором нового метода безопасности субъекта функции предоставления API принимают (405) посредством инициатора новый метод безопасности от субъекта функции ядра общей инфраструктуры API (CAPIF).

3. Способ по п.2, при этом перед упомянутым приемом инициатором нового метода безопасности от субъекта функции ядра общей инфраструктуры API (CAPIF) способ дополнительно содержит этап, на котором запрашивают (404) посредством инициатора новый метод безопасности у субъекта функции ядра CAPIF.

4. Способ по п.1, в котором при упомянутом получении инициатором нового метода безопасности субъекта функции предоставления API принимают посредством инициатора новый метод безопасности от субъекта функции предоставления API.

5. Способ по п.4, при этом

перед упомянутым получением инициатором нового метода безопасности субъекта функции предоставления API способ дополнительно содержит этап, на котором отправляют посредством инициатора запрос согласования метода безопасности в субъект функции предоставления API, причем запрос согласования метода безопасности содержит список методов безопасности, поддерживаемых инициатором, и список методов безопасности содержит новый метод безопасности; и

при упомянутом приеме инициатором нового метода безопасности от субъекта функции предоставления API принимают посредством инициатора ответ по согласованию метода безопасности от субъекта функции предоставления API, причем ответ по согласованию метода безопасности содержит новый метод безопасности.

6. Способ по любому одному из пп.1-5, дополнительно содержащий этап, на котором принимают (407) посредством инициатора ответное сообщение на первый запрос вызова от субъекта функции предоставления API, при этом ответное сообщение на первый запрос вызова указывает, что сервисный API успешно вызван.

7. Способ вызова сервисного интерфейса прикладного программирования (API), в котором метод безопасности субъекта функции предоставления API обновляется с исходного метода безопасности на новый метод безопасности, и метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором, при этом способ содержит этапы, на которых:

принимают (401) посредством субъекта функции ядра общей инфраструктуры API (CAPIF) запрос обновления для субъекта функции предоставления API от субъекта функции публикации API, при этом запрос обновления содержит новый метод безопасности;

сохраняют посредством субъекта функции ядра CAPIF новый метод безопасности; и

отправляют посредством субъекта функции ядра CAPIF новый метод безопасности в инициатор.

8. Способ по п.7, в котором запрос обновления дополнительно содержит информацию указания, и информация указания указывает субъекту функции ядра CAPIF отправить новый метод безопасности в инициатор.

9. Способ по п.7, при этом перед упомянутой отправкой субъектом функции ядра CAPIF нового метода безопасности в инициатор способ дополнительно содержит этап, на котором принимают посредством субъекта функции ядра CAPIF запрос получения от инициатора, при этом запрос получения используется для запрашивания нового метода безопасности.

10. Способ по любому одному из пп.7-9, в котором упомянутое сохранение субъектом функции ядра CAPIF нового метода безопасности содержит этап, на котором сохраняют посредством субъекта функции ядра CAPIF соответствие между инициатором, новым методом безопасности и субъектом функции предоставления API.

11. Способ вызова сервисного интерфейса прикладного программирования (API), в котором метод безопасности субъекта функции предоставления API обновляется с исходного метода безопасности на новый метод безопасности, и метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором, при этом способ содержит этапы, на которых:

принимают (402), посредством субъекта функции предоставления API, второй запрос вызова от инициатора с использованием исходного метода безопасности, причем второй запрос вызова используется для вызова сервисного API;

отправляют (403), посредством субъекта функции предоставления API, ответное сообщение на второй запрос вызова в инициатор, причем ответное сообщение на второй запрос вызова указывает то, что не удается вызвать сервисный API;

принимают (406), посредством субъекта функции предоставления API, первый запрос вызова от инициатора с использованием нового метода безопасности, при этом первый запрос вызова содержит имя сервисного API, и первый запрос вызова используется для вызова сервисного API; и

проверяют, посредством субъекта функции предоставления API, инициатор с помощью нового метода безопасности.

12. Способ по п.11, при этом перед упомянутым приемом субъектом функции предоставления API первого запроса вызова от инициатора с использованием нового метода безопасности способ дополнительно содержит этап, на котором отправляют посредством субъекта функции предоставления API новый метод безопасности в инициатор.

13. Способ по п.12, при этом перед упомянутой отправкой субъектом функции предоставления API нового метода безопасности в инициатор способ дополнительно содержит этапы, на которых:

принимают посредством субъекта функции предоставления API запрос согласования метода безопасности от инициатора, причем запрос согласования метода безопасности содержит список методов безопасности, поддерживаемых инициатором, и список методов безопасности содержит новый метод безопасности; и

отправляют посредством субъекта функции предоставления API ответ по согласованию метода безопасности в инициатор, при этом ответ по согласованию метода безопасности содержит новый метод безопасности.

14. Способ по любому одному из пп.11-13, в котором ответное сообщение на второй запрос вызова содержит значение причины, и значение причины указывает то, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

15. Способ по любому одному из пп.11-13, дополнительно содержащий этап, на котором отправляют (407) посредством субъекта функции предоставления API ответное сообщение на первый запрос вызова в инициатор, при этом ответное сообщение на первый запрос вызова указывает, что сервисный API успешно вызван.

16. Инициатор сервисного интерфейса прикладного программирования (API), содержащий блок обработки и блок связи, при этом метод безопасности субъекта функции предоставления API обновляется с исходного метода безопасности на новый метод безопасности, и метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором, причем

блок связи выполнен с возможностью отправлять второй запрос вызова в субъект функции предоставления API с использованием исходного метода безопасности, причем второй запрос вызова используется для вызова сервисного API, и принимать ответное сообщение на второй запрос вызова от субъекта функции предоставления API, причем ответное сообщение на второй запрос вызова содержит значение причины, и значение причины указывает то, что не удается вызвать сервисный API из-за несоответствия метода безопасности;

блок обработки выполнен с возможностью получения нового метода безопасности субъекта функции предоставления API; и

блок связи дополнительно выполнен с возможностью отправки первого запроса вызова в субъект функции предоставления API с использованием нового метода безопасности, при этом первый запрос вызова содержит имя сервисного API, и первый запрос вызова используется для вызова сервисного API.

17. Инициатор по п.16, в котором блок обработки конкретно выполнен с возможностью принимать, посредством использования блока связи, новый метод безопасности от субъекта функции ядра общей инфраструктуры API (CAPIF).

18. Инициатор по п.16, в котором перед тем, как блок обработки принимает новый метод безопасности от субъекта функции ядра общей инфраструктуры API (CAPIF), блок обработки дополнительно выполнен с возможностью запрашивать, посредством использования блока связи, новый метод безопасности у субъекта функции ядра CAPIF.

19. Инициатор по п.16, в котором блок обработки конкретно выполнен с возможностью принимать, посредством использования блока связи, новый метод безопасности от субъекта функции предоставления API.

20. Инициатор по п.19, в котором

блок связи дополнительно выполнен с возможностью отправлять запрос согласования метода безопасности в субъект функции предоставления API, причем запрос согласования метода безопасности содержит список методов безопасности, поддерживаемых инициатором, и список методов безопасности содержит новый метод безопасности; и

блок обработки конкретно выполнен с возможностью принимать, посредством использования блока связи, ответ по согласованию метода безопасности от субъекта функции предоставления API, причем ответ по согласованию метода безопасности содержит новый метод безопасности.

21. Инициатор по любому одному из пп.16-20, в котором блок связи дополнительно выполнен с возможностью принимать ответное сообщение на первый запрос вызова от субъекта функции предоставления API, при этом ответное сообщение на первый запрос вызова указывает, что сервисный API успешно вызван.

22. Субъект функции ядра общей инфраструктуры интерфейсов прикладного программирования (CAPIF), содержащий блок связи и блок хранения данных, при этом метод безопасности субъекта функции предоставления интерфейса прикладного программирования (API) обновляется с исходного метода безопасности на новый метод безопасности, и метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором, причем

блок связи выполнен с возможностью приема запроса обновления для субъекта функции предоставления API от субъекта функции публикации API, при этом запрос обновления содержит новый метод безопасности функции предоставления API; и

блок хранения данных приспособлен для сохранения нового метода безопасности,

при этом блок связи дополнительно выполнен с возможностью отправки нового метода безопасности в инициатор.

23. Субъект функции ядра CAPIF по п.22, при этом запрос обновления дополнительно содержит информацию указания, и информация указания указывает субъекту функции ядра CAPIF отправить новый метод безопасности в инициатор.

24. Субъект функции ядра CAPIF по п.23, в котором блок связи дополнительно выполнен с возможностью приема запроса получения от инициатора, при этом запрос получения используется для запрашивания нового метода безопасности.

25. Субъект функции ядра CAPIF по любому одному из пп.22-24, в котором блок хранения данных конкретно выполнен с возможностью сохранения соответствия между инициатором, новым методом безопасности и субъектом функции предоставления API.

26. Субъект функции предоставления интерфейса прикладного программирования (API), содержащий блок связи и блок обработки, при этом метод безопасности субъекта функции предоставления API обновляется с исходного метода безопасности на новый метод безопасности, и метод безопасности субъекта функции предоставления API используется для связи между субъектом функции предоставления API и инициатором, причем

блок связи выполнен с возможностью принимать второй запрос вызова от инициатора с использованием исходного метода безопасности, при этом второй запрос вызова используется для вызова сервисного API, отправлять ответное сообщение на второй запрос вызова в инициатор, причем ответное сообщение второго запроса вызова указывает то, что не удается вызвать сервисный API, и принимать первый запрос вызова от инициатора с использованием нового метода безопасности, при этом первый запрос вызова содержит имя сервисного API, и первый запрос вызова используется для вызова сервисного API; и

блок обработки выполнен с возможностью проверки инициатора с помощью нового метода безопасности.

27. Субъект функции предоставления API по п.26, в котором блок связи дополнительно выполнен с возможностью отправки нового метода безопасности в инициатор.

28. Субъект функции предоставления API по п.27, в котором блок связи дополнительно выполнен с возможностью:

принимать запрос согласования метода безопасности от инициатора, при этом запрос согласования метода безопасности содержит список методов безопасности, поддерживаемых инициатором, и список методов безопасности включает в себя новый метод безопасности; и

отправлять ответ по согласованию метода безопасности в инициатор, при этом ответ по согласованию метода безопасности содержит новый метод безопасности.

29. Субъект функции предоставления API по любому одному из пп.26-28, при этом ответное сообщение на второй запрос вызова содержит значение причины, и значение причины указывает то, что не удается вызвать сервисный API из-за несоответствия метода безопасности.

30. Субъект функции предоставления API по любому одному из пп.26-28, в котором блок связи дополнительно выполнен с возможностью отправки ответного сообщения на первый запрос вызова в инициатор, причем ответное сообщение на первый запрос вызова указывает, что сервисный API успешно вызван.

31. Машиночитаемый носитель данных, при этом машиночитаемый носитель данных хранит инструкции, и когда инструкции исполняются в компьютере, обеспечивается выполнение компьютером способа по любому из пп.1-15.

32. Устройство для вызова сервисного интерфейса прикладного программирования (API), содержащее:

по меньшей мере один процессор; и

память, которая подключена к по меньшей мере одному процессору и в которой хранятся программные инструкции, которые при их исполнении по меньшей мере одним процессором предписывают устройству выполнять способ по любому одному из пп.1-15.

33. Система вызова сервисного интерфейса прикладного программирования (API), содержащая инициатор по любому одному из пп.16-21 и субъект функции предоставления интерфейса прикладного программирования (API) по любому одному из пп.26-30.

34. Система по п.33, при этом система дополнительно содержит субъект функции ядра общей инфраструктуры интерфейсов прикладного программирования (CAPIF) по любому одному из пп.22-25.

Images