Способ идентификации онлайн-пользователя и его устройства в приложении
METHOD OF IDENTIFYING AN ONLINE USER AND DEVICE THEREOF IN AN APPLICATION

Настоящее изобретение относится к области информационных технологий, а именно к способу идентификации онлайн-пользователя и его устройства с помощью уникальных аппаратных и абонентских идентификаторов, например, таких как MSISDN, при нахождении устройства онлайн-пользователя в любой сети передачи данных в Приложении, имеющем доступ к чтению аппаратных идентификаторов устройства и пользователя.
Термины, используемые в тексте описания изобретения.
Приложение (APP) -  Программное Обеспечение для UD, приемлемо реализованное для участия в описываемом способе (в том числе, но не ограничиваясь, мобильное приложение, выполненное, в частности, но не только, по технологии нативного кода, SDK-кода с разработкой в IDE, а также PWA и/или аналогичной WEB-технологии, в частности, но не обязательно, с применением WebView компонентов). Приложение может являться также встроенной функцией или компонентом Операционной Системы устройства.
IS (Identification Service) – Сервис Идентификации, обеспечивающий точную идентификацию клиента. Все серверные и клиентские программно-аппаратные составляющие IS по необходимости, но не обязательно, могут быть частично или полностью представлены программно-аппаратными решениями контрагентов. В частности, функции определения MSISDN, отправки скрытых и обычных SMS могут (но не обязательно) выполняться компонентами, созданными и/или размещенными в инфраструктуре ОСС или иных программно-аппаратных инфраструктурах третьих сторон. Все серверные составляющие IS могут частично и/или полностью находиться в инфраструктурном периметре контрагентов на любом типе серверного размещения (в том числе, но не ограничиваясь, на одиночном физическом, виртуальном, связанных физических или виртуальных серверах, или облачных решениях). Все клиентские программные составляющие IS могут обновляться с серверной части IS. Взаимодействие серверных и клиентских частей, а также их обмен данными с третьим сторонами происходит по безопасному протоколу (за исключением случаев, требующих небезопасного протокола). Условием приемлемости для серверного и клиентского кода является возможность технического воспроизведения всех описанных в Способе шагов при условии соблюдения правил безопасности по эксплуатации UD.  IS включает в себя:
клиентский модуль (Client Module - CM) - программный код на пользовательской стороне, отдельно предварительно встраиваемый (или загружаемый с сервера IS) в Приложение, не влияющий на основной функционал Приложения, но добавляющий функционал по идентификации пользователя. CM может обновляться “на лету” в процессе работы Приложения.
серверный модуль (Server Module - SM)  - программный код на серверной стороне для выполнения функций обработки данных и необходимого обмена данными между всеми составляющими инфраструктуры реализации способа.
Сотовая связь (сеть подвижной связи) -  один из видов непрерывной при перемещении абонента мобильной радиосвязи в одном и том же частотном диапазоне, в основе которого лежит сотовая сеть, общая зона покрытия которой делится на ячейки (соты), определяющиеся частично перекрывающимися зонами покрытия отдельных базовых станций (БС).
OCC (Оператор Сотовой Связи) - компания, предоставляющая услуги сотовой связи для сотовых аппаратов своих абонентов. ОСС может инфраструктурно быть представлена как технически и юридически раздельные провайдеры разных входящих в сотовую связь функций. Некоторые провайдеры могут параллельно осуществлять одни и те же функции (в том числе, но не ограничиваясь, хранение реестра MSISDN, связок MSISDN, IMEI и IMSI, отправка скрытых и обычных SMS, определение местоположения абонентского оборудования)  считаясь при этом составной частью ОСС.
Скрытое SMS-сообщение - данное сообщение не выводится в интерфейсе мобильного устройства и пользователь его не видит.
MSISDN (Mobile Subscriber Integrated Services Digital Number) - номер мобильного абонента цифровой сети с интеграцией служб для связи в стандартах GSM, UMTS и пр.
SIM-карта (Subscriber Identification Module) - идентификационный электронный модуль абонента, применяемый в мобильной связи. Может быть выполнен как отдельный компонент, вставляемый в устройство связи, или находится штатно в устройстве за счет его аппаратно-программных средств.
ICCID (Integrated Circuit Card identifier) - уникальный серийный номер SIM-карты.
IMSI (International Mobile Subscriber Identity) – международный идентификатор мобильного абонента (индивидуальный номер абонента), ассоциированный с каждым пользователем мобильной связи стандарта GSM, UMTS или CDMA.
UHSI (Unique Hardware Subscriber Identifier) - уникальный аппаратный идентификатор пользователя, в том числе, но не ограничиваясь, -  абонента сотовой связи. В качестве UHSI может выступать, в частности, но не ограничиваясь, IMSI или ICCID, а также сертификаты в приложениях, операционной системе или идентифицирующие ключи на внешних аппаратных средствах.
UD (User’s Device) - любая произвольная программно-аппаратная среда пользователя (включая, но не ограничиваясь, удаленную виртуальную OS), обеспечивающая корректную работу необходимой части технического решения на стороне пользователя.
Хранилище  - любой технически приемлемый для обеспечения функционирования описываемой схемы контейнер для записи/хранения/чтения/редактирования/удаления информации в UD. В том числе, но не ограничиваясь, cookie или storage браузера, внутренний кэш приложения.
IMEI (International Mobile Equipment Identity) - международный идентификатор мобильного оборудования, обычно уникальный, используется для идентификации аппаратов GSM, WCDMA и IDEN, а также некоторых спутниковых устройств.
NUDID (Native Unique Device Identifier) - собственный аппаратный идентификатор устройства, предоставленный производителем устройства и хранимый на нем за счет штатных аппаратно-программных средств устройства (например, IMEI).
SUDID (Service Unique Device Identifier) - уникальный идентификатор устройства в SM, связанный на серверной стороне IS с собственным аппаратным идентификатором устройства пользователя (NUDID) и (по необходимости) с другими требуемыми данными пользователя, включая идентификаторы в других источниках данных и системах учета пользователя.
UCPUID (Unique Cross-platform User ID) - уникальный межплатформенный идентификатор (в частности, но не ограничиваясь, MSISDN, СНИЛС, ИНН, номер социального страхования, аккаунт в Социальной сети и т.д.), хранение связок (одна или более) которого с другими данными распределено между участвующими платформами, а первичным источником (центром выпуска) которого может являться одна или более из участвующих платформ.
UID (Unique User Identifier) - уникальный идентификатор пользователя в PS, связанный на серверной стороне PS с одним или несколькими UCPUID и другими необходимыми данными пользователя, включая идентификаторы в других источниках данных и системах учета пользователя..
UCIK (Unique Composite Identification Key) - уникальный составной ключ идентификации пользователя и устройства, включающий в себя SUDID и UID, служащий для однозначного определения Онлайн-сервисом пользователя и его устройства. UCIK может быть разовым - работающим в течение одной сессии и без записи/обновления в хранилище UD, а также многоразовым (обычный тип)  - с записью/обновлением в хранилище UD.
UIKF (User's Identification Key Fingerprint) - отпечаток UCIK, генерируемый в IS и позволяющий однозначно отличить пользователя на стороне Онлайн-сервиса, но не идентифицировать в IS. UIKF может быть разовым - работающим в течение одной сессии и без записи/обновления в хранилище UD, а также многоразовым (обычный тип) - с записью/обновлением в хранилище UD.
UTID (Unique Transaction Identifier) - генерируемый (серверной или клиентской частью) уникальный идентификатор транзакции для однозначного обозначения каждой конкретной операции взаимодействия элементов какой-либо Информационной Системы. В описываемом Способе, это уникальный идентификатор процедуры определения MSISDN пользователя.
UCC (Unique Confirmation Code) - уникальный код подтверждения, генерируемый и высылаемый из SM на устройство пользователя и отправляемый  пользователем обратно для верификации совершения пользователем определенной операции или данных (в данном случае  - определения MSISDN пользователя).
Данные - поддающееся многократной интерпретации представление информации в формализованном виде, пригодном для передачи, связи или обработки, которыми оперируют информационные системы и их пользователи.
Метаданные - информация о другой информации, или данные, относящиеся к дополнительной информации о содержимом или объекте. Метаданные раскрывают сведения о признаках и свойствах, характеризующих какие-либо сущности, позволяющие автоматически искать и управлять ими в больших информационных потоках.
Сеть (Вычислительная сеть, Компьютерная сеть) - система, обеспечивающая обмен данными между вычислительными устройствами (компьютеры, серверы, маршрутизаторы и другое оборудование). Для передачи информации могут быть использованы различные среды. Примеры Сети - Интернет, Интранет.
Пользователь - лицо или организация, которое использует Сеть для выполнения конкретной функции.
Сессия - сеанс взаимодействия CM и SM в пределах открытия и закрытия приложения (включая браузер).
Протокол передачи данных (далее - протокол) - набор соглашений интерфейса логического уровня, которые определяют обмен данными между различными программами. Эти соглашения задают единообразный способ передачи сообщений и обработки ошибок при взаимодействии программного обеспечения разнесённой в пространстве аппаратуры, соединённой тем или иным интерфейсом.
Безопасный протокол - протокол, обеспечивающий невозможность фальсификации третьими сторонами передаваемых данных.
В Сетях существует большое количество Онлайн-сервисов, предоставляющих онлайн-пользователям различные услуги. Для того, чтобы воспользоваться этими услугами, онлайн-пользователь в большинстве случаев должен пройти процедуру идентификации и аутентификации в этих Онлайн-сервисах,   предоставляя свои личные или платежные данные и подтверждая их. Это обусловлено условиями безопасного получения доступа к специальной информации или осуществлению финансовых или иных важных транзакций. Такая процедура создает неудобство  онлайн-пользователю, который каждый раз должен вручную вводить свои платежные или личные идентифицирующие данные, или при повторном обращении к Онлайн-сервису вводить пароль, ПИН-код или тому подобное. Владельцам пользовательских устройств доступ к информационным ресурсам предоставляется средствами их устройств, и безопасность информации, хранящейся на устройствах, или доступ к которой получают с их помощью, является важным вопросом. Для удобства онлайн-пользователей при решении различных задач и выполнении различных операций на своем пользовательском устройстве предусмотрены специализированные приложения. При использовании таких приложений важно безопасное сохранение информации о пользователе и его устройстве при получении доступа к ней.
Известна Система проведения денежных транзакций, согласно патенту RU2620715 с приоритетом от 31.05.2012. Система может включать в себя мобильное устройство, которое запускает приложение для работы в системе проведения денежных транзакций, а также абонента, который имеет профиль в системе. Абонент указывает транзакцию, которая должна быть выполнена в системе проведения денежных транзакций. Процессор системы выполняет транзакции, указываемые абонентом, включающие в себя обмен данными с базой данных денежных транзакций, чтобы определять, является или нет транзакция допустимой, на основе данных, указываемых в профиле абонента. При проведении транзакции система также включает в себя по меньшей мере один субъект, участвующий в указанной транзакции и имеющий профиль в системе. Этот субъект может быть человеком, розничным магазином, агентом или другим субъектом. Недостатком данной системы является то, что она для идентификации пользователя дополнительно выполняет проверки по программе идентификации клиентов согласно Bank Secrecy Act и US PATRIOT Act., т.е. в целях безопасности предполагает дополнительное сравнение идентификационных данных клиентов с государственными данными, удостоверяющими личность. Данная система безопасности предполагает ее использование ограниченным кругом лиц, данные о которых есть в Bank Secrecy Act и US PATRIOT Act. Кроме того, система предполагает изначальную настройку тех платежей, которые пользователь хочет провести, то есть предполагается обязательное наличие личного кабинета, где пользователь маркирует в некоем списке те транзакции, которые хочет провести - это приводит к требованию наличия отдельного приложения для использования способа и невозможности без предварительных действий выбрать способ оплаты и произвести ее.
Наиболее близким аналогом заявленного изобретения является известный Способ идентификации мобильного пользователя третьими лицами на основе карты модуля идентификации абонента (SIM-карта) и связанных с устройством параметров, доступных в телекоммуникационных сетях, по патенту GB2573262 с приоритетом от 08.03.2018. Способ состоит из этапов: - Мобильный пользователь пытается взаимодействовать с Приложением или получить доступ к веб-сайту, разработчик Приложения/веб-сайта передает запрос мобильного идентификатора внешнему серверу IPification; Сервер IPification передает до шести запросов мобильного ID в виде вызовов API на сервер оператора мобильной связи, при этом каждый запрос мобильного ID основан на одном из следующих входных параметров, связанных с SIM-картой/устройством: IMSI, ICCID, IMEI, MSISDN, частный IP и общественный IP; - Сервер оператора мобильной связи передает мобильные идентификаторы обратно на сервер IPification; при этом каждый из мобильных идентификаторов генерируется в ответ на один из запросов мобильного ID, отправленных на сервер оператора мобильной связи в качестве входных параметров, и при этом каждый идентификатор мобильной связи является уникальным буквенно-цифровым идентификатором пользователя, являющегося абонентом услуг мобильной связи, предоставляемых оператором мобильной связи; - Сервер IPification проверяет, идентичны ли все идентификаторы мобильных устройств, полученные от сервера оператора мобильной связи, и в зависимости от результата проверки реагирует двумя альтернативными способами: Если результат проверки положительный, сервер IPification предоставляет единый мобильный идентификатор пользователя разработчику Приложения/веб-сайта, тем самым аутентифицируя мобильного пользователя и позволяя ему взаимодействовать с Приложением или получать доступ к веб-сайту; - Если результат проверки отрицательный, сервер IPification предоставляет разработчику Приложения/веб-сайта информацию о неудачной аутентификации пользователя, и в результате пользователю не разрешается взаимодействовать с Приложением или получать доступ к веб-сайту. Недостатком данного способа является использование его только для мобильного Интернета, что значительно сужает возможности пользователя в реальных обстоятельствах, например, когда доступ к Сети возможен только через беспроводную компьютерную сеть WiFi.
Предлагаемое изобретение решает техническую проблему по устранению указанных недостатков, а именно обеспечивает надежную идентификацию онлайн-пользователя и его устройства в любой сети передачи данных при загруженном на пользовательское устройство Приложении, имеющем доступ к чтению аппаратных идентификаторов устройства и онлайн-пользователя после его первичной идентификации в Приложении.
Технический результат изобретения заключается в  повышении надежности идентификации онлайн-пользователя и его устройства с помощью Сервиса Идентификации, включающего клиентский и серверный модули, причем клиентский модуль включен в загруженное на устройство онлайн-пользователя Приложение, которому доступны уникальные аппаратные и абонентские идентификаторы онлайн-пользователя, такие как номер мобильного абонента цифровой сети с интеграцией служб для связи в стандартах GSM, UMTS и пр. (MSISDN) или уникальный составной ключ идентификации пользователя и устройства (UCIK), который связан с MSISDN. В результате обеспечивается безопасный доступ к информационным ресурсам и платежным системам за счет определения и подтверждения уникальных аппаратных и абонентских идентификаторов из Приложения.
Технический результат реализуется за счет следующих этапов осуществления способа идентификации онлайн-пользователя и его устройства в Приложении. Онлайн-пользователь устанавливает на свое пользовательское устройство Приложение и запускает его. Отличие описываемого в данном изобретении Способа заключается в том, что клиентский модуль Сервиса Идентификации включен в установленное Приложение, с помощью которого считывают с пользовательского устройства его собственный аппаратный идентификатор устройства (Native Unique Device Identifier - NUDID) и уникальный аппаратный идентификатор пользователя (Unique Hardware Subscriber Identifier - UHSI), привязанный в данном устройстве к NUDID. Генерируют уникальный идентификатор транзакции (UTID) для однозначного обозначения каждой конкретной операции. Получают связку идентификаторов UHSI, NUDID и UTID от клиентского модуля, определяют по полученному UHSI или NUDID номер мобильного абонента цифровой сети (Mobile Subscriber Integrated Services Digital Number - MSISDN) и сравнивают полученную от клиентского модуля связку UHSI и NUDID с актуализированной связкой идентификаторов UHSI и NUDID, полученной после определения номера мобильного абонента цифровой сети (Mobile Subscriber Integrated Services Digital Number - MSISDN). Затем генерируют серверным модулем Сервиса Идентификации уникальный идентификатор пользователя (Unique User Identifier - UID), уникальный идентификатор пользовательского устройства (Service Unique Device Identifier - SUDID), уникальный составной ключ идентификации пользователя и его устройства (Unique Composite Identification Key - UCIK),  отпечаток UCIK (User's Identification Key Fingerprint - UIKF) и передают составной ключ UCIK и его отпечаток UIKF клиентскому модулю в Приложении. В случае несоответствия актуализированной связки UHSI и NUDID связке, полученной от клиентского модуля, либо подозрения на некорректность определения, отправляют сообщение по полученному номеру MSISDN на пользовательское устройство, например, скрытое SMS-сообщение, содержащее уникальный код подтверждения (Unique Confirmation Code - UCC). Затем считывают код UCC из сообщения, сравнивают код, полученный от клиентского модуля, и код, отправленный им на номер MSISDN, проверяют, соответствует ли присланный идентификатор транзакции UTID присланному ранее идентификатору. При совпадении кодов онлайн-пользователя и его устройство считают подтвержденными. В случае если онлайн-пользователь и его устройство ранее проходили идентификацию, но у Приложения в текущий момент отсутствует доступ к чтению аппаратных идентификаторов устройства и онлайн-пользователя, то с помощью клиентского модуля считывают с пользовательского устройства уникальный составной ключ идентификации пользователя и его устройства UCIK и направляют в Сервис Идентификации для определения по ключу UCIK первой связки аппаратного идентификатора устройства (NUDID) и номера мобильного абонента цифровой сети (MSISDN), зарегистрированного  при последнем определении MSISDN пользователя. Далее определяют текущий номер  MSISDN по идентификатору устройства NUDID и получают их следующую вторую связку. Актуализируют третью связку  идентификатора  NUDID и номера  MSISDN на пользовательском устройстве и сравнивают с ранее полученными связками идентификатора  NUDID и номера  MSISDN, при совпадении связок онлайн-пользователя и его устройство считают подтвержденными. При совпадении только второй связки по текущему номеру  MSISDN и третьей связки, актуализированной на пользовательском устройстве, генерируют серверным модулем Сервиса Идентификации уникальный идентификатор пользователя (UID), уникальный идентификатор пользовательского устройства (SUDID), уникальный составной ключ идентификации пользователя и его устройства (UCIK),  отпечаток UCIK (UIKF),  и передают составной ключ UCIK и его отпечаток UIKF клиентскому модулю в Приложении.  В случае не идентифицированного онлайн-пользователя и его устройства ранее в Приложении и отсутствии доступа у Приложения к чтению аппаратных идентификаторов устройства и онлайн-пользователя идентификацию предоставляют по его номеру MSISDN в ручном режиме на время сессии без записи его разового ключа UIKF в хранилище Сервиса Идентификации.
Следует пояснить, что все серверные и клиентские программно-аппаратные составляющие Сервиса Идентификации могут быть частично или полностью представлены программно-аппаратными решениями контрагентов. При этом все серверные составляющие Сервиса Идентификации могут частично и/или полностью находиться в инфраструктурном периметре контрагентов на любом типе серверного размещения, а клиентские составляющие могут обновляться с серверной части. Взаимодействие серверных и клиентских частей, а также их обмен данными с третьим сторонами происходит по безопасному протоколу.
Таким образом, идентификация онлайн-пользователя и его устройства, подключенного к любой сети передачи данных, осуществляемая за счет клиентского модуля Сервиса Идентификации, встроенного в установленное Приложение на пользовательское устройство с первичной идентификацией онлайн-пользователя, которое имеет доступ к чтению аппаратных идентификаторов устройства пользователя и самого онлайн-пользователя, позволяющее  записать в хранилище Сервиса Идентификации полученную связку аппаратных идентификаторов, генерировать уникальный идентификатор транзакции для однозначного обозначения конкретной операции, сравнить связку аппаратных идентификаторов от клиентского модуля с актуализированной связкой аппаратных идентификаторов, полученных после определения номера мобильного абонента цифровой сети, генерировать серверным модулем Сервиса Идентификации уникальные идентификаторы пользователя и его устройства, их уникальный составной ключ идентификации и отпечаток этого ключа для передачи клиентскому модулю в Приложение, и в результате с большой точностью идентифицировать онлайн-пользователя и его устройство в Сети. Также при несовпадении актуализированной связки аппаратных идентификаторов связке, полученной от клиентского модуля, отправляется сообщение по данному номеру мобильного абонента цифровой сети на пользовательское устройство, содержащее уникальный код подтверждения, который считывается и отправляется на серверный модуль сервиса идентификации,  полученный от клиентского модуля код подтверждения сравнивается с кодом, отправленным на номер MSISDN, и проверяется соответствие присланного идентификатора транзакции присланному ранее идентификатору, в результате при совпадении кодов идентификация онлайн-пользователя и его устройства считаются подтвержденными. При условии, если  у Приложения в текущий момент отсутствует доступ к чтению аппаратных идентификаторов устройства и онлайн-пользователя, то с помощью клиентского модуля считывают с пользовательского устройства уникальный составной ключ идентификации пользователя и его устройства и направляют в Сервис Идентификации для определения по ключу первой связки аппаратного идентификатора устройства и номера мобильного абонента цифровой сети MSISDN, зарегистрированного  при последнем его определении у пользователя, затем определяют текущий номер  MSISDN по идентификатору устройства и получают их следующую вторую связку, актуализируют третью связку  идентификатора  устройства и номера  MSISDN на пользовательском устройстве и сравнивают с ранее полученными связками идентификатора  устройства и номера  MSISDN, при совпадении связок онлайн-пользователь и его устройство считаются подтвержденными. Также при совпадении только второй связки по текущему номеру  MSISDN и третьей связки, актуализированной на пользовательском устройстве, генерируют серверным модулем Сервиса Идентификации уникальный идентификатор пользователя (UID), уникальный идентификатор пользовательского устройства (SUDID), уникальный составной ключ идентификации пользователя и его устройства (UCIK),  отпечаток UCIK (UIKF),  и передают составной ключ UCIK и его отпечаток UIKF клиентскому модулю в Приложении, чем подтверждают онлайн-пользователя и его устройство. Кроме того, онлайн-пользователю,  ранее не идентифицированному в Приложении, в случае отсутствия у Приложения доступа к чтению аппаратных идентификаторов устройства и онлайн-пользователя предоставляется возможность получить идентификацию по его номеру мобильного абонента цифровой сети в ручном режиме на время сессии без записи его разового уникального составного ключа идентификации в хранилище Сервиса Идентификации, что позволяет обеспечить безопасный доступ к информационному ресурсу. Следовательно, всей совокупностью указанных этапов осуществления способа реализуется указанный технический результат, заключающийся в  повышении надежности идентификации онлайн-пользователя и его устройства в Приложении и обеспечении безопасности доступа к информационным ресурсам Сети.
Изобретение осуществляется следующим образом:
Пользователь устанавливает себе на устройство Приложение со встроенным или загружаемым с сервера Клиентским модулем (Client Module, или CM) Сервиса Идентификации (Identification Service, или IS) и запускает его.
CM проверяет наличие доступа к чтению идентификаторов NUDID и UHSI.
CM имеет доступ к чтению NUDID и UHSI.
CM считывает с устройства его NUDID (Native Unique Device Identifier  - собственный аппаратный идентификатор устройства) и UHSI (Unique Hardware Subscriber Identifier - уникальный аппаратный идентификатор пользователя), привязанный в этом устройстве к этому NUDID.
CM посылает в Серверный модуль (Server Module - SM) IS запрос, содержащий UHSI, NUDID и UTID (Unique Transaction Identifier - генерируемый в CM или SM уникальный идентификатор транзакции).
SM получает NUDID, UHSI и UTID и определяет MSISDN (Mobile Subscriber Integrated Services Digital Number - номер мобильного абонента цифровой сети) по полученному UHSI или NUDID, актуализирует и сохраняет связку UHSI и NUDID, производит сравнение актуализированной связки UHSI и NUDID со связкой, полученной от СМ.
Если актуализированная связка UHSI и NUDID соответствует связке, присланной CM, то:
SM генерирует по необходимости UID, SUDID, UCIK и UIKF, обновляет у себя по необходимости связку UHSI и MSISDN, отдает UCIK, UIKF и по необходимости MSISDN в ответе в CM.
CM записывает/обновляет UCIK, UIKF и по необходимости MSISDN в хранилище.
Приложение получает UIKF или UIKF и по необходимости MSISDN от CM.
Если актуализированная связка UHSI и NUDID не соответствует связке, присланной CM (либо прислан только UHSI или NUDID, или по косвенным признакам есть подозрение на некорректность определения), то:
SM отправляет сообщение по данному MSISDN на UD (User’s Device - любая произвольная программно-аппаратная среда пользователя), например, скрытое SMS-сообщение, с UCC (Unique Confirmation Code - уникальный код подтверждения).
CM считывает UCC из сообщения.
CM посылает запрос, содержащий полученный UCC и UTID, в SM.
SM сравнивает код, полученный от CM, и код, отправленный им на MSISDN, а также проверяет, что присланный UTID соответствует идентификатору, присланному ранее из CM в SM. Если коды совпадают, номер считается подтвержденным и происходит переход к шагам, когда актуализированная связка UHSI и NUDID соответствует связке, присланной CM (см. выше пункт 2.a.iii.1).
CM не имеет доступ к чтению NUDID и UHSI.
CM получает доступ к чтению NUDID и UHSI в ручном или автоматическом режиме. Переход к шагам, когда доступ есть (см. выше пункт 2.а).
CM не получает доступ к чтению NUDID и UHSI. CM проверяет наличие UCIK (Unique Composite Identification Key - уникальный составной ключ идентификации пользователя и устройства) в хранилище UD (User’s Device - любая произвольная программно-аппаратная среда пользователя).
UCIK в хранилище UD есть.
Происходит запрос от CM к SM с передачей UCIK.
SM по UCIK определяет NUDID и MSISDN (первая связка), которые были зарегистрированы при последнем определении MSISDN пользователя.
SM по NUDID определяет текущий MSISDN  (вторая связка).
Для актуализации связки NUDID и MSISDN SM отправляет команду/сообщение (например, но не ограничиваясь, скрытую SMS) на текущий MSISDN.
в случае доставки сообщения SM получает актуальную пару NUDID и MSISDN (третья связка), после чего происходит переход к дальнейшим шагам (см. ниже пункт 2.b.ii.1.e).
в случае недоставки команды/сообщения происходит переход к шагам, когда UCIK в хранилище нет (см. ниже пункт 2.b.ii.2).
SM сравнивает старые и новые значения NUDID и MSISDN по трем связкам, после чего возможно три варианта сценария:
если все три связки NUDID и MSISDN совпадают, то
SM возвращает статус успешной идентификации в CM.
Приложение получает UIKF или UIKF и MSISDN (по необходимости) от CM.
если вторая и третья связки совпадают, то
SM генерирует по необходимости новые SUDID, UID, UCIK и UIKF, обновляет у себя по необходимости связку UHSI и MSISDN, возвращает в CM новый UCIK, UIKF, MSISDN (по необходимости) и статус успешной идентификации.
CM записывает/обновляет UCIK и UIKF в хранилище.
Приложение получает UIKF или UIKF и MSISDN (по необходимости) от CM.
Во всех остальных случаях сличения связок происходит переход к шагам, когда UCIK в хранилище нет (см. ниже пункт 2.b.ii.2)
UCIK в хранилище UD нет.
CM показывает форму для ввода пользователем MSISDN, пользователь вводит и отправляет через форму в SM свой MSISDN, вследствие чего форма меняется и показывает поле для ввода UCC (Unique Confirmation Code - уникальный код подтверждения).
SM генерирует и отправляет на UD код подтверждения (UCC), включая, но не ограничиваясь, SMS, нотификациями в Приложение или сообщениями в мессенджер.
Пользователь вводит в форме UCC, который CM отправляет в SM.
SM проверяет валидность UCC, и в случае его валидности отдает в CM ответ со статусом валидности кода генерирует по необходимости UID, SUDID, разовый UCIK и разовый UIKF и отправляет в CM только разовый UIKF и MSISDN (по необходимости) пользователя с указанием для CM не записывать UIKF в хранилище. Пользователь получает идентификацию по его MSISDN на время сессии.
Приложение получает UIKF или UIKF и по необходимости MSISDN от CM.
Схема способа идентификации онлайн-пользователя и его устройства в приложении представлена на Фиг.1.
Пример 1.
Способ идентификации онлайн-пользователя и его устройства при наличии у Клиентского модуля (Client Module - CM) Сервиса Идентификации (Identification Service - IS) доступа к чтению NUDID (Native Unique Device Identifier - собственный аппаратный идентификатор устройства) и UHSI (Unique Hardware Subscriber Identifier - уникальный аппаратный идентификатор пользователя), а также при совпадении актуальной связки UHSI и NUDID и связки, присланной Клиентским модулем, осуществляется в следующей последовательности согласно схеме на Фиг.1:
a. Запрос от CM в SM с передачей UHSI, NUDID и UTID (Unique Transaction Identifier - генерируемый в CM или SM уникальный идентификатор транзакции).
b. SM определяет MSISDN (Mobile Subscriber Integrated Services Digital Number - номер мобильного абонента цифровой сети) по полученному UHSI. SM генерирует по необходимости UID, SUDID, UCIK и UIKF, обновляет у себя по необходимости связку UHSI и MSISDN, отдает UCIK, UIKF и по необходимости MSISDN в ответе в CM.
c. CM записывает/обновляет UCIK, UIKF и по необходимости MSISDN в хранилище и передает UIKF или UIKF и по необходимости MSISDN в Приложение.
Таким образом, идентификация онлайн-пользователя и его устройства при запросе пользователя из приложения по любому каналу связи была произведена с абсолютной точностью, благодаря сравнению и подтверждению уникального идентификатора пользователя и его устройства по аппаратным идентификаторам устройства и пользователя с помощью серверного и клиентского модулей, что обеспечивает безопасный доступ к информационным ресурсам.
Пример 2.
Способ идентификации онлайн-пользователя и его устройства при наличии у Клиентского модуля доступа к чтению NUDID и/или UHSI, а также при несовпадении актуальной связки NUDID и UHSI и связки, присланной Клиентским модулем, с автоматической верификацией MSISDN пользователя - осуществляется в следующей последовательности согласно схеме на Фиг.1:
a. Запрос от CM в SM с передачей UHSI, NUDID и UTID (Unique Transaction Identifier - генерируемый в CM или SM уникальный идентификатор транзакции).
b. SM определяет MSISDN по полученному UHSI или NUDID. SM отправляет сообщение по данному MSISDN на UD (User’s Device - любая произвольная программно-аппаратная среда пользователя), например, скрытое SMS-сообщение с UCC (Unique Confirmation Code - уникальный код подтверждения).
c. CM считывает UCC из сообщения. CM посылает запрос, содержащий UTID и полученный UCC, в SM.
d. SM сравнивает код, полученный от CM, и код, отправленный им на MSISDN, а также проверяет, что присланный UTID соответствует идентификатору, присланному ранее из CM в SM. Если коды совпадают (иначе см. Пример 4), номер считается подтвержденным и SM генерирует по необходимости UID, SUDID, UCIK и UIKF, обновляет у себя по необходимости связки UHSI/MSISDN и NUDID/MSISDN, отдает UCIK, UIKF и по необходимости MSISDN в ответе в CM.
e. CM записывает/обновляет UCIK, UIKF и по необходимости MSISDN в хранилище и передает UIKF или UIKF и по необходимости MSISDN в Приложение.
Таким образом, идентификация онлайн-пользователя и его устройства при запросе пользователя из приложения по любому каналу связи была произведена с абсолютной точностью, благодаря сравнению и подтверждению уникального идентификатора пользователя и его устройства посредством команды/сообщения для сличения аппаратных идентификаторов пользователя и устройства с помощью серверного и клиентского модулей, что обеспечивает безопасный доступ к информационным ресурсам.
Пример 3.
Способ идентификации онлайн-пользователя и его устройства при отсутствии у Клиентского модуля доступа к чтению NUDID и UHSI и наличии UCIK (Unique Composite Identification Key - уникальный составной ключ идентификации пользователя и устройства) в хранилище UD (User’s Device - любая произвольная программно-аппаратная среда пользователя), с автоматической верификацией MSISDN пользователя - осуществляется в следующей последовательности согласно схеме на Фиг.1:
Запрос от CM в SM с передачей UCIK.
SM по UCIK определяет NUDID и MSISDN (первая связка), которые были зарегистрированы при последнем определении MSISDN пользователя. SM по NUDID определяет текущий MSISDN  (вторая связка). Для актуализации связки NUDID и MSISDN SM отправляет команду/сообщение (например, но не ограничиваясь, скрытую SMS) на текущий MSISDN.
Устройство сообщает в SM о доставке сообщения (иначе см. Пример 4).
SM получает актуальную пару NUDID и MSISDN (третья связка), сравнивает старые и новые значения NUDID и MSISDN по трем связкам, после чего возможно два варианта сценария:
если все три связки NUDID и MSISDN совпадают, то
SM возвращает статус успешной идентификации в CM.
Приложение получает UIKF или UIKF и по необходимости MSISDN от CM.
если вторая и третья связки совпадают, то
SM генерирует по необходимости новые SUDID, UID, UCIK и UIKF, обновляет у себя по необходимости связку UHSI и MSISDN, возвращает в CM новый UCIK, UIKF, по необходимости MSISDN и статус успешной идентификации.
CM записывает/обновляет UCIK и UIKF в хранилище и передает в приложение UIKF или UIKF и по необходимости MSISDN.
Таким образом, идентификация онлайн-пользователя и его устройства при запросе пользователя из приложения по любому каналу связи была произведена с абсолютной точностью, благодаря сравнению и подтверждению уникального идентификатора пользователя и его устройства посредством команды/сообщения для сличения аппаратных идентификаторов пользователя и устройства с помощью серверного и клиентского модулей, что обеспечивает безопасный доступ к информационным ресурсам.
Пример 4.
Способ идентификации онлайн-пользователя и его устройства при отсутствии у Клиентского модуля Сервиса Идентификации доступа к чтению NUDID и UHSI и отсутствии UCIK  в хранилище UD - с ручной верификацией MSISDN пользователя - осуществляется в следующей последовательности согласно схеме на Фиг.1:
a. Запрос из CM в SM для получения формы с полем для ввода MSISDN.
b. Получение на UD от SM формы с полем для ввода MSISDN.
c. Передача MSISDN через форму от UD в SM. Изменение формы для показа поля ввода UCC  (Unique Confirmation Code - уникальный код подтверждения).
d. Генерация кода подтверждения в SM и его отправка в UD, в том числе, но не ограничиваясь, через SMS, нотификацию в Приложении или сообщение в мессенджер.
e. Передача UCC вводом пользователя или автоматическим считыванием из CM в SM.
f. SM проверяет валидность UCC, и в случае его валидности отдает в CM ответ со статусом валидности кода, генерирует по необходимости UID, SUDID, разовый UCIK и разовый UIKF и отправляет в CM только разовый UIKF пользователя с указанием для CM не записывать UIKF в хранилище. Пользователь получает идентификацию по его MSISDN на время сессии.
g. CM передает разовый UIKF или разовый UIKF и по необходимости MSISDN в Приложение.
Таким образом, идентификация онлайн-пользователя и его устройства при запросе пользователя из приложения по любому каналу связи была произведена с абсолютной точностью, благодаря сравнению и подтверждению уникального идентификатора пользователя и его устройства при ручной идентификации пользователя с помощью серверного и клиентского модулей, что обеспечивает безопасный доступ к информационным ресурсам.