Способ идентификации сервиса в структуре enum

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

 

Техническое решение касается области электронных коммуникаций, в частности к методам идентификации и получения информации о сервисе на основе выполненных запросов через телекоммуникационные сети.

Из уровня техники известна система сопоставление (mapping) телефонных номеров Е.164 ENUM (Е.164 NUmber Mapping), согласно протоколам которой становится возможным объединение системы нумерации телефонов ЕЛ 64 с системой адресации Интернет.ENUM руководствуется приоритетом и алгоритмами использования системы доменных имен (DNS) для хранения и получения информации о ресурсах в соответствии с телефонным номером, который воспроизводится в доменном имени с набором ресурсных записей (NAPTR) о заранее определенных и известных типов сервисов в виде адресов в сети Интернет, правил и параметров их обработки, например

- VoIP,

- IP факс-серверов,

- серверов голосовой почты,

- Услуги ТфОП (перенаправление),

- и других, которые определены в соответствующем статическом депозитарии, информативно размещеном на странице IANA Enumservice Registrations.

Начальный и наиболее часто используемый сценарий ENUM - это настройки правил для перенаправления между телефонной сетью и системами интернет-телефонии VoIP. Например, если номер телефона имеет различные профили, с помощью ENUM можно автоматически изменить способ и расположение приема, перенаправив вызов в зависимости от того, в каком типе сети находится Принимающая сторона (Called Party согласно Рекомендации МСЭ Q.731) (автоматическое переключение между мобильным телефоном и VoIP для наиболее удобного или менее затратного способа связи для завершения звонка) или в зависимости от времени суток, например, если делается переадресация вызова во время обеденного перерыва. ENUM также может сопоставлять номер телефона с адресом электронной почты, веб-адресом или другим сервисом, определенным в депозитарии, указанном выше.

Из уровня техники известен патент РФ №2483352, в котором раскрыт способ идентификации сервиса, включая этапы, на которых принимают сервисный запрос, включающий в себя адрес унифицированного локатора ресурса и поле для указания типа содержания сервиса.

Описанный в патенте РФ №2483352 способ, устройство и система для идентификации сервиса предполагает наличие в архитектуре системы элемента в виде устройства шлюз протокола беспроводных приложений (WAP GW). WAP GW выполняет функции предварительно сконфигурированного устройства для приема сервисного запроса о мультимедийных сообщений (MMS), включающий в себя поле для указания типа содержимого сервиса из сервисного запроса, переданного с помощью терминала и устройства резолвинга (решения) сервисного запроса. Когда адрес сервисного шлюза (APN) настроен неверно, в результате чего данный запрос не может быть обработан на устройстве, идентификация типа сервиса из сервисного запроса происходит согласно с полем, включенным в сервисный запрос. Обращение по адресу непосредственно сервиса MMS, указанного в запросе, осуществляется за счет обращения к ENUM серверу, который содержит адрес домашнего MMSC отправителя, извлекает и возвращает его в WAP GW. WAP GW пересылает ответ на запрос терминала пользователя, который теперь получает возможность обратиться за полученным адресом непосредственно к сервису.

Недостатком известного решения является применение шлюза (WAP GW), задача которого инициировать обращение в ENUM сервера при неправильно сформированном адресе сервисного шлюза в рамках сервисного запроса. Это предполагает, что для идентификации сервиса неотъемлемым требованием является необходимость наличия адреса сервиса для выполнения запроса. Это накладывает дополнительные условия на процесс идентификации сервиса. Другим недостатком является то, что в существующих решении речь идет исключительно о коммуникационных сервисах.

Задачей заявленного технического решения является создание более универсального способа идентификации сервисов, который можно применять для любых типов сервисов, в том числе и некоммуникационных, и который не требует наличия шлюза (WAP GW), а также в котором нет необходимости заранее знать адрес сервиса. Дополнительной задачей для заявленного технического решения является выявление адреса сервиса, если предварительно известен тип сервиса и номер телефона абонента.

