Способ создания платежной системы

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

 

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

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

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

Известны способы проведения платежей с использованием пластиковых карт VISA™ и других карт, но идентификаторы карт трудно запомнить, и эти идентификаторы не являются сетевыми, что не позволяет их использовать непосредственно в слое сетевых протоколов сетей связи и Интернет. Известные системы проведения платежей PayPal, Яндекс.Деньги и другие платежные системы, использующие идентификаторы электронной почты, однако эти идентификаторы не позволяют проводить платежи в режиме реального времени, так как предполагают использование сетевого протокола SMTP, который не обеспечивает доставку сообщений в режиме реального времени. Все упомянутые системы не предоставляют облачных услуг (cloud service) быстрого и недорогого создания платежных систем с использованием оборудования и программного обеспечения упомянутых платежных систем, они также не предоставляют безымянных (White Label) решений, что позволило бы их клиентам продвигать собственные бренды в качестве наименований платежной системы, построенной с использованием упомянутых облачных услуг. Известен способ идентификации транзакционных счетов и обмена транзакционными сообщениями между сторонами проведения транзакции (патентная заявка США №20050114367, A1, серийный №927460/10, опубл. 26.05.2005, автор О.А.Серебренников), далее названный способ именуется Заявка Серебренникова или Способ Серебренникова. Однако способ Серебренникова не предлагает способа создания платежных систем путем предоставления облачных услуг безымянной системы.

