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

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

Реферат

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

Настоящее изобретение относится к области компьютерной техники, способам поиска, извлечения и обработки информации и идентификации сетевых ресурсов, электронной коммерции и дистрибуции физических и виртуальных товаров и услуг, в частности дистрибуции системы доменных имен (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, а телефоном клиента является номер +1(212)1234567, записанный в базе данных Ситибанка, то в соответствии с настоящим изобретением автоматически могут быть созданы следующие сетевые идентификаторы счета указанного клиента:

12121234567.citibank.com

и/или

sam1citi.citibank.com.

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

Для создания идентификаторов транзакционного счета для клиентов AT&T может быть использованы или логины входа пользователей на сервер AT&T, или номера телефонов клиентов, соответственно DNS идентификатором счета клиента, владеющего номером телефона +1-212-1234567 и логином 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, идентификатор, который используется в качестве идентификатора финансового счета дистрибутора в Системе проведения транзакций, и на этот счет может зачисляться комиссия от операций, прове