Поставленная задача решается за счет того, что способ идентификации сервиса включает этапы, на которых:

- формируют запрос на получение информации о сервисе,

согласно техническому решению,

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

затем с помощью второго сетевого средства, вносят в DNS-зону ENUM домена, ассоциированного с телефонным номером, по меньшей мере одну ресурсную запись, содержащую тип сервиса, ссылки на реестр сервисов, идентификатор сервиса в реестре, параметры сервиса для дальнейшего формирования обращения в реестр сервисов,

преобразовывают номер, определенным для ENUM способом, в доменное имя ENUM,

после этого с помощью третьего сетевого средства формируют DNS-запрос для получения ресурсных записей для данного доменного имени ENUM с помощью средств DNS,

направляют с DNS-сервера к третьему сетевому средству в ответ на DNS-запрос по меньшей мере одну ресурсную запись, ассоциированную с указанным доменным именем ENUM телефонного номера,

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

с помощью третьего сетевого средства формируют и осуществляют запрос в реестр сервисов, который по меньшей мере содержит идентификатор сервиса,

в ответ на обращение в реестр сервисов направляют на третье сетевое средство из реестра сервисов данные о сетевом адресе и метаданных сервиса.

Технический результат, который достигается при осуществлении заявленного способа, заключается в обеспечении получения сетевого адреса и метаданных по меньшей мере одного сервиса, ассоциируемого с абонентом телефонного номера. Эта информация выбирается из реестра сервисов, который хранит метаданные о сервисах. Реестр сервисов способен хранить информацию о сервисах любых типов, не ограничиваясь списком IANA Enumservice Registrations. При этом ссылка на реестр сервисов, и идентификатор сервиса сохраняется в ресурсных записях ENUM домена абонента. Метаданные, которые возвращаются реестром сервисов пригодны для машинной обработки. Данный технический результат получен впервые.

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

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

На Фиг. 1 изображена архитектуру системы для типового процесса идентификации сервиса в структуре ENUM по телефонному номеру абонента и использования идентифицированного сервиса.

На фиг. 2 изображена схема организации запросов и потоков данных способа.

На фиг. 3 предоставлено схему примера использования ENUM для получения медицинских данных абонента телефонного номера в рамках функционирования служб спасения населения при чрезвычайных событиях.

На фиг. 4 предоставлено схему примера использования ENUM для получения технической информации о транспортном средстве при техническом обслуживании транспортного средства.

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

Для более ясного и однозначного понимания сути заявленного способа, ниже приведены тезаурус использованных понятий.

Первое сетевое средство - сетевое техническое решение для преимущественно удаленной работы на сервере.

Второе сетевое средство - сетевое техническое решение, которое может быть использовано для редактирования DNS-зоны.

Третье сетевое средство - терминал, который получает информацию из DNS и реестра сервисов.

Абонентский номер (номер абонента) - телефонный номер по стандарту Е.164.

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

Сервис - программно-аппаратная система (набор телекоммуникационных и нетелекоммуникационных услуг, связанных с программно-аппаратными системами), который обеспечивает диалоговый обмен данными пользователю, имеет уникальный сетевой адрес (или несколько сетевых адресов), которая взаимодействует с другими сторонними приложениями путем обмена данными по запросам пользователя. Понимание понятия «сервис» по данному определению является более широким относительно приведенного аналогичного понятия в патенте РФ №2483352, но не противоречит ему.

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

Абонент телефонного номера - лицо или устройство, которому присвоен данный номер в формате Е.164.

Ресурсная запись - запись о соответствии имени и служебной информации в системе доменных имен (DNS).

DNS-сервер - программно-аппаратное решение для обеспечения функционирования иерархической системы доменных имен в соответствии со стандартами Интернет.