Таким образом, разработка собственной платежной системы является в настоящее время длительным и затратным производством, кроме того, имеющим немалую стоимость владения, что делает затруднительным создание собственной платежной системы, особенно для небольших компаний. Еще одним естественным ограничением является сложность расширения платежной системы за рамки собственной клиентской базы, так как это приводит к смещению фокуса деятельности компании в область платежных систем, в то время как обслуживание одной только собственной клиентской базы может иметь слишком высокую усредненную стоимость обслуживания одного клиента. Другим ограничением в настоящее время является то, что расходы на проведение платежей через платежные системы третьих сторон могут достигать 30% от суммы платежа, как в случае с платежной системой компании Apple (https://developer.apple.com/appstore/in-app-purchase/ln-App-Purchase-Guidelines.pdf), которой для проведении платежей внутри приложений (in-app платежи) обязаны пользоваться все разработчики приложений для операционной системы iOS.

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

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

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

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

Раскрытие изобретения

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

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

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

Предпочтительно, упомянутые сетевые идентификаторы являются DNS именами или идентификаторами Uniform Resource Identifier (URI), a сетевые адреса являются IP адресами.

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

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

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

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

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

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

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

Предпочтительно, в инструкции проведения транзакции не размещают идентификатор СИСС, а транзакцию проводят в отношении расшифрованного идентификатора транзакционного счета.

Предпочтительно, записью счета является запись счета платежной карты.

Предпочтительно, упомянутую запись счета шифруют с использованием открытого ключа Сегмента.

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

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

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

Предпочтительно, создают множество СИСС, каждый из которых является DNS идентификатором, причем для создания СИСС используют адрес электронной почты, в котором, по меньшей мере, знак <@> заменяют знаком точка <.>

Предпочтительно, создают множество СИСС, каждый из которых является DNS идентификатором, причем для создания СИСС используют номер телефона пользователя и DNS имя оператора телефонной связи, для чего, по меньшей мере, номер телефона присоединяют слева к DNS имени оператора телефонной связи, разделяя упомянутый, по меньшей мере, номер телефона и упомянутое DNS имя знаком точка <.>.

Примеры осуществления изобретения

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

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

Вкратце способ Серебренникова раскрывает способ проведения, например, платежа в Интернет, причем идентификатором счета плательщика и получателя платежа в платежной системе являются действительные DNS имена, например payer.pay и payee.pay, в данном случае зарегистрированные в предполагаемом домене верхнего уровня .PAY. Каждому из DNS имен сопоставлен IP адрес сервера платежной системы, обслуживающей соответственно счет плательщика или получателя платежа, таким образом, после разрешения указанных DNS имен в IP адреса, например в случае

Payer.pay?payer.pay&.payee.pay&$100,

будет установлено соединение соответственно с сервером платежной системы плательщика, куда будет передана инициация платежа (HTTP запрос)

payer.pay&payee.pay&$100.

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

Сценарий покупки электронного билета

Проиллюстрируем использование заявки Серебренникова на примере покупки билета на предполагаемом сайте etickets.pay, причем покупателю принадлежит идентификатор payer.pay, которому поставлен в соответствие IP адрес платежной системы. Покупатель билета посещает страницу сайта etickets.pay, выбирает билет и выбирает способ оплаты с использованием способа заявки Серебренникова. Покупателю предлагается согласиться с суммой и условиями оплаты, а также указать DNS идентификатор счета плательщика в платежной системе. Плательщик вводит свой идентификатор счета payer.pay в специальное поле страницы оплаты сайта etickets.pay. После этого сайт etickets.pay создает строку

Payer.pay?payer.pay&etickets.pay&$100

и использует строку для создания Интернет соединения в протоколе HTTPS, при этом имя payer.pay будет разрешено через систему DNS в IP адрес сервера платежной системы плательщика, с которым etickets.pay установит Интернет соединение и передаст на сервер платежной системы плательщика платежную инструкцию payer.pay&etickets.pay&$100.

Сервер платежной системы плательщика проверит наличие клиентского счета с идентификатором payer.pay, и если такой счет существует, то, например, для аутентификации плательщика и авторизации платежа сервер etickets.pay передаст управление серверу платежной системы плательщика, а сервер платежной системы предложит плательщику ввести известный плательщику пароль в специальное поле аутентификации плательщика на странице платежной системы плательщика, затем введенный плательщиком пароль будет верифицирован на сервере платежной системы и, если пароль верный, то платеж будет авторизован платежной системой, а управление будет вновь передано сайту etickets.pay для завершения оформления электронного билета. Похожий сценарий, в частности, использует технология 3DSecure™ компании VISA™, с той только разницей, что вместо идентификатора счета плательщика payer.pay покупатель вводит данные пластиковой платежной карты, поэтому для аутентификации платежа заявленным способом может быть использована одна из существующих технологий, что делает внедрение заявленного способа недорогим.

Идентификаторы счетов Торгово-Сервисных Предприятий (ТСП или мерчентов)

Каждый сетевой DNS идентификатор, используемый для идентификации транзакционного счета, должен разрешаться в IP адрес облака. Это накладывает ограничения на политику делегирования имен DNS (или URL или URI), используемых для целей проведения платежей, так как не допускает свободного выбора IP адресов для упомянутых DNS имен, и каждый из IP адресов должен принадлежать облаку. Это одновременно создает предпосылки для использования новых доменов верхнего уровня, доменные имена в которых предназначены исключительно для адресации соединений с целью проведения различных транзакций, включая адресацию платежей. Например, в домене .book можно регистрировать DNS наименования книг, которые одновременно будут служить идентификаторами счета для получения платежей от продажи соответствующей книги. Так же можно использовать домен .арр для целей дистрибуции приложений (applications) и любой другой домен верхнего уровня для целей дистрибуции в нем имен второго уровня как товара, за который платит пользователь (registrant). Поэтому, представляется целесообразным и предпочтительным использовать домен .pay для платежей любого рода.

Как известно, первым и вторым этапом регистрации имен второго уровня в новых доменах верхнего уровня является период Sunrise и Landrush, в течение которого происходит регистрация доменных имен второго уровня для владельцев известных зарегистрированных торговых марок. Как правило, владельцами торговых марок являются Торгово-Сервисные Предприятия (ТСП), что позволяет зарегистрировать DNS идентификаторы всем ТСП, желающим иметь транзакционные счета в облаке, такие как ТСП.ДВУ, где ДВУ является любым Доменом Верхнего Уровня Интернет. Каждое DNS имя второго уровня ТСП.ДВУ может также служить идентификатором счета платежной системы в облаке платежных систем. Каждое ТСП может создавать счета товаров и услуг путем регистрации DNS имен третьего уровня, таких как ТОВАР.ТСП.ДВУ, единственным ограничением, как отмечалось ранее, будет использование IP адресов, принадлежащих облаку платежных систем.

Идентификаторы счетов в платежных системах облака

В соответствии с настоящим изобретением, ТСП, чей DNS идентификатор счета второго уровня (например, amazon.pay) был зарегистрирован в период Sunrise и Landrush, может быть идентификатором счета владельца или даже стать идентификатором отдельной платежной системой, которая может присвоить DNS имена третьего уровня счетам товаров или услуг, которые ТСП продает (например, kindle.amazon.pay), или может присвоить DNS имена третьего уровня счетам пользователей, которых ТСП обслуживает (например, Smith.amazon.pay). В случае идентификации счетов товаров (услуг) счета могут преимущественно служить для получения платежей при продаже товара (услуги). В случае идентификации счетов пользователя счета могут служить как для входящих, так и для исходящих платежей.

Идентификаторы платежных систем облака

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

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

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

Примеры платежных систем ТСП

Примером платежной системы, содержащей счета товаров (услуг), может служить платежная система компании Wal-Mart™ или Спортмастер™ или платежная система производителя товаров Samsung™ или Apple™, где каждому товару может быть присвоен URI, содержащий доменное имя товара уровня N в иерархической части URI, являясь идентификатором счета товара и получения платежей от покупателей этого товара. Для поиска информации о товаре может быт использован тот же URI, компонент [?запрос] которого вместо платежной инструкции может содержать запрос данных о товаре или услуге.

Примеры платежных систем

Примером платежных систем, содержащих счета пользователей, могут служить платежные системы компаний бесплатной электронной почты Gmail или Hotmail, или платежная система банка Citibank, или платежная система онлайновой игры World of War Craft или Angry Birds и так далее.

Другим примером платежных систем могут служить любые домены верхнего уровня (например, .amazon), счетами товаров или пользователей в которых могут быть домены второго уровня, зарегистрированные в этих доменах верхнего уровня (например, kindle.amazon).

Создание DNS идентификаторов счетов для клиентов и товаров платежных систем

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

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

2. Поскольку трудность запоминания DNS идентификатора счета может служить препятствием к внедрению сетевых идентификаторов для существующих клиентов, то в качестве сетевых идентификаторов счета желательно использовать данные, ранее известные клиенту сервиса.

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

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

1. Автоматизация. Возможность автоматизации выбора сетевых идентификаторов для существующих транзакционных счетов.

2. Известность. Сетевые идентификаторы должны содержать информацию, ранее известную владельцу счета и транзакционному серверу.

3. Осмысленность. Сетевой идентификатор счета должен быть мнемоническим (осмысленным) для владельца этого счета.

4. Уникальность. Сетевой идентификатор счета должен быть уникальным во всем множестве транзакционных счетов обслуживаемых транзакционным сервером.

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

Если, например, провайдером онлайновых услуг является Citibank, логином клиента на сервере банка является имя SAM1CITI, а телефоном клиента является номер [phone], записанный в базе данных Ситибанка, то в соответствии с настоящим изобретением автоматически могут быть созданы следующие сетевые идентификаторы счета указанного клиента:

12121234567.citibank.com

и/или

sam1citi.citibank.com.

Другим примером может служить создание DNS идентификаторов транзакционных счетов для провайдеров услуг бесплатной почты hotmail.com, gmail.com, mail.ru или любого другого публичного или корпоративного почтового сервера. Как известно, все почтовые адреса пользователей одного провайдера отличаются лишь логином, расположенным слева от знака @, и логин является уникальным идентификатором пользователя. Заменяя знак @ знаком точка <.>, можно конвертировать e-mail адреса в DNS адреса второго уровня в домене сервис провайдера, так что почтовому адресу [e-mail] будет соответствовать уникальный DNS идентификатор транзакционного счета sam1citi.gmail.com.

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

12121234567.att.com.

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

Приведенные примеры в равной степени относятся к созданию DNS идентификаторов счетов для товаров (услуг) или пользователей в доменах верхнего уровня:

12121234567.att

kindle.amazon

sam1citi.google

sam1citi.citibank

angrybirds.apple

ipad-3-16gb.walmart

и так далее…

Как видно из приведенных примеров, каждый из созданных транзакционных идентификаторов является сетевым DNS идентификатором и каждый соответствует упомянутым требованиям автоматизации, известности, осмысленности и уникальности. Если этим транзакционным идентификаторам поставить в соответствие IP адреса облака, то с их использованием можно будет проводить транзакции в облаке, как раскрыто в заявке Серебренникова и в настоящем изобретении.

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

Создание облака платежных систем

Предположим, что в сети создана и предлагается сетевая услуга процессинга транзакций (платежей) компании АВС и что программное обеспечение, обеспечивающее процессинг транзакций, размещено на сетевом сервере или группировке сетевых серверов компании АВС (далее сервер или группировку серверов АВС будем называть «облаком»), которые доступны потенциальным клиентам и пользователям сети Интернет (или другой сети) с использованием одного или более IP адресов (или сетевых адресов другой сети), далее именуемых «IP индекс облака».

Проиллюстрируем сценарий использования облака для создания платежных систем, например для социальной сети Facebook, для оператора сотовой связи AT&T и для сервера бесплатной электронной почты gmail.com, а также проиллюстрируем проведение платежной операции между счетами созданных в облаке платежных систем.

Этап 1. Создание DNS идентификаторов транзакционных клиентских счетов.

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

Для создания DNS идентификаторов транзакционных счетов клиентов Facebook.com и gmail.com, адреса электронной почты [e-mail] и [e-mail] могут быть преобразованы в DNS идентификаторы путем замены знака @ на знак точка, таким образом идентификаторами транзакционных счетов будут соответственно client_ID.facebook.com и client_ID.gmail.com.

Для создания идентификаторов транзакционного счета для клиентов AT&T может быть использованы или логины входа пользователей на сервер AT&T, или номера телефонов клиентов, соответственно DNS идентификатором счета клиента, владеющего номером телефона [phone] и логином samlciti в AT&T, может быть, например, идентификатор 12121234567.att.com или идентификатор sam1citi.att.com.

Этап 2. Присвоение IP адресов платежным системам Facebook, Gmail и AT&T.

Каждой из вновь создаваемых платежных систем Facebook, gmail.com и AT&T передается в аренду/использование один или более IP адресов из "IP индекса облака", далее эти один или более IP адресов платежной системы будем называть соответственно "IP индекс Facebook", "IP индекс gmail" и "IP индекс AT&T" для соответствующих платежных систем. При этом все IP адреса принадлежат «IP индексу облака» и обеспечивают соединение с облаком.

Этап 3. Разграничение процессинга различных платежных систем.

Сегменты облака, адресуемые с помощью "IP индекса Facebook", "IP индекса gmail" и "IP индекса AT&T", логически или физически разделяются для целей разделения процессинга платежных систем facebook, gmail и AT&T соответственно. Разграничение «IP индекса облака» на индексы и области процессинга, принадлежащие разным платежным системам, позволяет разграничить учет и применять различную политику учета в отношении транзакций, проводимых клиентами каждой из платежных систем, а также увеличить безопасность работы и устойчивость систем к сбоям. В частности, компании Facebook, Google и AT&T могут независимо друг от друга устанавливать для своих клиентов различные комиссии по платежам, самостоятельно управлять процессами аутентификации клиентов, верификации и авторизации платежей, ограничивать или расширять полномочия клиентов, предлагать те или иные дополнительные условия использования счетов.

Этап 4. Присвоение IP адресов DNS идентификаторам транзакционных счетов.

Для того чтобы DNS идентификатор счета каждого пользователя платежных систем стал действительным DNS адресом сети Интернет, ему в соответствие должен быть поставлен IP адрес. Поэтому каждому DNS идентификатору счета пользователя Facebook ставим в соответствие IP адрес из "IP индекса Facebook", а соответственно DNS идентификатору счета каждого пользователя gmail ставим в соответствие IP адрес из "IP индекса gmail", а для каждого пользователя AT&T ставим IP адрес из "IP индекса AT&T". Благодаря этому разрешение сетевых идентификаторов счетов пользователей Facebook через систему DNS Интернет будет возвращать IP адреса из "IP индекса Facebook", аналогично для Gmail и для AT&T будет возвращать соответственно адреса из "IP индекса gmail" и из "IP индекса AT&T", что позволит устанавливать соединения соответственно с сегментом платежной системы Facebook, или Gmail или AT&T, соответственно.

Этап 5. Проведение транзакции между счетами клиентов в созданных платежных системах.

Для проведения платежа на сумму $100 со счета 12121234567.att.com на счет cliant_ID.gmail.com, например, может быть использована, например, строка с адресом соединения и платежной инструкцией, расположенной после адреса соединения и знака «?»:

12121234567.att.com?12121234567.att.com&client_ID.gmail.com&$100.

В данном примере 1) адрес соединения (DNS имя) 12121234567.att.com будет разрешен в IP адрес из "IP индекса AT&T"; 2) будет установлено Интернет соединение (например, HTTPS) с платежной системой AT&T в облаке; 3) в платежную систему AT&T будет передана платежная инструкция 12121234567.att.com&client_ID.gmail.com&$100.

После шага 3) платежная система должна будет обработать платежную инструкцию (HTTPS запрос) и ответить на него вызывающему ресурсу (HTTPS ответ), что позволит установить обмен между вызывающим ресурсом и сервером платежной системы и провести платеж используя, например, Сценарий покупки электронного билета, описанный выше. Вызывающим ресурсом в приведенном примере может быть любое лицо, включая стороны проведения платежа и сервера соответствующих платежных систем, а соединение Интернет, установленное между вызывающим ресурсом и платежной системой AT&T, может быть использовано для организации процессов обмена между вызывающим ресурсом и сервером платежной системы для целей аутентификации плательщика и/или получателя платежа, верификации данных и авторизации платежа известными способами.

Дистрибуция DNS идентификаторов финансовых счетов облака, зарегистрированных в избранном домене верхнего уровня

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

Предположим, что домен верхнего уровня .PAY используется для создания DNS идентификаторов, предназначенных для использования в качестве идентификаторов транзакционных (финансовых) счетов.

Настоящее изобретение предлагает способ дистрибуции любыми третьими сторонами DNS идентификаторов (далее для примера будем говорить о доменах второго уровня, зарегистрированных в домене верхнего уровня .PAY), которые используются в качестве идентификаторов финансовых счетов. Предположим, пользователь Интернет посетил web сайт дистрибутора доменов второго уровня в РДВУ.PAY. Упомянутый дистрибутор предлагает пользователю зарегистрировать имя в домене верхнего уровня .PAY и использовать последнее в качестве идентификатора финансового счета для оплаты покупок в Интернет и в физической розничной сети. Для дистрибутора создается Сегмент Системы проведения транзакций, а все распространенные им DNS имена в домене .PAY используются в качестве идентификаторов финансовых счетов соответствующих пользователей произвольного домена верхнего уровня в его Сегменте Системы проведения транзакций, что позволяет упомянутому дистрибутору получать комиссионное вознаграждение от проведения его пользователями транзакций с использованием в качестве идентификаторов финансового счета DNS идентификаторов, зарегистрированных ими в домене верхнего уровня. PAY, зарегистрированных с помощью упомянутого дистрибутора.

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

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

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