В существующем уровне техники типы сервисов должны быть заранее известны и предварительно определенными в репозитории IANA Enumservice Registrations. Данные в указанном репозитории не предназначены для автоматического считывания, а только статически пересчитывают набор доступных типов сервисов.

Согласно заявленному техническому решению, предложено создать реестр сервисов, которые должны отвечать следующим условиям: каждый сервис имеет по меньшей мере один оригинальный (неповторимый) уникальный идентификатор. Применяя этот уникальный идентификатор, реестр сервисов выполняет поиск и выдает сетевые адреса и метаданные относительно соответствующего сервиса.

Типы сервисов, хранящихся в реестре сервисов могут быть как телекоммуникационные, так и нетелекоммуникационные.

Реестр сервисов сохраняет блоки данных, в частности, относительно:

(1) свойств сервиса, включающие данные относительно (1.1) названия сервиса, (1.2) сетевые адреса сервиса (1.3) протокола для сервиса, (1.4) общее описание сервиса,

(2) функциональность и условия выполнения сервиса, включающие данные относительно (2.1) телекоммуникационных протоколов, используемых сервисом, (2.2) профессиональных протоколов, используемых сервисом, (2.3) формализованного описания структуры услуг, входящих в сервис, (2.4) скоррелированных с (2.3) минимальным набором параметров, необходимых для выполнения сервиса, (2.5) скоррелированных с (2.3) полного набора параметров, необходимых для выполнения сервиса, (2.6) допустимых минимальных и максимальных предельных значений параметров для выполнения сервиса,

(3) схемы доступа к сервису, включающие данные относительно (3.1) формализованного порядка последовательности действий по доступу к сервису, (3.2) релевантный им набор параметров для проведения процедур аутентификации, авторизации и верификации при доступе к сервису,

(4) требования к безопасности при использовании сервиса, включающие данные относительно (4.1) списка центров сертификации, которые могут выдавать сертификаты для использования с сервисом, (4.2) интервалов времени валидности для используемых сертификатов,

(5) форматы входных и выходных параметров сервиса, включающие данные относительно (5.1) спецификации исходных данных, необходимых для выполнения сервиса, которая коррелируется с (2.4) и (2.5), (5.2) спецификации исходных данных для каждой услуги, которая коррелируется с (2.3),

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

Этот перечень не является исчерпывающим, а также не содержит обязательных блоков данных.

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

Заявленное решение объясняется приведенной на фиг. 1 архитектурой. Стандарт DNS определяет несколько типов ресурсных записей 105 (А, АААА, ТХТ, MX, NAPTR и другие). Для доменного имени 102 может быть задано любое количество записей 105 любого из этих типов. В общем случае ресурсные записи 105 создаются и редактируются с помощью второго сетевого средства 107. Перечень ресурсных записей 105 и их структура могут изменяться с помощью второго сетевого средства 107.

DNS-зона 103 домена 102 обслуживается по меньшей мере одним DNS-сервером 104, который дает ответы на DNS-запросы 115 пользователей интернет, путем выбора соответствующих записей 105 с DNS-зоны 103.

В существующем уровне техники, ресурсные записи 105 содержат непосредственно ссылки на сервис 113. В заявленном решении, в ресурсных записях 105 не сохраняются непосредственно ссылки на сервис 113, зато ресурсный запись 105 содержит тип сервиса, ссылки на реестр сервисов 111, идентификатор сервиса и другую информацию, которая, например, идентифицирует объект 114 в сервисе 113, а также персонализирует условия применения сервиса 113.

Согласно заявленному способу, предварительно создают реестр сервисов 111, в который с помощью первого сетевого средства 110 вносят 120 хотя бы одну запись [о сервисе 113], характеризующую свойства сервиса 113. Реестр сервисов 111 выполнен с возможностью изменения, дополнения или удаления записей, характеризующих свойства сервисов 113.