Защита данных, безопасность адресации и использования сетевых соединений

Вопросы безопасности при использовании изобретения могут решаться различными известными способами и способами, раскрытыми в настоящем изобретении.

Криптографическая защита данных счета в облаке

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

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

Настоящее изобретение расширяет использование способа заявки Серебренникова для платежных систем облака. Для этого данные карты шифруются открытым ключом одной из платежных систем облака и записываются вместе с IP адресом из «IP индекса» этой платежной системы или записываются вместе с СИСС. Данные могут записываться в память, доступную владельцу карты, и оставаться, таким образом, в распоряжении самого владельца карты и быть неизвестны платежной системе, а предъявляться платежной системе только в момент проведения платежа. Таким образом, ЗЗС может создаваться любым третьим лицом, имеющим соответствующие криптографические средства, поскольку открытый ключ платежной системы доступен публике как часть цифрового сертификата платежной системы. Это позволяет избежать хранения данных клиента в единой базе данных, что позволяет избежать рисков неавторизованного доступа к данным ЗЗС всех клиентов одновременно в случае, если проникновения мошенников в базу данных и одновременно не создает помех и дополнительных барьеров при проведении транзакции. При хранении ЗЗС различных клиентов различных платежных систем облака для расшифровывания конкретной ЗЗС необходимо знать, открытым ключом какой конкретно платежной системы облака была зашифрована ЗЗС, что также трудно сделать, если использовать случайные последовательности IP адресов для формирования «IP индекса» конкретной платежной системы, как это описано ниже в разделе «Использование случайных последовательностей».

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