С помощью второго сетевого средства 107 вносят 117 в DNS-зону 103 ENUM домена 102, ассоциированного 101 с телефонным номером 106, по меньшей мере один ресурсный запись 105, который содержит тип сервиса, ссылка 119 на реестр сервисов 111, идентификатор сервиса, параметры сервиса для дальнейшего формирования обращения в реестр сервисов 111, например идентификатор абонента телефонного номера 106 в сервисе 113.

Зная номер 106, потребитель сервиса 108 с помощью третьего сетевого средства 109, стандартным для ENUM способом преобразовывает этот номер в ассоциированное 101 с ним доменное имя ENUM 102.Для полученного путем преобразования доменного имени 102, от потребителя сервиса 108 с помощью третьего сетевого средства 109 стандартными средствами направляют DNS-запрос 115 на получение ресурсных записей 105 DNS-зоны 103 домена 102 к DNS-серверу 104, которой обслуживает это доменное имя 102 или является кэширующим DNS-сервером. В ответ на запрос 115, DNS-сервер 104 возвращает список ресурсных записей 105, относящихся к этому доменному имени 102. Количество ресурсных записей 105, возвращающихся DNS-сервером 104, может быть больше одного.

Получив с помощью третьего сетевого средства 109 список ресурсных записей 105, потребитель сервиса 108 с помощью третьего сетевого средства 109 выбирает из списка те ресурсные записи 105, которые содержат в себе указание нужного типа сервиса, которым желает воспользоваться потребитель сервисов 108.

Ресурсные записи 105 могут содержать любую дополнительную информацию (например, о параметрах, описывающих место и время использования сервиса), которые являются дополнительным фильтром для выбора нужных ресурсных записей 105.

Выбирается по меньшей мере одна ресурсная запись 105, из содержимого которой берут информацию о типе сервиса, берут ссылки 119 на реестр сервисов 111, идентификатор сервиса 113 в реестре сервисов 111, и другую информацию, которая, например, идентифицирует объект 114 для сервиса 113, а также персонализирует условия применения сервиса 113. На основе этих данных формируют и третьим сетевым средством 109 отправляют запрос 116 в реестр сервисов 111 для получения интернет-адресов и метаданных сервиса 112.

Реестр сервисов 111, получив запрос 116, содержащий идентификатор сервиса, возвращает 121 на третий сетевой средство 109 потребителю сервисов 108 метаданные и интернет-адреса сервиса 112.

Потребитель сервиса 108, используя полученные интернет-адреса и метаданные 112, с помощью третьего сетевого средства 109 обращается 118 до сервиса 113, за получением искомой услуги или информации.

На фиг 2. показана схема организации запросов и потоков данных способа идентификации сервиса при условии создания архитектуры, приведенной на фиг.1.

Потребитель сервиса 201 обращается 206 к DNS-серверу или кэширующего DNS-серверу 202, обслуживающего DNS-зону ENUM домена 103, для получения ресурсных записей 203. Следует отметить, что потребитель сервиса 201 выполняет действия с помощью третьего сетевого средства 109. Специалисту должно быть понятно, что DNS-зона ENUM домен в 103 обслуживается по меньшей мере одним DNS-сервером 202.

DNS-сервер 202 на основе имеющейся в DNS-зоне ENUM домена 103 информации определяет список ресурсных записей 203 и возвращает 207 его к потребителю сервиса 201.

С ресурсной записи 203 берут 208 информацию о типе сервиса, URI реестра сервисов, идентификатора сервиса, параметров сервиса. На основе этих полученных данных выполняют запрос 209 в реестр сервисов 204 с целью получить данные об интернет-адресе сервиса и метаданные сервиса. Реестр сервисов 204 на основе полученного запроса 209 направляет ответ 210 к третьему сетевому средству 109, который использует потребитель 201, в которой содержится эта информация о сервисе.

После этого потребитель сервиса 201 с помощью третьего сетевого средства 109 выполняет обращение к сервису 211, применяя полученные метаданные сервиса. В ответ потребитель 201 с помощью третьего сетевого средства 109 получает 212 результат работы сервиса.

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

Пример 1. Использование ENUM для получения медицинских данных абоненту телефонного номера, который является регистрантом соответствующего ENUM-домена в рамках функционирования служб спасения населения при чрезвычайных событиях (как пример создается тип сервиса "MED").

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

Предварительно, например, администратор реестра сервисов 301 с помощью программного обеспечения, например, пользуясь панелью администратора 302 вводит 303 в реестр сервисов 304 записи о сервисах 310, 311, которые содержат информацию, необходимую для служб спасения и, характеризующих свойства сервисов. Эти сервисы предоставляются двумя соответствующими медицинскими учреждениями.

Панель администратора реестра сервисов 302 выполнена с возможностью изменения, дополнения или удаления записей, характеризующих свойства сервисов. Примером сервиса, принадлежащим к службам спасения, могут выступать медицинские учреждения, которые по авторизованному запросу выдают сигнальную информацию о здоровье абонента. Пример сигнальной информации: группа крови, чувствительность к лекарственным средствам и т.п., то есть такая информация, указывающая на то, какие ограничения следует соблюдать при оказании медицинской помощи. Это должно быть понятно, что базы данных соответствующих медицинских учреждений, предоставляющих сервисы 321, 322, сохраняют сигнальную медицинскую информацию об абоненте телефонного номера 305. Эти записи медицинского характера, полученные в результате прохождения обследований, диспансеризации и других медицинских действий в отношении абонента телефонного номера в этих медицинских учреждениях.

Предварительно, абонентом телефонного номера 305 стандартными средствами для работы с доменными именами, например, панели регистранта 306, должно быть зарегистрировано ENUM доменное имя 307, соответствующее телефонному номеру абонента.

В DNS-зоне ENUM домена, с помощью средств работы с DNS-зонами, например, с помощью панели регистранта 306, создаются ресурсные записи NAPTR 308. Каждая такая запись содержит тип сервиса "MED", идентификатор сервиса, ссылка 309 на реестр сервисов 304 и идентификатор абонента телефонного номера в базе данных сервиса. Каждая из таких ресурсных записей соответствует одному медицинскому учреждению, где обслуживается абонент. Таким образом, каждое из медицинских учреждений является сервисом, который по авторизованным запросу предоставляет сигнальную медицинскую информацию, которая известна данному учреждению.

При необходимости оказания экстренной помощи абоненту телефонного номера, например, при поступлении сообщения 312 о необходимости оказания скорой медицинской помощи, зная номер абонента, диспетчер скорой помощи 313 с помощью специального программного обеспечения 314, обращается 315 к DNS-зоне ENUM домена абонента телефонного номера 305, находит там все ресурсные записи, содержащие тип сервиса "MED" 308, берет из этих записей идентификаторы сервисов, ссылки 309 на реестр сервисов 304, обращается в реестр сервисов 304 и получает 316 метаданные 310, 311 серверов медицинских учреждений 321, 322, впрочем URI, к которым может обратиться за сигнальной медицинской информацией об абоненте используя идентификаторы абонента телефонного номера в базах данных сервисов, которые так же содержатся в ресурсных записях ENUM домена 308.

Далее полученные данные передаются 317 программному обеспечению бригады врачей скорой помощи 318, которое в свою очередь с помощью авторизованных запросов 319, 320 к соответствующим сервисам 321, 322 получает сигнальную медицинскую информацию об абоненте телефонного номера.

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