Аутентификация, верификация и авторизация

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

Онлайновый доступ к услугам проведения платежей

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

Устойчивость систем адресации

В случае Интернет особой заботой таких организаций как ICANN является избегание рисков потери стабильности и целостности системы DNS. Важной особенностью изобретения является то, что процесс разрешения DNS идентификаторов счетов в IP адреса серверов с последующим установлением Интернет соединения отделен от процесса проведения транзакций таким же образом, как сегодня процесс разрешения DNS имени, например, Ситибанка (Citibank.com) отделен от предоставляемых Ситибанком услуг проведения платежей в режиме онлайн с использованием онлайн банкинга Ситибанка. Поэтому использование изобретения не несет дополнительных рисков для системы DNS адресации Интернет.

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

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

Использование случайных последовательностей

Создание "IP индекса Facebook", "IP индекса gmail" и "IP индекса AT&T" может быть организовано случайным способом, при котором множество IP адресов каждого из индексов представляют собой случайную последовательность адресов. Этого можно достигнуть путем случайного выбора IP адреса из индекса последовательных IP адресов для его включения в индекс IP адресов конкретной платежной системы. Такой способ назначения IP адресов не позволит определить принадлежность конкретного IP адреса индексу IP адресов конкретной платежной системы. Случайная последовательность IP адресов индекса также не позволит определить число клиентов конкретной платежной системы с использованием публичных DNS сервисов. При использовании криптографических ключей платежной системы случайное множество IP адресов индекса IP адресов платежной системы не позволит определить злоумышленникам, криптографические ключи какой платежной системы используются при соединении с определенным IP адресом облака платежных систем.

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

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

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

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

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

4. Способ по п.1, отличающийся тем, что упомянутые сетевые идентификаторы являются DNS именами или идентификаторами Uniform Resource Identifier (URI), а сетевые адреса являются IP адресами.

5. Способ по п.4, отличающийся тем, что регистратору DNS имен уровня N предоставляют Сегмент системы проведения платежей, а зарегистрированные регистратором упомянутые DNS имена уровня N используют в качестве упомянутых СИСС для идентификации финансовых счетов в упомянутом Сегменте Базы, каждому СИСС ставят в соответствие, по меньшей мере, один сетевой адрес соответствующего Сегмента Адресов, а СИСС и поставленный ему в соответствие хотя бы один упомянутый адрес Сегмента Адресов записывают в базу данных системы адресации сетевых соединений.

6. Способ по п.5, отличающийся тем, что в избранном домене верхнего уровня Интернет создают упомянутую Систему проведения платежей, а DNS идентификаторы второго уровня, зарегистрированные в упомянутом избранном домене верхнего уровня Интернет, используют в качестве упомянутых СИСС, упомянутым регистратором является другой домен верхнего уровня, а упомянутый Сегмент системы проведения платежей используют в качестве платежной системы дистрибутора.

7. Способ по п.6, отличающийся тем, что упомянутым избранным доменом верхнего уровня является домен .PAY.