Пример 2. Использование ENUM для получения технической информации о транспортном средстве при техническом обслуживании транспортного средства (в качестве примера создается тип сервиса "VEHICLE»).

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

Предварительно, например, администратор реестра сервисов 401 с помощью программного обеспечения, например, панели администратора реестра сервисов 402, вносит 403 в реестр сервисов 404 записи 410 о сервисе 417, который функционально принадлежит к службам, которые осуществляют техническое обслуживание транспортных средств и, который характеризует свойства сервиса. Панель администратора реестра сервисов 402 выполнена с возможностью изменения, дополнения или удаления записей, подобных 410, которые характеризуют свойства сервисов. Примером сервиса, принадлежащих к службам осуществляющих техническое обслуживание транспортных средств является станция технического обслуживания транспортных средств (СТО), которые по авторизованному запросу выдают имеющуюся техническую информацию о транспортных средствах, которые обслуживались на данной СТО. Пример технической информации: перечень и даты проведенных регламентных работ, марки моторных масел, которые применялись, выявленных кодов неисправностей с последующими рекомендациями по ремонту транспортного средства, список рекомендованных к замене запчастей, то есть такой информации, которая может быть полезной при следующих технических работах с транспортным средством.

Предварительно, стандартными средствами для работы с доменными именами, например, панели регистранта 406, должно быть зарегистрировано ENUM доменное имя 407 соответствующее телефонному номеру SIM карты, которая интегрирована в транспортное средство 405. То есть абонентом телефонного номера в данном случае является транспортное средство.

В DNS-зоне ENUM домена, с помощью средств работы с DNS, например, панели регистранта 406, создаются ресурсные записи NAPTR 408. Каждый такая запись содержит тип сервиса "VEHICLE", идентификатор сервиса, и ссылки 409 на реестр сервисов 404 и идентификатор абонента телефонного номера в базе данных сервиса. Каждый из таких ресурсных записей 408 соответствует одному техническому заведения, сервер которого 417 содержит соответствующие данные, и обслуживающий данное транспортное средство. Таким образом, каждое СТО является сервисом, который по авторизованным запросу предоставляет имеющуюся техническую информацию о транспортных средствах.

При необходимости выяснения истории обслуживания транспортного средства, например, при ремонте автомобиля в другом городе 411, зная номер SIM карты, которая интегрирована в автомобиль 405, работник СТО 412 с помощью специального программного обеспечения 413, обращается 414 к DNS-зоны ENUM домена абонента, находит там все ресурсные записи, содержащие тип сервиса "VEHICLE" 408, берет из этих записей идентификаторы сервисов, ссылки 409 на реестр сервисов 404, обращается в реестр сервисов 404 и получает 415 метаданные и интернет-адреса сервиса учреждения 417, к которой может обратиться за технической информацией о транспортном средстве, используя идентификаторы абонента телефонного номера (транспортного средства) в базах данных сервисов, которые так же содержатся в ресурсных записях ENUM домена 408.

Далее с помощью специализированного программного обеспечения 413, формируются авторизованные запросы 416 и получается техническая информация о транспортном средстве с интегрированной в него SIM картой.

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

На основе вышеприведенного специалисту должно быть понятно решение поставленной задачи и достижения заявленного технического результата.

Способ идентификации сервиса, включающий этапы, на которых:

- формируют запрос на получение информации о сервисе,

отличающийся тем, что

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

затем с помощью второго сетевого средства вносят в DNS-зону ENUM домена, ассоциированного с телефонным номером, по меньшей мере одну ресурсную запись, содержащую тип сервиса, ссылку на реестр сервисов, идентификатор сервиса в реестре, параметры сервиса для дальнейшего формирования обращения к реестру сервисов,

преобразовывают номер, определенным для ENUM способом, в доменное имя ENUM,

после этого с помощью третьего сетевого средства формируют DNS-запрос для получения ресурсных записей для данного доменного имени ENUM с помощью средств DNS,

направляют с DNS-сервера к третьему сетевому средству в ответ на DNS-запрос по меньшей мере одну ресурсную запись, ассоциированную с указанным доменным именем ENUM телефонного номера,

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

с помощью третьего сетевого средства формируют и осуществляют запрос в реестр сервисов, который по меньшей мере содержит идентификатор сервиса,

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