8. Способ по п.5, отличающийся тем, что для упомянутого регистратора создают закрытый и открытый криптографические ключи асимметричного шифрования, а упомянутым пользователям при регистрации упомянутых СИСС предлагают ввести данные кредитной карты, которые шифруют с использованием открытого криптографического ключа дистрибутора и получают ЗЗКК, затем устанавливают связь упомянутой ЗЗКК с упомянутым СИСС и записывают ЗЗКК с сопоставленным ему СИСС в Сегмент базы упомянутого регистратора, а при оплате соответствующим пользователем товара или услуги в сети Интернет или в розничной сети физического мира вводят упомянутый СИСС и используют СИСС для создания и передачи упомянутой платежной инструкции в Сегмент Базы регистратора, а для проведения упомянутого платежа в Сегменте базы осуществляют поиск счета, идентификатор которого совпадает с упомянутым СИСС, и извлекают ЗЗКК, поставленный в соответствие упомянутому СИСС в Сегменте Базы, ЗЗКК расшифровывают с использованием закрытого ключа регистратора и используют расшифрованные данные для осуществления платежа.

9. Способ по п.6, отличающийся тем, что связь между ЗЗКК и СИСС не устанавливают и ЗЗКК в базу данных Сегмента базы не записывают, а для проведения платежа ЗЗКК размещают в инструкции проведения платежа.

10. Способ по п.1, отличающийся тем, что упомянутые один или более адресов Сегмента Адресов выбирают случайным образом из множества адресов системы проведения транзакций.

11. Способ по п.1, отличающийся тем, что в инструкции проведения транзакции размещают значение зашифрованной записи счета.

12. Способ по п.11, отличающийся тем, что в инструкции проведения транзакции не размещают идентификатор СИСС, а транзакцию проводят в отношении расшифрованного идентификатора транзакционного счета.

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

14. Способ по п.11, отличающийся тем, что упомянутую запись счета шифруют с использованием открытого ключа Сегмента.

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

16. Способ по п.1, отличающийся тем, что создают множество СИСС, каждый из которых является DNS идентификатором, причем для создания соответствующего DNS идентификатора в качестве правой части идентификатора или, по меньшей мере, в качестве изменяющейся части правой части идентификатора используют DNS имя сервера сервис провайдера, а в качестве левой части DNS идентификатора используют логин пользователя для доступа к серверу сервис провайдера или номер телефона пользователя, а упомянутую левую часть присоединяют к правой, разделяя упомянутые части знаком точка <.>.

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

18. Способ по п.1, отличающийся тем, что создают множество СИСС, каждый из которых является DNS идентификатором, причем для создания СИСС используют адрес электронной почты, в котором, по меньшей мере, знак <@> заменяют знаком точка <.>

19. Способ по п.1, отличающийся тем, что создают множество СИСС, каждый из которых является DNS идентификатором, причем для создания СИСС используют номер телефона пользователя и DNS имя оператора телефонной связи, для чего, по меньшей мере, номер телефона присоединяют слева к DNS имени оператора телефонной связи, разделяя упомянутый, по меньшей мере, номер телефона и упомянутое DNS имя знаком точка <.>.