Устройства, способы и системы токенизации конфиденциальности платежей

Изобретение относится к электронным платежным системам с использованием мобильных устройств. Описаны устройства, способы и системы токенизации конфиденциальности платежей (РРТ). Технический результат заключается в повышении защищенности платежей. Предложено преобразовывать поручения токенизированной оплаты покупок в движение средств для оплаты покупок между счетами множества эмитентов. В одном из вариантов осуществления РРТ получает от торговца запрос арбитража токенов, содержащий однозначную, не зависящую от источника, универсально разрешимую информацию о платежном токене для обработки заказа на покупку, поступившего от пользователя. РРТ запрашивает в базе данных токенов информацию об эмитенте с использованием информации о платежном токене и получает информацию об эмитенте. На основании информации о платежном токене РРТ также определяет, что у пользователя следует запросить опции платежа, и передает запрос опций платежа пользовательскому мобильному устройству. После получения ответа от мобильного устройства РРТ генерирует запрос авторизации покупки на основании опций платежа и предварительно заданных установочных параметров для эмитентов, с которым следует связаться с целью обработки заказа на покупку, и передает эмитенту генерированный запрос авторизации. 12 н. и 108 з.п. ф-лы, 44 ил.

 

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

Притязания на приоритет

Заявитель настоящим притязает на приоритет предварительной патентной заявки США 61/494402 под названием "PAYMENT PRIVACY TOKENIZATION APPARATUSES, METHODS AND SYSTEMS", поданной 7 июня 2011 г. (досье № Р-42304PRV|20270-167PV), на основании статьи 119 раздела 35 Свода законов США. Все содержание упомянутой заявки в прямой форме в порядке ссылки включено в настоящую заявку.

Область техники, к которой относится изобретение

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

Предпосылки создания изобретения

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

Краткое описание чертежей

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

на фиг.1А-Б показаны блок-схемы, иллюстрирующие примеры особенностей токенизации платежей в некоторых вариантах осуществления РРТ,

на фиг.2А-Б схематически показаны интерфейсы приложений пользователя, иллюстрирующие примеры возможностей интерфейсов приложения для управления токенизированными платежами по транзакциям покупки в некоторых вариантах осуществления РРТ,

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

на фиг.4 показана схема потоков данных, иллюстрирующая один из примеров процедуры регистрации в программе токенизированной оплаты покупок в некоторых вариантах осуществления РРТ,

на фиг.5 показана логическая блок-схема, иллюстрирующая примеры особенностей регистрации в программе токенизированной оплаты покупок в некоторых вариантах осуществления РРТ, например, компонент 500 регистрации в программе токенизированной оплаты покупок (ТРЕ),

на фиг.6А-Д показаны схемы потоков данных, иллюстрирующие один из примеров процедуры выполнения токенизированной транзакции покупки в некоторых вариантах осуществления РРТ,

на фиг.7А-Е показаны логические блок-схемы, иллюстрирующие примеры особенностей выполнения токенизированной транзакции покупки в некоторых вариантах осуществления РРТ, например, компонент 700 выполнения токенизированной транзакции покупки (tPTE),

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

на фиг.9А-Ж схематически показаны интерфейсы пользователя, иллюстрирующие примеры возможностей приложений для виртуального бумажника в режиме совершения покупок в некоторых вариантах осуществления РРТ,

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

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

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

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

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

на фиг.15 показана блок-схема, иллюстрирующая варианты осуществления контроллера РРТ.

Первая цифра, используемая в каждой позиции на чертежах, соответствует номеру фигуры, на которой эта позиция представлена и/или подробно показана. Так, позиция 101 подробно показана и/или представлена на фиг.1. Позиция 201 представлена на фиг.2 и т.д.

Подробное описание

Токенизация конфиденциальности платежей (РРТ)

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

На фиг.1А-Б показаны блок-схемы, иллюстрирующие примеры особенностей токенизации платежей в некоторых вариантах осуществления РРТ. Как показано на фиг.1А, чтобы определять, следует ли обрабатывать транзакцию покупки, в некоторых вариантах осуществления может требоваться сетевая платежная система, состоящая из серверов, размещающихся в географически отдаленных местоположениях (например, локальный сервер 114а платежной сети и удаленный сервер 114b платежной сети). Например, пользователь 110а может находиться в географически отдаленном местоположении и может осуществлять доступ к веб-сайту, например, 113, торговца, например, 112, находящего в другом географическом местоположении. В некоторых вариантах осуществления пользователь 110а может использовать клиента 111а, чтобы передать данные покупки (например, 115а) торговому серверу 112. Например, клиент 111а может предоставлять платежный токен (например, посредством объекта Playspan UltimatePay Lightbox, выполняемого в просмотровой среде клиента 111а) с целью сохранения анонимности пользователя. Например, платежный токен может представлять собой однонаправленную криптографическую хеш-функцию MD5 финансовой информации о платеже и может не содержать какой-либо информации, идентифицирующей личность пользователя. Хотя токен может не содержать идентифицирующей информации, в его основе может лежать идентифицирующая информация (например, уникальный идентификатор), что выгодно, поскольку позволяет заполнять таблицу данных повышенной секретности такими хеш-функциями с информацией о коде страны пользователя, при этом получаемой таблице сохраняется анонимность пользователя, поскольку хеш-функция и код страны не могут использоваться для установления личности пользователя, тем не менее, затем такая таблица может использоваться для применения правил конфиденциальности в зависимости от кода страны, чтобы тем маршрутизировать токен и обработку платежа в платежные серверы в соответствующей стране и предотвращать огласку личной информации пользователя в ненадлежащих юрисдикциях. В некоторых вариантах осуществления пользователь 110а может пожелать использовать посредством платежного токена платежный механизм (например, кредитную карту, дебетовую карту, предоплаченную карту, счет с хранимой суммой и т.д.), который в целом предназначен для использования в географически отдаленном местоположении. Так, согласно некоторым сценариям пользователь из географически отдаленного местоположения может пожелать использовать платежный механизм, рассчитанный на использование в географически отдаленном местоположении, чтобы оплатить покупку, совершенную у торговца, находящегося в локальном географическом местоположении, без разглашения торговцу или серверу платежной системы, находящейся в локальном географическом местоположении, какой-либо информации, идентифицирующей личность пользователя.

Например, этому сценарию может быть противопоставлен случай, когда пользователь 111b использует клиента 110b и находится в локальном географическом местоположении. Например, пользователь 110b может использовать клиента 111b для предоставления данных покупки тому же веб-сайту 113 торговца 112, находящегося в локальном географическом местоположении. В некоторых вариантах осуществления торговый сервер 112 может предоставлять поступающие от обоих пользователей запросы на совершение покупки тому же локальному серверу платежной системы, например, 114а. Так, в некоторых вариантах осуществления локальному серверу 114а платежной сети может требоваться определять, следует ли обрабатывать платеж по входящему запросу авторизации карты на месте или пересылать запрос удаленному серверу платежной сети, например, 114b. В некоторых вариантах осуществления локальному серверу 114а платежной сети может требоваться определять это без использования какой-либо информации, идентифицирующей личность пользователя. В некоторых вариантах осуществления локальный сервер 114а платежной сети может использовать предоставленный клиентом пользователя платежный токен в качестве элемент поиска для запроса базы данных. Например, локальный сервер платежной сети может использовать сценарий гипертекстовой предобработки (РНР), содержащий команды на языке структурированных запросов (SQL) (например, такие как в приведенных далее примерах), чтобы запрашивать базу данных с использованием сохраняющего анонимность обеспечивающего секретность платежного токена. В ответ база данных может предоставлять переменную величину, указывающую, следует ли обрабатывать запрос локально или дистанционно. В некоторых вариантах осуществления база данных может предоставлять IP-адрес удаленного сервера платежной сети (такого как, например, удаленный сервер 114b платежной сети), которому должен переслать запрос локальный сервер платежной сети. Так, в некоторых вариантах осуществления запрос обработки платежного токена пользователя может передаваться для обработки (например, 119) соответствующему серверу платежной сети в зависимости от местоположения пользователя, типа платежного токена, используемого пользователем, счета(-ов), к которому привязан обеспечивающий секретность, сохраняющий анонимность платежный токен, и/или т.п. По существу, РРТ позволяет маршрутизировать запросы серверам платежной сети, являющимся локальными по отношению к таким запросам. Преимуществом этого может являться повышение безопасности и конфиденциальности за счет того идентифицирующая информация пользователя широко рассылается без необходимости. Преимуществом этого также может являться потенциальное выравнивание нагрузки, связанной с обработкой запросов платежей. В некоторых вариантах осуществления платежному серверу торговца может быть известно о другом региональном платежном сервере, и в нем может содержаться набор правил, регулирующих место происхождения покупки, при этом некоторые юрисдикции могут быть отмечены как требующие поддержание различных уровней конфиденциальности. В таких вариантах осуществления, например, когда платежное требование происходит из страны (например, Европейского Союза), в которой требуется поддержание конфиденциальности на самом высоком уровне, РРТ может передавать токены и маршрутизировать транзакцию покупки в соответствующее местоположение относительно места происхождения покупки. Тем не менее, в качестве альтернативы, когда в месте происхождения покупки отсутствуют строги требования конфиденциальности, запрос может обрабатывать наиболее легкодоступный сервер платежной сети (например, текущий сервер, наименее загруженный альтернативный сервер и т.д.).

Как показано на фиг.1Б, в некоторых вариантах осуществления пользователь может пожелать приобрести товар, услугу и/или иное предложение (далее - продукт) у торговца, например, 106. Пользователь может пожелать использовать карту (например, дебетовую, кредитную, предварительно оплаченную и т.д.), например, 101а, наличные (или их эквивалент), например, 102а, ценные бумаги, например, 103а, виртуальную валюту, бонусы, баллы, мили и т.д., например, 104а и/или другие опции платежа. Тем не менее, пользователь может пожелать сохранить анонимность, чтобы предотвратить получение торговцем персональной информации пользователя. В качестве другого примера, пользователь может опасаться злоупотребления данными своей карты в целях мошеннических транзакций. В некоторых вариантах осуществления пользователь может быть способен использовать псевдонимы или токены вместо платежной информации. Например, пользователь может быть способен передавать токен, например, 101b, 102b, 103b, 104b торговцу вместо полных данных о карте, наличных или счете. На фиг.9А-14Б проиллюстрированы различные неограничивающие выгодные особенности использования пользователем для виртуального бумажника, чтобы инициировать транзакцию покупки, включая возможность "маскирования" транзакции с использованием платежного токена вместо платежной информации. С целью обработки транзакции с торговцем может взаимодействовать безопасный арбитратор токенов. Например, после приема платежного токена от пользователя торговец может передавать его арбитратору транзакций. Безопасный арбитратор транзакций может быть способен проводить синтаксический анализ поступающего токена и устанавливать личность пользователя для этого токена токен. Арбитратор транзакций также может определять финансовую платежную информацию для использования при обработке транзакции. В некоторых вариантах осуществления арбитратор транзакций также может иметь только другой токен, хранящийся в качестве платежной информации. В таких вариантах осуществления эмитент токена может являться единственным лицом помимо пользователя, которому известна действительная персональная и/или финансовая информация пользователя. Так, в некоторых вариантах осуществления токен может представлять собой сочетание с другим токеном. Например, токен арбитратора транзакций, может указывать на другой токен арбитратора транзакций и/или эмитента. Так, в некоторых вариантах осуществления путем соответствующей структуризации платежных токенов может формироваться множество уровней защиты персональной и финансовой информации. В некоторых вариантах осуществления токен может представлять собой комбинацию из других платежных токенов. Например, платежный токен 105 может указывать, что транзакция может быть обработана путем присвоения определенной доли в процентах (например, 55%) суммы транзакция токену 101b (например, в конечном итоге привязанному к данным 101а кредитной карты) и другой доли в процентах (например, 45%) другому токену 102b (например, в конечном итоге привязанному к счету 102а хранящихся средств). В некоторых вариантах осуществления доли в процентах могут определяться в реальном или почти реальном времени. Например, арбитраторы токенов могут взаимодействовать с эмитентами, у которых счета пользователей привязаны к платежным токенам, чтобы определять, со счетов каких пользователей должны списываться средства, и какие суммы должны списываться с каждого счета (например, в соответствии с заранее заданным алгоритмом). В качестве другого примера, доли в процентах могут определяться только при обработке транзакция, например, токенов 103b, 104b, например, путем предложения пользователя указать опции платежа при обработке транзакция покупки.

В некоторых вариантах осуществления могут обеспечиваться дополнительные уровни защиты путем использования методов аутентификации. В качестве примера пользователю может быть предложено представить имя пользователя и пароль, чтобы активировать платежный токен. В качестве другого примера, пользователю может быть предложено представить цифровой сертификат, удостоверяющий личность, до использования платежного токена при транзакции покупки. В качестве другого примера, может использоваться считыватель отпечатков пальцев. Например, клиентским устройством пользователя может являться устройство, которое используется исключительно пользователем, такое как смартфон, планшетный компьютер, портативный компьютер и/или т.п. В некоторых вариантах осуществления может быть предусмотрена заказная аппаратная микросхема аутентификации, например, 103, которая поддерживает связь с клиентом. В различных вариантах осуществления микросхема может быть встроена в клиента, поставляться предварительно установленной в клиенте, подключена к клиенту в качестве периферийного устройства и/или т.п. В некоторых вариантах осуществления пользователь может выполнять процедуру аутентификации с использованием клиента и карты пользователя, привязанной к платежному токену пользователя. Например, микросхема аутентификации может быть сконфигурирован на распознавание физической карты платежного токена пользователя при нахождении карты вблизи микросхемы аутентификации. Например, микросхема аутентификации и карта могут обмениваться сигналами с использованием Bluetooth™, Wi-Fi™, RFID-меток, возможностей установления сотовой связи (например, 3G, 4G) и/или т.п. Так, в некоторых вариантах осуществления пользователю при совершении покупки с использованием платежного токена пользователю может предлагаться поднести физическую карту платежного токена к микросхеме аутентификации, поддерживающей связь с клиентом, после чего пользователь может сделать заказ на покупку с использованием токена. Таким образом, система обеспечивает защиту аутентичности, чтобы не позволить тем, кому может быть известен платежный токен пользователя, использовать его для мошеннической транзакции.

На фиг.2А-Б схематически показаны интерфейсы приложений пользователя, иллюстрирующие примеры возможностей интерфейсов приложения для управления токенизированными платежами по транзакциям покупки в некоторых вариантах осуществления РРТ. В некоторых вариантах осуществления приложение, выполняемое в устройстве пользователя, может содержать интерфейс приложения, обеспечивающий различные возможности для пользователя. В некоторых вариантах осуществления приложение может содержать указание местоположения пользователя, например, 201 (например, название магазина торговца, географическое местоположение, проход между полками в магазине торговца и т.д.). Приложение может содержать указание суммы, причитающейся за продукт, например, 202. В некоторых вариантах осуществления приложение может предоставлять пользователю различные опции оплаты приобретенного продукта(-ов). Например, приложение может использовать координаты GPS, чтобы определять магазин торговца, в котором находится пользователь, и адресовать пользователя на веб-сайт торговца. В некоторых вариантах осуществления РРТ может предоставлять API участвующим торговцам, чтобы непосредственно облегчать обработку транзакций. В некоторых вариантах осуществления может быть разработано фирменное приложение РРТ торговца с функциональными возможностями РРТ, которое может непосредственно подключать пользователя к системе обработки транзакций торговца. Например, пользователь может выбирать одну из нескольких карт (например, кредитных карт, дебетовых карт, предоплаченных карт и т.д.) различных эмитентов, например, 203. В некоторых вариантах осуществления приложение может предоставлять пользователю возможность оплаты суммы покупки с использованием средств на банковском счете пользователя, например, чековом, сберегательном, депозитном счете денежного рынка, текущем счете и т.д., например, 204. В некоторых вариантах осуществления пользователь может по умолчанию устанавливать, какая карта, банковский счет и т.д. должна использоваться для транзакции покупки посредством приложения. В некоторых вариантах осуществления такие установки по умолчанию могут позволять пользователю инициировать транзакцию покупки путем одного клика, нажатия, проведения карты через считывающее устройство и/или иного входного воздействия, например, 205. Когда в некоторых вариантах осуществления пользователь использует такую возможность, приложение может использовать пользовательские установки по умолчанию, чтобы инициировать транзакцию покупки. В некоторых вариантах осуществления приложение может позволять пользователю использовать другие счета (например, Google™ Checkout, Paypal™ и т.д.) для оплаты покупки, например, 206. В некоторых вариантах осуществления приложение может позволять пользователю использовать бонусы, баллы, начисляемые авиакомпаниями мили, баллы, начисляемые гостиницами, электронные купоны, печатные купоны (например, путем сбора печатных купонов, аналогичных идентификатору продукта) и т.д. для оплаты покупки, например, 207-208. В некоторых вариантах осуществления приложение может предоставлять возможность использовать прямую авторизацию до инициации транзакции покупки, например, 209. В некоторых вариантах осуществления приложение может использовать индикатор индикатор состояния, указывающий состояние транзакции после того, как пользователь решил инициировать транзакцию покупки, например, 210. В некоторых вариантах осуществления приложение может предоставлять пользователю информацию о предыдущих покупках, например, 211. В некоторых вариантах осуществления приложение может предоставлять пользователю возможность совместно использовать информацию о покупке (например, посредством электронной почты, SMS, сообщений в Facebook®, Twitter™ и т.д.) с другими пользователями, например, 212. В некоторых вариантах осуществления приложение может предоставлять пользователю возможность отображать идентифицирующую продукт информацию, собранную клиентским устройством (например, чтобы показать сотруднику отдела по работе с покупателями на выходе из магазина), например, 214. В некоторых вариантах осуществления пользователь, приложение, устройство и РРТ могут совершить ошибку в процессе обработки. В таких случаях пользователь может иметь возможность обмениваться информацией в реальном времени с сотрудником отдела по работе с покупателями (например, VerifyChat 213), чтобы устранить затруднения в ходе процедуры выполнения транзакции покупки.

В некоторых вариантах осуществления пользователь может выбрать совершение транзакция с использованием одноразового токена, например, сохраняющего анонимность кредитной карты номера, например, 205b. Например, РРТ может использовать токенизированый и сохраняющий анонимность набор данных карты (например, "AnonCard1", "AnonCard2"). В качестве другого примера, РРТ может генерировать, например, в реальном времени одноразовый анонимный набор данных карты с целью безопасного завершения транзакции покупки (например, "Anon It 1X"). В таких вариантах осуществления приложение может автоматически задавать установку параметров профиля пользователя таким образом, чтобы персональная идентифицирующая информация пользователя не предоставлялась торговцу и/или другим лицам. Например, приложение может автоматически передавать только токен или псевдонимы вместо платежной информации. Платежная система может обрабатывать токен с целью получения связанной с ним платежной информации для обработки транзакции покупки. В некоторых вариантах осуществления пользователю может предлагаться ввести имя пользователя и пароль, чтобы активировать функции сохранения анонимности.

В некоторых вариантах осуществления пользователь может быть способен управлять атрибутами каждого токен, связанного с пользователем, посредством веб-интерфейса, например, 220. Например, пользователь может быть способен входить в систему веб-интерфейса, например, 221, и визуализировать платежные токены, связанные с пользователем, например, 223. Пользователю также могут предоставляться элементы элементы интерфейса пользователя для генерирования новых токенов. Например, интерфейс пользователя может предоставлять элементы для создания нового токена, например, 224. Например, интерфейс пользователя может позволять пользователю выбирать финансовые данные 225, включая без ограничения источник финансирования для получения токена, тип счета для токена, начальное значение токена (например, для предварительного финансирования и/или предварительной авторизации), опцию снижения стоимости (например, для облегчения регулируемого по времени контроля расходов для пользователя), адрес для выставления счета, адрес доставки, контактные параметры, протокол безопасной пересылки данных, администратор токенов, опцию сохранения анонимности пользователя (в целях защиты) и/или т.п. В некоторых вариантах осуществления веб-интерфейс может позволять пользователю выбирать персональные данные 226, включая без ограничения владельцев токенов, периодичность контактов (например, для предложения токенов), предпочтения для предложения токенов, контроль со стороны родителей, активированные устройства и/или т.п. В некоторых вариантах осуществления веб-интерфейс может позволять пользователю указывать даты 227 активации и дату 228 истечения срока действия токенов.

На фиг.3А-В схематически показаны интерфейсы приложений пользователя, иллюстрирующие примеры возможностей мобильного приложения для токенизации платежей с целью защиты пользовательских данных и предотвращения мошенничества в некоторых вариантах осуществления РРТ. В некоторых вариантах осуществления приложение, выполняемое в устройстве пользователя, может предоставлять возможность "VerifyChat" предотвращения мошенничества (например, путем активации элемента UI 213 на фиг.2). Например, РРТ может обнаруживать необычную и/или подозрительную транзакцию. РРТ может использовать возможность VerifyChat для связи с пользователем и проверки подлинности инициатора транзакции покупки. В различных вариантах осуществления РРТ может передавать сообщение электронной почты, текстовые (SMS) сообщения, сообщения Facebook®, Twitter™, текстовый диалог в реальном времени, речевой диалог в реальном времени, видеодиалог в реальном времени (например, Apple FaceTime) и/или т.п. для связи с пользователем. Например, РРТ может инициировать видеозапрос пользователя, например, 301. Например, от пользователя может потребоваться представиться посредством видеодиалога в реальном времени, например, 302. В некоторых вариантах осуществления сотрудник отдела по работе с покупателями, например, 304b, может вручную устанавливать подлинность пользователя с использованием видеоизображения пользователя. В некоторых вариантах осуществления РРТ может использовать распознавание лица, биометрическую и/или подобную идентификацию (например, с использованием методов классификации образов), чтобы устанавливать личность пользователя, например, 304а. В некоторых вариантах осуществления приложение может предоставлять контрольную отметку (например, перекрестие, целевой прямоугольник и т.д.), например, 303, чтобы пользователь мог использовать видео с целью облегчения автоматического распознания пользователя для РРТ. В некоторых вариантах осуществления пользователь мог не инициировать транзакцию, например, если транзакция является мошеннической. В таких вариантах осуществления пользователь может аннулировать запрос, например, 305. Затем РРТ может аннулировать транзакцию и/или инициировать процедуру расследования мошенничества от имени пользователя.

В некоторых вариантах осуществления РРТ может использовать процедуру тестового запроса с целью проверки подлинности пользователя, например, 306. Например, РРТ поддерживать связь с пользователем посредством текстового диалога в реальном времени, SMS-сообщений, электронной почты, сообщений Facebook®, Twitter™ и/или т.п. РРТ может задавать вопрос пользователю, например, 308. Приложение может обеспечивать пользователя элементом(-ами) ввода (например, виртуальной клавиатурой 309) для ответа на вопрос, заданный РРТ. В некоторых вариантах осуществления вопрос может произвольным образом автоматически выбираться РРТ; в некоторых вариантах осуществления сотрудник отдела по работе с покупателями может вручную связываться с пользователем. В некоторых вариантах осуществления пользователь мог не инициировать транзакцию, например, если транзакция является мошеннической. В таких вариантах осуществления, пользователь может аннулировать, например, на шагах 307, 310 текстовой запрос. Затем РРТ может аннулировать транзакцию и/или инициировать процедуру расследования мошенничества от имени пользователя.

В некоторых вариантах осуществления приложение может быть сконфигурировано на распознавание идентификаторов продукта (например, штриховых кодов, QR-кодов (от английского - Quick Response Code, матричный или двухмерный код) и т.д.). Например, для предотвращения мошенничества приложение может предлагать пользователю использовать пользовательское устройство для получения копии экрана с изображением приобретаемых товаров, чтобы тем самым гарантировать, что лицо, проводящее карту через считывающее устройство, также имеет пользовательское устройство и осведомлено о приобретаемых товарах. В некоторых вариантах осуществления пользователю может предлагаться подписаться зарегистрироваться, чтобы активизировать возможности приложения. После этого камера может предоставлять пользователю персональные возможности совершения покупок одним нажатием. Например, клиентское устройство может иметь камеру, посредством которой приложение может получать изображения, видеоданные, потоковое видео в реальном времени и/или т.п., например, 313. Приложение может быть сконфигурировано на анализ поступающих данных, например, 311 и поиск идентификатора продукта, например, 314. В некоторых вариантах осуществления приложение может накладывать перекрестие, целевой прямоугольник и/или аналогичные контрольные отметки для совмещения, например, 315, чтобы пользователь мог совместить идентификатор продукта с использованием контрольных отметок для облегчения распознавания и интерпретации идентификатора продукта. В некоторых вариантах осуществления приложение может содержать элементы интерфейса, позволяющие пользователю переключать между режимом идентификации продукта и экранами, отображающими предлагаемые наименования (например, 316), чтобы пользователь мог точно изучить доступные предложения до выбора идентификатора продукта. В некоторых вариантах осуществления приложение может предоставлять пользователю возможность просмотра до выбора идентификаторов продуктов (например, 317), чтобы помочь пользователю решить, какой идентификатор продукта он желает выбрать. В некоторых вариантах осуществления пользователь может пожелать аннулировать приобретение продукта, и приложение может предоставлять пользователю элемент интерфейса пользователя (например, 318), чтобы аннулировать процедуру распознавания идентификатора продукта и возвращаться к предыдущему экрану интерфейса, который использовал пользователь. В некоторых вариантах осуществления пользователю может предоставляться информация о продуктах, установленных пользователем значениях, торговцах, предложениях и т.д. в виде списка (например, 319), чтобы пользователь мог лучше разобраться в возможностях совершения покупки. Приложение может предоставлять различные другие возможности (например, 320).

В некоторых вариантах осуществления пользователь может быть способен просматривать и/или изменять профиль пользователя и/или установочные параметры пользователя, например, путем активации элемента 309 интерфейса пользователя (смотри фиг.3А). Например, пользователь может быть способен просматривать/изменять имя пользователя (например, 321А-В), номер счета(например, 322А-В), код защиты доступа пользователя (например, 323А-В), ПИН-код пользователя (например, 324А-В), адрес пользователя (например, 325А-В), номер социального страхования пользователя (например, 326А-В), текущее местоположение устройства согласно данным GPS (например, 327А-В), счет пользователя у торговца, в магазине которого в данный момент находится пользователь (например, 328А-В), поощрительные счета пользователя (например, 329А-В), и/или т.п. В некоторых вариантах осуществления пользователь может быть способен выбирать, какие поля данных и соответствующие значения следует передавать для совершения транзакции покупки, и тем самым обеспечивать улучшенную защиту данных. Например, в примере, проиллюстрированном на фиг.3В, пользователь выбрал имя 312а, номер 322а счета, код 323а в системе защиты, ID 328а счета у торговца и ID 329а поощрительного счета в качестве полей для передачи в составе уведомления для обработки транзакции покупки. В некоторых вариантах осуществления пользователь может переключать поля и/или значения данных, передаваемые в составе уведомления для обработки транзакции покупки. В некоторых вариантах осуществления приложение может обеспечивать множество экранов полей данных и/или соответствующих значений, хранящихся для пользователя, с целью выбора для передачи в составе заказа на покупку. В некоторых вариантах осуществления приложение может обеспечивать РРТ с указанием местоположения пользователя согласно данным GPS. На основании местоположения пользователя согласно данным GPS РРТ может определять контекст пользователя (например, находится ли пользователь в магазине, на приеме у врача, в больнице, в почтовом отделении и т.д.). На основании контекста пользователя приложение может представлять пользователю соответствующие поля, из которых пользователь может выбирать поля и/или значения для передачи в составе заказа на покупку.

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

На фиг.4 показана схема потоков данных, иллюстрирующая один из примеров процедуры регистрации в программе токенизированной оплаты покупок в некоторых вариантах осуществления РРТ. В некоторых вариантах осуществления пользователь, например, на шаге 401, может пожелать приобрести товар, услугу, рыночное изделие и/или т.п. (продукт) у торговца. Пользователь может связаться с сервером торговца, например, 403а посредством клиента, включая без ограничения персональный компьютер, мобильное устройство, телевизионный приемник, торговый терминал, киоск, банкомат и/или т.п. (например, 402). Например, пользователь может вводить в клиента данные, например, данные покупки на шаге 411 с указанием желания пользователя приобрести продукт. В различных вариантах осуществления ввод данных пользователем может включать без ограничения ввод с клавиатуры, считывание карты, активацию поддерживающего RFID/NFC аппаратного устройства (например, электронной карты с множеством счетов, смартфона, планшета и т.д.), щелчки клавишей мыши, нажатие кнопок на джойстике/игровой приставке, речевые команды, одно/многоточечные жесты на сенсорном интерфейсе, касание пользователем элементов интерфейса на сенсорном дисплее и/или т.п. Например, пользователь может адресовать просмотровое приложение, выполняемое в клиентском устройстве, на веб-сайт торговца и может выбирать продукт с веб-сайт путем щелчка по гиперссылке, представляемой пользователю посредством веб-сайта. В качестве другого примера, клиент может извлекать дорожку 1 данных из карты пользователя (например, кредитной карты, дебетовой карты, предоплаченной карты, платежной карты и т.д.), такие как дорожка 1 данных согласно приведенному далее примеру: %B123456789012345 PUBLIC/J.Q. 99011200000000000000**901******?* (при этом '123456789012345' означает номер карты, принадлежащей 'J.Q. Public' и имеющей номер CVV 901; '990112' означает служебный код, а *** отображает десятичные цифры, которые случайным образом изменяются при каждом использовании карты).

В некоторых вариантах осуществления клиент может генерировать сообщение с заказом на покупку, например, на шаге 412 и передавать, например, на шаге 413 генерированное сообщение с заказом на покупку серверу торговца. Например, просмотровое приложение, выполняемое в клиенте, может от лица пользователя передавать серверу торговца сообщение GET по протоколу (защищенной) передачи гипертекстов (HTTP(S)), содержащее подробности заказа продукта, в виде данных расширяемого языка разметки гипертекста (XML). Далее приведен пример сообщения GET по протоколу HTTP(S), содержащего сообщение на языке XML с заказом на покупку для сервера торговца:

В некоторых вариантах осуществления сервер торговца может получать сообщение с заказом на покупку от клиента и может проводить его синтаксический анализ с целью извлечения подробностей поступившего от пользователя заказа на покупку. На основании анализа сервер торговца может определять, что сообщение с заказом на покупку не токенизировано, например, на шаге 414. После определения того, что сообщение с заказом на покупку не токенизировано, сервер торговца может определять, что пользователю требуется предоставить возможность зарегистрироваться с целью получения услуг токенизации платежей. Сервер торговца может попытаться идентифицировать арбитратора токенов для предоставления пользователю услуг токенизации платежей. Например, сервер торговца может запрашивать, например, на шаге 415 в базе данных торговца, например, 404 адрес арбитратора токенов. Например, сервер торговца может использовать сценарий гипертекстовой предобработки (РНР), содержащий команды на языке структурированных запросов (SQL), для запроса адреса арбитратора токенов в реляционной базе данных. Далее приведен один из примеров листинга команд PHP/SQL с целью запроса адреса арбитратора токенов в базе данных:

В ответ база данных торговца может предоставить адрес арбитратора токенов, например, на шаге 416. Сервер торговца может генерировать запрос с предложением токенизации от имени пользователя, например, на шаге 417 и передавать запрос с предложением токенизации серверу токенов, например, 405. Например, сервер торговца может передавать сообщение POST по протоколу HTTP(S), содержащее запрос с предложением токенизации согласно приведенному далее примеру:

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

Клиент может воспроизводить, например, на шаге 421, предложение токенизации и форму заявления и отображать для пользователя, например, на шаге 422 предложение токенизации и форму заявления о создании токена, например, 423.

В некоторых вариантах осуществления пользователь может пожелать зарегистрироваться с целью подписки на услуги токенизации платежей и может заполнить форму 423 заявления о создании токена путем ввода данных. Клиент может генерировать заполненную форму заявления и передать серверу токенов (непосредственно или через сервер торговца) заявление о создании токена, например 424. Например, клиент может использовать сообщение HTTP(S) POST для заявления 424 о создании токена согласно приведенному далее примеру:

Сервер токенов может получать форму заявления и проводить ее синтаксический анализ, чтобы извлечь из нее поля и значения данных для генерирования записи данных токена, например, 425. Сервер токенов также может задавать набор правил конфиденциальности, ограничений, правил обработки транзакций (например, в какой стране должны находиться серверы, участвующие в обработке транзакций) и т.д., применимых к токену, созданному для пользователя. Например, такими ограничениями может быть установлено, что все транзакции с использованием токена могут обрабатываться только серверами (например, платежей), находящимися на территории определенной страны. В качестве другого примера, ограничения могут обновляться (например, периодически, автоматически, по требованию) в соответствии с законами о неприкосновенности личной жизни и/или другими законами, регламентирующими обработку транзакций в этой стране. В качестве другого примера, ограничениями могут устанавливаться весовые коэффициенты для различных факторов (например, выравнивания связанной с обработкой транзакций нагрузки на сервер, перегрузки сети, ограничений по конфиденциальности, ограничений по защите и т.д.), и может требоваться взвешивание факторов (например, путем вычисления средневзвешенного показателя на основании факторов), чтобы определять страну, в которой должна выполняться обработка транзакции с использованием токена. В качестве другого примера, для токена может быть установлен набор стран, в которых (не) может обрабатываться транзакция. Лишь в качестве неограничивающего пояснения, в приведенной далее структуре данных на языке проиллюстрирован пример правил 427, которые могут создаваться для токена и храниться в таблице (смотри, например, таблицу правил 1519n конфиденциальности на фиг.15) в базе 406b данных правил конфиденциальности:

Например, правилами может устанавливаться, где должны совершаться платежные операции, чтобы предотвратить использование не подлежащей огласке платежной информации пользователя вне территорий, предписанных правилами конфиденциальности. Например, в некоторых странах с жесткими мерами контроля конфиденциальности требуется, чтобы обработка платежей совершалась только в стране, в которой у пользователя имеется счет (смотри далее правило 1); в других странах мерами контроля конфиденциальности может требоваться, чтобы обработка платежей совершалась только в определенном регионе (например, в любой стране ЕС, смотри далее правило 2); в других странах могут отсутствовать ограничения по конфиденциальности, и обработка платежей может совершаться по существу где угодно (например, смотри далее правило 3) и могут существовать правила, способствующие выравниванию нагрузку и повышению производительности сетей за счет делегирования обработки менее загруженным серверам (например, смотри далее правило 4).

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

Сервер токенов может сохранять данные, извлеченные из формы заявления, в базе данных токенов, например, 406а, а установочные параметры 427 конфиденциальности/ограничений - в базе 406b данных правил конфиденциальности. Например, сервер токенов подавать команды PHP/SQL согласно приведенному далее примеру:

На фиг.5 показана логическая блок-схема, иллюстрирующая примеры особенностей регистрации в программе токенизированной оплаты покупок в некоторых вариантах осуществления РРТ, например, компонент 500 регистрации в программе токенизированной оплаты покупок (ТРЕ). В некоторых вариантах осуществления пользователь может пожелать приобрести товар, услугу, рыночное изделие, и/или т.п. (продукт) у торговца. Пользователь может вводить в клиента данные, например, данные покупки на шаге 501 с указанием желания пользователя приобрести продукт. В некоторых вариантах осуществления клиент может генерировать сообщение с заказом на покупку, например, на шаге 502, и передавать генерированное сообщение с заказом на покупку серверу торговца. Сервер торговца может получать сообщение с заказом на покупку от клиента и проводить его синтаксический анализ с целью извлечения подробностей поступившего от пользователя заказа на покупку, например, на шаге 503. Например, сервер торговца может использовать синтаксические анализаторы, аналогичные примерам синтаксических анализаторов, рассмотренных далее со ссылкой на фиг.15. На основании синтаксического анализа сервер торговца может определять, что сообщение с заказом на покупку не токенизировано, например, на шаге 504, опция "Нет". Если сервер торговца установит, что сообщение с заказом на покупку токенизировано, сервер торговца может инициировать процедуру обработки транзакции, такую как компонент tPTE 700, дополнительно описанный далее со ссылкой на фиг.7. После определения того, что сообщение с заказом на покупку не токенизировано, сервер торговца может определять, что пользователю требуется предоставить возможность зарегистрироваться с целью получения услуг токенизации платежей. Сервер торговца может попытаться идентифицировать арбитратора токенов для предоставления пользователю услуг токенизации платежей. Например, сервер торговца может запрашивать, например, на шаге 505 в базе данных торговца адрес арбитратора токенов. В ответ база данных торговца может предоставлять адрес арбитратора токенов, например, на шаге 506. Сервер торговца может генерировать запрос с предложением токенизации от лица пользователя, например, на шаге 507 и передавать запрос с предложением токенизации серверу токенов.

В некоторых вариантах осуществления сервер токенов может проводить синтаксический анализ запроса с предложением токенизации и извлекать из него данные пользователя и клиента, например, на шаге 508. Сервер токенов может определять, требуется ли от пользователя дополнительная информация, чтобы генерировать структуру данных токена и/или запись данных токен, например, на шаге 509. Если требуется дополнительная информация (например, не все поля записи данных токена могут быть заполнены доступной информацией), сервер токенов может генерировать форму ввода данных токена, например, на шаге 511 и предоставить ее пользователю. Сервер токенов предоставлять форму ввода данных токена клиенту (непосредственно клиенту или посредством сервера торговца). Клиент может воспроизводить форму и отображать ее, например, на шаге 512 для пользователя. В некоторых вариантах осуществления пользователь может получать форму, такую как проиллюстрированный на фиг.2Б пример интерфейса пользователя.

В некоторых вариантах осуществления пользователь может пожелать подписаться на услуги токенизации платежей и может ввести данные, например, 513 для создания токена, чтобы заполнить форму (например, в одном из примеров пользователь может использовать "маскирование" 1022, смотри фиг.10А или может иным способом указывать, что он желает повысить конфиденциальность данных транзакции) (в одном из альтернативных примеров пользователь может делать это путем запрашивания и/или приобретения иным способом предоплаченной карты, смарт-карты, карты одноразового использования, кредитной карты, дебетовой карты, смартфона, PDA с включенными в них данными токена). Клиент может генерировать заполненную форму и предоставлять ее, например, на шаге 514 серверу токенов (непосредственно или посредством сервера торговца). Сервер токенов может получать форму и проводить ее синтаксический анализ с целью извлечения из нее полей и значений данных и генерирования записи данных токена, например, на шаге 515. Например, сервер токенов может генерировать однозначно разрешимый идентификатор токена независимо от того, какой источник запрашивает токен (например, торговец, эмитент, торговый банк, платежная сеть, пользователь и т.д.). В некоторых вариантах осуществления сервер токенов отслеживает все генерированные токены посредством идентификаторов токенов, и после создания каждого токена требует, чтобы не допускалось создание токена с таким же идентификатором. В некоторых вариантах осуществления создание записей токенов может осуществляться последовательно. Например, может создаваться последовательность идентификаторов токенов для каждого эмитента, торговца, торгового банка и/или платежной сети. Например, каждая последовательность может содержать диапазон чисел, уникальный для каждого источника. В других вариантах осуществления вместо последовательного создания идентификаторов токенов они могут присваиваться путем случайного распределения. В некоторых вариантах осуществления каждый токен может быть предварительно профинансирован. Например, источник токена (например, эмитент, торговый банк, незавимый арбитратор токенов) может сначала получать гарантии однозначного и исключительного выделения средств токену из источника, на который указывает токен. Так, в некоторых вариантах осуществления токен может быть предварительно профинансирован и обеспечен средствами на сумму вплоть до (или в качестве альтернативы, точно) заданной суммы транзакции покупки. Например, сервер токенов может генерировать структуру данных токена, аналогичную структуре данных на языке XML согласно приведенном далее примеру:

Сервер токенов также может задавать набор правил конфиденциальности, ограничений, правил обработки транзакций (например, в какой стране должны находиться серверы, участвующие в обработке транзакций) и т.д., применимых к токену, созданному для пользователя. Сервер токенов может сохранять структуру данных токена в базе данных токенов, а установочные параметры конфиденциальности/ограничения/ - в базе данных правил конфиденциальности, например, на шаге 516. Сервер токенов также может предоставлять клиенту идентификатор токена, например, на шаге 517. Токен может предоставляться клиентскому устройству в виде структуры данных посредством сообщения POST по протоколу HTTP(S), в виде файла (по протоколам передачи файлов), в виде вложения (например, по электронной почте) и/или иным способом для последующего использования. Клиент сохранять идентификатор токена и/или отображать идентификатор токена для пользователя, например, на шаге 518.

На фиг.6А-Д показаны схемы потоков данных, иллюстрирующие один из примеров процедуры выполнения токенизированной транзакции покупки в некоторых вариантах осуществления РРТ. В некоторых вариантах осуществления пользователь, например, 601, может пожелать приобрести товар, услугу, рыночное изделие, и/или т.п. (продукт) у торговца. Пользователь может связываться с сервером торговца, например, 603а посредством клиента, включая без ограничения персональный компьютер, мобильное устройство, телевизионный приемник, торговый терминал, киоск, банкомат, и/или т.п. (например, 602). Например, пользователь может вводить в клиента данные, например, данные покупки на шаге 611 с указанием желания пользователя приобрести продукт. В различных вариантах осуществления ввод данных пользователем может включать без ограничения: ввод с клавиатуры, считывание карты, активацию поддерживающего RFID/NFC аппаратного устройства (например, электронной карты с множеством счетов, смартфона, планшета и т.д.), щелчки клавишей мыши, нажатие кнопок на джойстике/игровой приставке, речевые команды, одно/многоточечные жесты на сенсорном интерфейсе, касание пользователем элементов интерфейса на сенсорном дисплее и/или т.п. Например, пользователь может адресовать просмотровое приложение, выполняемое в клиентском устройстве, на веб-сайт торговца и может выбирать продукт с веб-сайт путем щелчка по гиперссылке, представляемой пользователю посредством веб-сайта. В качестве другого примера, клиент может извлекать дорожку 1 данных из карты пользователя (например, кредитной карты, дебетовой карты, предоплаченной карты, платежной карты и т.д.), такие как дорожка 1 данных согласно приведенному далее примеру:

В некоторых вариантах осуществления клиент может генерировать сообщение с заказом на покупку, например, на шаге 612 и передавать, например, на шаге 613 генерированное сообщение с заказом на покупку серверу торговца. Например, просмотровое приложение, выполняемое в клиенте, может от лица пользователя передавать серверу торговца сообщение GET по протоколу протоколу (защищенной) передачи гипертекстов (HTTP(S)), содержащее подробности заказа продукта, в виде данных расширяемого языка разметки гипертекста (XML). Далее приведен пример сообщения GET по протоколу HTTP(S), содержащего сообщение на языке XML с заказом на покупку для сервера торговца:

В некоторых вариантах осуществления сервер торговца может получать от клиента сообщение с заказом на покупку и проводить его синтаксический анализ с целью извлечения подробностей поступившего от пользователя заказа на покупку. На основании анализа сервер торговца может определять, что сообщение с заказом на покупку токенизировано. Сервер торговца запросить на шаге 615 базу данных, например, базу данных торговца, например, 604 с целью определения арбитратора для обработки токенизированного заказа на покупку. Например, сервер торговца может использовать сценарий гипертекстовой предобработки (РНР), содержащий команды на языке структурированных запросов (SQL), для запроса адреса арбитратора токенов в реляционной базе данных. Далее приведен один из примеров листинга команд PHP/SQL с целью запроса адреса арбитратора токенов в базе данных:

В ответ база данных торговца может предоставить адрес арбитратора токенов, например, 616. Сервер торговца генерировать запрос арбитража токенов, например, на шаге 617 и передать запрос арбитража токенов, например, на шаге 618 серверу токенов, например, 605. Например, сервер торговца может передавать сообщение POST по протоколу HTTP(S), содержащее запрос арбитража токенов, согласно приведенному далее примеру:

В различных вариантах осуществления сервер токенов может являться частью системы торговца (например, процесса торговли) или частью платежной сети (например, сервера платежной сети) или может представлять собой независимый сервер, взаимодействующий с торговцем, эмитентом, торговым банком и платежной сетью. В целом, подразумевается, что арбитратором токенов может служить любой объект и/или компонент, входящий в РРТ. В некоторых вариантах осуществления сервер токенов может проводить синтаксический анализ сообщения с запросом арбитража токенов и извлекать из него платежный токен. Сервер токенов может определять опции платежа для использования (или определять, следует ли запросить у пользователя подробности опций платежа) при обработке транзакция с использованием платежного токена. Например, сервер токенов может передавать, например, на шаге 619 базе данных, например, базе 606 данных токенов запрос эмитента пользователя с использованием в запросе платежного токена в качестве элемент поиска. Например, сервер токенов может использовать команды PHP/SQL по аналогии с описанными выше примерами. В ответ база данных токенов может предоставлять, например, на шаге 620, данные эмитентов, с которыми следует связаться в связи с платежом. Например, в ответе с данными эмитентов может содержаться файл данных на языке XML с предназначенными для сервера токенов указаниями по обработке платежей по транзакции. Далее приведен один из примеров файла данных эмитента на языке XML:

В некоторых вариантах осуществления сервер токенов может определять, например, на шаге 621, аутентифицирован ли пользователь токен. Например, если связанные с платежным токеном данные на языке XML недоступны, сервер токенов может определять, что пользователь не подписался на услуги токенизации платежей. В качестве другого примера, если данные на языке XML указывают, что у пользователя должна быть запрошена аутентификация (например, регистрация и пароль), сервер токенов может определять, что необходима проверка аутентификации. Сервер токенов может инициировать сеанс проверки пользователя. Например, приложение, выполняемое в пользовательском устройстве, может обеспечивать возможность "VerifyChat" предотвращения мошенничества (например, путем активации элемента UI 213 на фиг.2). Сервер токенов может использовать VerifyChat для связи с пользователем и проверки подлинности инициатора транзакции покупки. В различных вариантах осуществления сервер токенов может передавать сообщение электронной почты, текстовые (SMS) сообщения, сообщения Facebook®, Twitter™, текстовый диалог в реальном времени, речевой диалог в реальном времени, видеодиалог в реальном времени (например, Apple FaceTime) и/или т.п. для связи с пользователем. Например, сервер токенов может инициировать видеозапрос пользователя. Например, от пользователя может потребоваться представиться посредством видеодиалога в реальном времени. В некоторых вариантах осуществления сотрудник отдела по работе с покупателями может вручную устанавливать подлинность пользователя с использованием видеоизображения пользователя. В некоторых вариантах осуществления РРТ может использовать распознавание лица, биометрическую и/или подобную идентификацию (например, с использованием методов классификации образов), чтобы устанавливать личность пользователя. В некоторых вариантах осуществления приложение может предоставлять контрольную отметку (например, перекрестие, целевой прямоугольник и т.д.), чтобы пользователь мог использовать видео с целью облегчения автоматического распознания пользователя для РРТ. В качестве другого примера, сервер токенов может запросить у пользователя цифровой сертификат для проверки подлинности. В качестве другого примера, сервер может запросить у пользователя имя и пароль, чтобы активировать токен при обработке платежей.

Если сервер токенов установил, что пользователь аутентифицирован, сервер токенов может передать подверждение аутентификации токена, например, на шаге 622а. Кроме того, если сервер токенов определил, что у пользователя следует запросить опции платежа (например, вместо использования только предварительно заданных установочных параметров из ответа с данными эмитента на шаге 620), сервер токенов может запросить опции платежа у пользователя. Например, сервер токенов может передавать может передавать клиенту 602 сообщение POST по протоколу HTTP(S) по аналогии с приведенными выше примерами. Клиент может воспроизводить, например, на шаге 623 подтверждение токена аутентификация и/или запрос опций платежа и отображать сообщение(-я) для пользователя, например, на шаге 624.

В некоторых вариантах осуществления пользователь может пожелать ввести собственные опции платежа для обработки текущей транзакции покупки. В таких вариантах осуществления на шаге 626 пользователь может вводить данные опций платежа, например, такие как рассмотрены выше со ссылкой на фиг.2. Клиент может генерировать сообщение с опциями платежа путем ввода данных и передавать сообщение с опциями платежа, например, 627 серверу токенов. В некоторых вариантах осуществления, сервер токенов может извлекать из базы данных правил конфиденциальности установочные параметры конфиденциальности/ограничений, например, 628a, на основании которых сервер токенов может определять местоположение и идентифицировать сервер, которому сервер токенов должен передать данные токена, данные эмитента, опции платежа и т.д. для обработки транзакции. В некоторых вариантах осуществления сервер токенов может определять, например, на шаге 628b эмитентов для установления связи с целью обработки платежей с использованием предварительно заданных установочных параметров эмитента, правил конфиденциальности/ограничений/установочных параметров и/или опций платежа, введенных пользователем. В некоторых вариантах осуществления сервер токенов может обновлять, например, на шаге 629 данные эмитента, хранящиеся в базе данных токенов, с использованием опции платежа, введенных пользователем.

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

В некоторых вариантах осуществления сервер платежной сети может генерировать запрос, например, 635 сервера(-ов) эмитента, соответствующего платежному токену и выбранным пользователем опциям платежа. Например, платежный токен пользователя может быть привязан к одному или нескольким финансовым учреждениям-эмитентам (эмитентам), таким как банковские учреждения, которые открыли для пользователя счет(-а), привязанный платежный к токену. Например, такие счета могут включать без ограничения кредитную карту, дебетовую карту, предоплаченную карту, чековый счет, сберегательный счет, депозитный счет денежного рынка, депозитные сертификаты, счета хранимой суммой и/или т.п. В сервере(-ах), например, 609a-n эмитента(-ов) могут храниться подробности счета пользователя, привязанного к платежному токену. В некоторых вариантах осуществления подробности сервера(-ов) эмитента(-ов) могут храниться в базе данных, например, базе 608 данных платежной сети. База данных может являться, например, реляционной базой данных, реагирующей на команды на языке структурированных запросов (SQL). Сервер платежной сети может запрашивать подробности сервера(-ов) эмитентов в базе данных платежной сети. Например, сервер платежной сети может выполнять сценарий гипертекстовой предобработки (РНР), содержащий команды с целью запроса подробностей сервера(-ов) эмитентов в базе данных. Далее приведен один из примеров листинга команд PHP/SQL, иллюстрирующий существенные особенности запросов базы данных:

В ответ на запрос сервера эмитента, например, 635 база данных платежной сети может передавать, например, на шаге 636 серверу платежной сети запрошенные данные сервера эмитента. В некоторых вариантах осуществления сервер платежной сети может использовать данные сервера эмитента, чтобы генерировать, например, на шаге 637, запрос(-ы) авторизации каждого из серверов эмитентов, выбранного на основании предварительно заданных установочных параметров, связанных с токеном, и/или введенных пользователем опций платежа, и передавать запрос(-ы) авторизации карты, например, 638a-n, серверу(-ам) эмитентов, например, 609a-n. В некоторых вариантах осуществления запрос(-ы) авторизации может содержать подробности, включающие без ограничения расходы пользователя, участвующего в транзакции, подробности карточного счета пользователя, сведения о выставлении счетов пользователю и/или отправке и/или т.п. Например, сервер платежной сети может передавать сообщение POST по протоколу HTTP(S), содержащее запрос авторизации на языке XML, согласно приведенному далее примеру:

В некоторых вариантах осуществления сервер эмитента может проводить синтаксический анализ запроса(-ов) авторизации и на основании подробностей запроса может запрашивать в базе данных, например, базе 610a-n данных профилей пользователей данные, касающиеся счета, привязанного к платежному токену пользователя. Например, сервер эмитента может передавать команды PHP/SQL согласно приведенному далее примеру:

В некоторых вариантах осуществления после получения пользовательских данных, например, 640a-n сервер эмитента может определять, например, на шаге 641a-n, может ли пользователь оплатить транзакцию с использованием средств, доступных на счете. Например, сервер эмитента может определять, достаточен ли остаток на счете пользователе, достаточен кредит по счету и/или т.п. В зависимости от результата сервер(-ы) эмитентов может передавать, например, на шаге 642a-n ответ на запрос авторизации серверу платежной сети. Например, сервер(-ы) эмитентов может передавать сообщение POST по протоколу HTTP(S) по аналогии с приведенными выше примерами. Если, по меньшей мере, один сервер эмитента установит, что пользователь не способен оплатить транзакцию с использованием средств, доступных на счете, например, на шагах 643, 644, в некоторых вариантах осуществления сервер платежной сети может снова запросить у пользователя опции платежа (например, путем передачи серверу токенов сообщения 644 о неудачной попытке авторизации, чтобы сервер токенов снова получил от пользователя опции платежа) и может повторить попытку авторизации для совершения транзакция покупки. Если число неудачных попыток авторизации превысит определенный предел, в некоторых вариантах осуществления сервер платежной сети может отказаться от выполнения процедуры авторизации и передать серверу торговца, серверу токенов и/или клиенту сообщение "авторизация не удалась".

В некоторых вариантах осуществления сервер платежной сети может получать сообщение об авторизации, содержащее уведомление об успешной авторизации, например, на шагах 643, 646 и проводить синтаксический анализ сообщения с целью извлечения подробностей авторизации. После того, как установлено, что пользователь имеет достаточно средств для совершения транзакции, сервер платежной сети может генерировать запись данных транзакции, например, 645 на основании запроса авторизации и/или ответа на запрос авторизации и сохранять подробности транзакции и авторизации, связанной с транзакцией, в базе данных транзакций. Например, чтобы сохранить данные транзакции базе данных, сервер платежной сети может передавать команды PHP/SQL согласно приведенном далее примеру:

В некоторых вариантах осуществления сервер платежной сети может пересылать сообщение об успешной авторизации, например, 646 серверу токенов, который в свою очередь может пересылать сообщение об успешной авторизации, например, 647 серверу торговца. Торговец может получать сообщение об авторизации и на его основании определять, что пользователь имеет достаточно средств на карточном счете для совершения транзакции. Сервер торговца может вносить дополнительную запись о транзакции пользователя в данные группы транзакций авторизованных транзакций. Например, торговец может присоединять, например, на шаге 648 данные на языке XML, касающиеся транзакции пользователя, к файлу данных на языке XML, содержащему данные группы транзакций, которые были авторизованы для различных пользователей, и сохранять, например, на шаге 649 файл данных на языке XML в базе данных, например, базе 604 данных торговца. Например, файл данных на языке XML может иметь структуру, сходную с приведенным далее примером образца структуры данных на языке XML:

В некоторых вариантах осуществления сервер также может генерировать, например, на шаге 648 квитанцию об оплате покупки и предоставлять ее клиенту, например, на шаге 650. Клиент может воспроизводить и отображать, например, на шагах 651-652, квитанцию об оплате покупки для пользователя. Например, клиент может воспроизводить веб-страницу, электронное сообщение, текстовое/SMS-сообщение, поместить в буфер речевое сообщение, передать сигнал вызова и/или воспроизводить звуковое сообщение и т.д. и отображать выходные данные, включающие без ограничения звуковые сигналы, музыку, аудио, видео, изображения, тактильную обратную связь, вибрационные уведомления (например, на поддерживающих вибрационные уведомления клиентских устройствах, таких как смартфон и т.д.) и/или т.п.

Как показано на фиг.6Д, в некоторых вариантах осуществления сервер торговца может инициировать расчеты по группе авторизованных транзакций. Например, сервер торговца может генерировать, например, на шаге 653 запрос данных группы транзакций и передавать его, например, на шаге 654 базе данных, например, базе 604 данных торговца. Например, сервер торговца может использовать команды PHP/SQL согласно приведенным выше примерам для запроса реляционной базы данных. В ответ на запрос данных группы транзакций база данных может предоставлять, например, на шаге 655 запрошенные данные группы транзакций. Сервер может генерировать, например, на шаге 656 запрос расчетов по группе транзакций с использованием данных группы транзакций, полученных от базы данных, и передавать, например, на шаге 657 запрос расчетов по группе транзакций торговому банку сервера, например, 603b. Например, сервер торговца может передавать торговому банку сервер сообщение POST по протоколу HTTP(S), в теле которого содержатся данные группы транзакций на языке XML. Сервер торгового банка может генерировать, например, на шаге 658, платежное требование по группе транзакций с использованием полученного запроса расчетов по группе транзакций и передавать его серверу платежной сети, например, на шаге 659. Сервер платежной сети может проводить синтаксический анализ платежного требования по группе транзакций и извлекать данные каждой транзакции из платежного требования по группе транзакций, например, на шаге 660. Сервер платежной сети может сохранять данные, например, на шаге 661, каждой транзакции в базе данных, например, базе 608 данных платежной сети. Сервер платежной сети может запрашивать, например, на шагах 662-663 в базе данных, например, базе 608 данных платежной сети адрес сервера эмитента для извлеченных данных каждой транзакции. Например, сервер платежной сети может использовать команды PHP/SQL согласно приведенным выше примерам. Сервер платежной сети может генерировать индивидуальное платежное требование, например, на шаге 664 в отношении каждой транзакции, для которой у него имеются извлеченные данные, и передавать индивидуальное платежное требование, например, на шаге 665 серверу эмитента, например, 609. Например, сервер платежной сети может передавать запрос POST по протоколу HTTP(S) согласно приведенному далее примеру:

В некоторых вариантах осуществления сервер эмитента может генерировать команду оплаты, например, на шаге 666. Например, сервер эмитента может передавать команду снятия средств со счета пользователя (или списания со счета кредитной карты пользователя). Сервер эмитента может передавать команду оплаты, например, на шаге 667 базе данных, в которой хранятся данные счета пользователя, например, базе 610 данных профилей пользователей. Сервер эмитента может передавать сообщение о переводе средств, например, на шаге 668 серверу платежной сети, который может пересылать его, например, на шаге 669 торговому банку сервер. Далее приведено один из примеров сообщения POST о переводе средств по протоколу HTTP(S):

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

На фиг.7А-Е показаны логические блок-схемы, иллюстрирующие примеры особенностей выполнения токенизированной транзакции покупки в некоторых вариантах осуществления РРТ, например, компонент 700 выполнения токенизированной транзакции покупки (tPTE). В некоторых вариантах осуществления пользователь может пожелать приобрести товар, услугу, рыночное изделие и/или т.п. (продукт) у торговца. Пользователь может связываться с сервером торговца посредством клиента. Например, пользователь может вводить в клиента, например, на шаге 701 данные покупки с указанием желания пользователя приобрести продукт. В некоторых вариантах осуществления клиент может генерировать токенизированное сообщение с заказом на покупку, например, на шаге 702 и передавать его серверу торговца. Сервер торговца может получать от клиента сообщение с заказом на покупку и может проводить его синтаксический анализ с целью извлечения подробностей из полученного от покупателя заказа на покупку. На основании анализа сообщения торговец может определять, например, на шаге 703, что заказ на покупку токенизирован. Если сервер торговца установит, например, на шаге 704, опция "Нет", что заказ на покупку не токенизирован, сервер торговца может обрабатывать транзакцию как нормальную транзакцию по карте в обход процесса интерпретации токена. Если сервер торговца установит, например, на шаге 704, опция "Да", что заказ на покупку токенизирован, сервер торговца может запросить, например, на шаге 705 базу данных торговца определить арбитратора для обработки токенизированного заказа на покупку. В ответ база данных торговца может предоставить адрес арбитратора токенов, например, на шаге 707. Сервер торговца может генерировать запрос арбитража токенов, например, на шаге 708 и передавать его серверу токенов.

В некоторых вариантах осуществления сервер токенов может проводить синтаксический анализ запроса арбитража токенов и извлекать из него платежный токен. Сервер токенов может определять опции платежа для использования (или определять, следует ли запросить у пользователя подробности опций платежа) при обработке транзакции с использованием платежного токена. Например, сервер токенов может передавать, например, на шаге 708 базе данных токенов запрос эмитента пользователя с использованием в запросе платежного токена в качестве элемента поиска. В ответ база данных токенов может предоставлять, например, на шаге 709 данные эмитентов для установления связи в целях платежа. В некоторых вариантах осуществления сервер токенов может определять, например, на шаге 710, аутентифицирован ли пользователь токен. Если сервер токенов установит, например, на шаге 711, опция "Нет", что пользователь не аутентифицирован, сервер токенов может генерировать сообщение о неудачной аутентификации, например, на шаге 712a и инициировать, например, на шаге 712b, программу обработки ошибок и/или программу регистрации пользователя, такую как компонент РТЕ 500, рассмотренные выше со ссылкой на фиг.5. Если сервер токенов установит, например, на шаге 711, опция "Да", что пользователь аутентифицирован, сервер токенов может продолжать обработку на шаге 713a. Сервер токенов может генерировать на шаге 713a запрос данных токена из базы данных токенов, а также правил конфиденциальности, ограничений, установочных параметров и т.д., связанных с токеном, из базы данных правил конфиденциальности. Например, такими ограничениями может быть установлено, что все транзакции с использованием токена могут обрабатываться только серверами, находящимися на территории определенной страны. В качестве другого примера, ограничения могут обновляться (например, периодически, автоматически, по требованию) в соответствии с законами о неприкосновенности личной жизни и/или другими законами, регламентирующими обработку транзакций в этой стране. В качестве другого примера, ограничениями могут устанавливаться весовые коэффициенты для различных факторов (например, выравнивания связанной с обработкой транзакций нагрузки на сервер, перегрузки сети, ограничений по конфиденциальности, ограничений по защите и т.д.), и может требоваться взвешивание факторов (например, путем вычисления средневзвешенного показателя на основании факторов), чтобы определять страну, в которой должна выполняться обработка транзакции с использованием токена. В качестве другого примера, для токена может быть установлен набор стран, в которых (не) может обрабатываться транзакция. База данных правил конфиденциальности может предоставлять запрошенные данные серверу токенов на шаге 713b. Как описано выше, в одном из вариантов осуществления, в котором токен не содержит код страны, для установления страны постоянного местожительства пользователя, кода страны и/или соответствующих ограничений может использоваться табличная база данных конфиденциальности, например, 1519o с использованием токена в качестве основы для запроса такой табличной базы данных. Сервер токенов может использовать данные токена и/или правила конфиденциальности, ограничения, установочные параметры и т.д., чтобы определять, например, на шаге 714, следует ли запросить у пользователя опции платежа (например, вместо использования только предварительно заданных установочных параметров в полученных данных эмитента). Если сервер токенов установит, например, на шаге 715, опция "Нет", что у пользователя следует запросить установочные параметры опций платежа, сервер токенов может запросить у пользователя опции платежа, например, на шаге 716. Клиент может воспроизводить запрос опций платежа и отображать его, например, на шаге 717.

В некоторых вариантах осуществления пользователь может пожелать ввести собственные опции платежа для обработки текущей транзакции покупки. В таких вариантах осуществления пользователь может вводить опции платежа на шаге 718. Клиент может генерировать сообщение, содержащее опции платежа, с использованием данных пользователя и передавать его серверу токенов. В некоторых вариантах осуществления сервер токенов может идентифицировать, например, на шаге 719 (например, определять IP-адрес, МАС-адрес, URL и т.д.) сервер(-ы) платежной сети(-ей), эмитента(-ов) для установления связи в целях обработки платежей с использованием предварительно заданных установочных параметров эмитента, правил конфиденциальности, ограничений на обработку транзакций, установочных параметров и т.д. (полученных в базе данных правил конфиденциальности) и/или опций платежа, предоставленных пользователем. В некоторых вариантах осуществления сервер токенов может обновлять, например, на шаге 720 данные эмитента, хранящиеся в базе данных токенов, с использованием опций платежа, предоставленных пользователем. В некоторых вариантах осуществления сервер токенов может генерировать, например, на шаге 721 сообщение "выполняется авторизация" и передавать его серверу торговца, который в свою очередь может пересылать, например, на шаге 722, сообщение клиенту. Клиент может воспроизводить и отображать, например, на шаге 723 для пользователя сообщение "выполняется авторизация".

В некоторых вариантах осуществления сервер токенов может генерировать, например, на шаге 724 сообщение, содержащее данные токена, данные эмитента и/или введенные пользователем опции платежа и передавать его выбранному серверу платежной сети (например, если сервер токенов реализован отдельно от системы платежной сети) с использованием правил конфиденциальности, ограничений на обработку транзакций, установочных параметров и т.д. Сервер платежной сети может обрабатывать транзакцию с целью перевода средств для оплаты покупки на счет в торговом банке торговца. Если сервер торговца сначала принял от клиента не токенизированное сообщение с заказом на покупку, например, на шаге 725, сервер торговца может генерировать, например, на шаге 726 запрос карты и передавать его серверу торгового банка. Сервер торгового банка может проводить синтаксический анализ сервер запроса, например, на шаге 727, генерировать запрос авторизации карты, например, на шаге 728 и передавить его серверу платежной сети. Тем не менее, если заказ на покупку, принятый от клиента, токенизирован, сервер токенов может преобразовывать подробности платежа для использования, как описано выше, и может предоставлять серверу платежной сети токен и опции платежа, например, на шаге 729.

В некоторых вариантах осуществления сервер платежной сети может генерировать запрос, например, на шаге 729 сервера(-ов) эмитентов, соответствующего платежному токену и выбранным пользователем опциям платежа. В некоторых вариантах осуществления сервер платежной сети может запросить в базе данных платежной сети данные сервера(-ов) эмитентов, например, на шаге 730. В ответ на запрос данных сервера эмитента база данных платежной сети может предоставлять, например, на шаге 731 серверу платежной сети запрошенные данные сервера эмитента. В некоторых вариантах осуществления сервер платежной сети может использовать данные сервера эмитента, чтобы генерировать запрос(-ы) авторизации, например, на шаге 732 для каждого из серверов эмитентов, выбранных на основании связанных с токеном предварительно заданных установочных параметров платежа и/или введенных пользователем опций платежа, и передавать запрос(-ы) авторизации карты серверу(-ам) эмитентов. В некоторых вариантах осуществления сервер эмитента может проводить синтаксический анализ запроса(-ов) авторизации, например, на шаге 733 и на основании данных запроса может запрашивать в базе данных профилей пользователей, например, на шаге 734 данные счета, привязанного к платежному токену пользователя. В некоторых вариантах осуществления после получения пользовательских данных, например, на шаге 735 сервер эмитента может определять, например, на шаге 736, способен ли пользователь оплатить транзакцию с использованием средств, доступных на счете. Например, сервер эмитента может определять, достаточен ли остаток на счете пользователе, достаточен кредит по счету и/или т.п. В зависимости от результата сервер(-ы) эмитентов может генерировать и передавать, например, на шаге 737 ответ на запрос авторизации серверу платежной сети. Если, по меньшей мере, один сервер эмитента установит, что пользователь не способен оплатить транзакцию с использованием средств, доступных на счете, например, на шагах 738, 739, опция "Нет", в некоторых вариантах осуществления сервер платежной сети может снова запросить у пользователя опции платежа (например, путем передачи серверу токенов сообщения 644 о неудачной попытке авторизации, чтобы сервер токенов снова получил от пользователя опции платежа) и может повторить попытку авторизации для совершения транзакция покупки. Если число неудачных попыток авторизации превысит определенный предел, например, на шаге 740, опция "Да", в некоторых вариантах осуществления сервер платежной сети может отказаться от выполнения процедуры авторизации и передать, например, на шаге 741 серверу торговца, серверу токенов и/или клиенту сообщение "транзакция прекращена".

В некоторых вариантах осуществления сервер платежной сети может получать сообщение об авторизации, содержащее уведомление об успешной авторизации, и может проводить его синтаксический анализ сообщение с целью извлечения подробностей авторизации. После того, как установлено, например, на шаге 739, опция "Да", что пользователь располагает достаточными средствами для совершения сервер платежной сети может генерировать запись данных транзакции, например, на шаге 742 на основании запроса авторизации и/или ответа на запрос авторизации и сохранить, например, а шаге 743, данные транзакции и авторизации транзакции в базе данных транзакций. В некоторых вариантах осуществления сервер платежной сети может генерировать сообщение об успешной авторизации, например, на шаге 744 и пересылать его серверу токенов, который в свою очередь может пересылать сообщение об успешной авторизации, например, на шагах 745-746 серверу торгового банка и/или серверу торговца. В некоторых вариантах осуществления сообщение об успешной авторизации может не содержать персональной идентифицирующей информации и в некоторых вариантах осуществления может содержать только платежный идентификатор токена. Торговец может получать сообщение об авторизации и на его основании определять, например, на шагах 747-748, была ли авторизована транзакция. Если установлено, например, на шаге 748, опция "Да", что транзакция была авторизована, сервер торговца может добавить запись о транзакции пользователя к данным группы авторизованных транзакций, например, на шаге 749-750. В некоторых вариантах осуществления сервер также может генерировать квитанцию об оплате покупки, например, на шаге 751 и передавать ее клиенту. Клиент может воспроизводить и отображать для пользователя, например, на шаге 753, квитанцию об оплате покупки.

Как показано на фиг.7Д-Е, в некоторых вариантах осуществления сервер торговца может инициировать расчеты по группе авторизованных транзакций. Например, сервер торговца может генерировать запрос данных группы транзакций, например, на шаге 754 и передавать его базе данных торговца. В ответ на запрос данных группы транзакций база данных торговца может предоставлять запрошенные данные группы транзакций, например, на шаге 755. Сервер может генерировать запрос расчетов по группе транзакций, например, на шаге 756 с использованием данных группы транзакций, полученные в базе данных, и передавать его серверу торгового банка. Сервер торгового банка может проводить синтаксический анализ запрос расчетов по группе транзакций, например, на шаге 657, генерировать, например, на шаге 758 платежное требование по группе транзакций с использованием полученного запроса расчетов по группе транзакций и передавать платежное требование по группе транзакций серверу платежной сети. Сервер платежной сети может проводить синтаксический анализ платежного требования по группе транзакций, например, на шаге 759, и извлекать данные каждой транзакции из платежного требования по группе транзакций. Сервер платежной сети может извлекать данные транзакции покупки, например, на шаге 761 из платежного требования по группе транзакций и генерировать запись данных транзакции, например, на шаге 762. Сервер платежной сети может сохранять, например, на шаге 763, данные каждой транзакции в базе данных платежной сети. Сервер платежной сети может запрашивать в базе данных платежной сети, например, на шагах 764-765 адрес сервера эмитента для каждой транзакции, данные которой извлечены. Сервер платежной сети может генерировать индивидуальное платежное требование, например, на шаге 766 для каждой транзакции, данные которой извлечены, и передавать его серверу эмитента.

В некоторых вариантах осуществления сервер эмитента может проводить синтаксический анализ индивидуального платежного требования, например, на шаге 767 и генерировать команду оплаты, например, на шаге 768. Например, сервер эмитента может передавать команду снятия средств со счета пользователя (или списания средств со счета кредитной карты пользователя). Сервер эмитента может передавать команду оплаты базе данных профилей пользователей. Сервер эмитента может генерировать сообщение о переводе средств, например, на шаге 770 и передавать его серверу платежной сети. Как описано выше, система может обрабатывать каждое индивидуальное платежное требование из группы, пока не будут обработаны все запросы в группе, например, на шаге 771. Затем сервер платежной сети может генерировать сообщение о переводе средств по группе транзакций, например, на шаге 772 и передавать его серверу торгового банка, например, на шаге 773. В некоторых вариантах осуществления сервер торгового банка может проводить синтаксический анализ сообщения о переводе средств и увязывать транзакцию с торговцем. Затем сервер торгового банка может переводить средства, указанные в сообщении о переводе средств, на счет торговца, например, на шаге 774.

На фиг.8 схематически показан интерфейс пользователя, иллюстрирующий общее представление примеров возможностей приложений для виртуального бумажника в некоторых вариантах осуществления РРТ. На фиг.8 проиллюстрированы различные примеры возможностей мобильного приложения 800 для виртуального бумажника. Некоторые из представленных возможностей включают бумажник 801, социальную интеграцию посредством TWITTER, FACEBOOK и т.д., предложения и программы 803 лояльности, покупку в режиме 804 режиме моментальных снимков, предупреждения 805 и безопасность, параметры настройки и аналитику 896. Эти возможности более подробно рассмотрены далее.

На фиг.9А-Ж схематически показаны интерфейсы пользователя, иллюстрирующие примеры возможностей приложений для виртуального бумажника в режиме совершения покупок в некоторых вариантах осуществления РРТ. Как показано на фиг.9А, в некоторых вариантах осуществления мобильного приложения для виртуального бумажника облегчаются и значительно расширяются возможности совершения покупок пользователями. Как показано на фиг.9А, пользователю могут быть доступны для рассмотрения разнообразные режимы совершения покупок. В одном из вариантов осуществления, пользователь может инициировать, например, режим совершения покупок путем выбора иконки 910 покупок в нижней части интерфейса пользователя. Пользователь может ввести на клавиатуре искомое наименование в поле 912 поиска и/или поместить его в корзину 911 для виртуальных покупок. Пользователь также может использовать управляемый голосом режим совершения покупок путем произнесения в микрофон 913 названия или описания искомого наименования и/или наименования для помещения в корзину для виртуальных покупок. В одном из дополнительных вариантов осуществления пользователь также может выбирать другие опции 914 совершения покупок, такие как текущие наименования 915, счета 916, адресная книга 917, торговцы 918 и ближайшее соседство 919.

В одном из вариантов осуществления пользователь может выбрать, например, опция текущие наименования 915, представленный в крайнем левом интерфейсе пользователя на фиг.9А. Когда выбран опция текущие наименования 915, может отображаться средний интерфейс пользователя. Как показано, на среднем интерфейсе пользователя может быть представлен текущий список наименований 915a-h в корзине пользователя для виртуальных покупок. Пользователь может наименование, например наименование 915a, просматривать описание 915j выбранного наименований и/или других наименований того же торговца. Кроме того, может отображаться цена и итоговая сумма к оплате, а также код 915k QR, в котором содержится информация, необходимая для совершения транзакция покупки в режиме моментальных снимков.

Как показано на фиг.9Б, в другом варианте осуществления пользователь может выбирать опция счета 916. После выбора опции 916 счета интерфейс пользователя может отображать список счетов и/или квитанций 916a-h одного или нескольких торговцев. Рядом с каждым из счетов может отображаться дополнительная информация, такая как дата посещения, представлены ли наименования из множества магазинов, дата оплата последнего счета, автоматический платеж, число продуктов и/или т.п. В одном из примеров, может быть выбран счет покупок с использованием бумажника 916a от 20 января 2011 года. При выборе счет покупок с использованием бумажника может отображаться интерфейс пользователя, на котором представлена разнообразная информация, касающаяся выбранного счета. Например, интерфейс пользователя может отображать список приобретенных наименований 916k, <<916i>>, общее число наименований и соответствующую стоимость. Например, в выбранном счете покупок с использованием бумажника содержалось 7 наименований стоимостью $ 102,54. Затем пользователь может выбирать любые из наименований и добавлять приобретаемые наименования. Пользователь также может обновлять предложения 916j, чтобы удалить любые предложения, ставшие недействительными с момента последнего обновления, и/или искать новые предложения, которые могут быть применимы к текущей покупке. Как показано на фиг.9Б, пользователь выбирал два наименования для повторного приобретения. После их добавления может отображаться сообщение 9161, подтверждающее добавление двух наименований, после чего общее число наименований в корзине для виртуальных покупок составляет 14.

Как показано на фиг.9В, в еще одном варианте осуществления пользователь выбрать опция 917 адресная книга для просмотра адресной книги 917a, в которой содержится список контактных лиц 917b, и перевода денег или совершения платежей. В одном из вариантов осуществления для каждого контактного лица в адресной книге может указываться имя и доступные и/или предпочтительные способы платежа. Например, платеж контактному лицу Amanda G. Может совершаться посредством социальной сети (например, FACEBOOK), обозначенной иконкой 917c. В другом примере деньги могут быть переведены Brian S. посредством кода QR, обозначенного иконкой 917d. В еще одном примере платеж Charles В. может быть совершен посредством ближней связи 917e, Bluetooth 917f и электронной почты 917g. Платеж также может совершаться посредством USB 917h (например, путем установления физического соединения между двумя мобильными устройствами), а также посредством других социальных сетей, таких как TWITTER.

В одном из вариантов осуществления пользователь может выбрать Joe Р. для совершения платежа. Как показано на интерфейсе пользователя, рядом с именем Joe Р. находится иконка 917g электронной почты, указывающая, что Joe Р. принимает платеж посредством электронной почты. При выборе его имени интерфейс пользователя может отобразить его контактные данные, такие как адрес электронной почты, номер телефона и т.д. Если пользователь желает совершить платеж Joe Р. иным способом, а не по электронной почте, пользователь может добавить другой режим 917j перевода средства в его контактные данные и совершить платеж. Как показано на фиг.9Г, для пользователя может отображаться экран 917k, на котором пользователь может вводить сумму для перевода Joe, а также добавлять другой текст, чтобы обеспечить Joe контекстом платежной операции 917l. Пользователь может выбирать режимы (например, SMS, электронную почту, социальную сеть) для связи с Joe посредством элементов 917m графического интерфейса пользователя (ТИП). Вводимый пользователем текст может отображаться для просмотра посредством элемента 917n ТИП. После того, как пользователь завершит ввод необходимой информации, пользователь может нажать на кнопку 917o отправить, чтобы передать сообщение Joe через социальную сеть. Если у Joe также имеется приложение для виртуального бумажника, Joe может быть способен принимать сообщение 917p о платеже через социальную сеть посредством приложения или непосредственно на веб-сайте социальной сети (например, Twitter™, Facebook® и т.д.). Могут сочетаться сообщения, поступающие через различные социальные сети и из других источников (например, SMS, электронной почты). В сообщении может указываться способ выплаты, применимый к каждому режиму обмена сообщениями. Как показано на фиг.9Г, в принятом Joe SMS-сообщении 917q указано, что для выплаты Joe $5, полученных посредством SMS-сообщения, ему следует ответить на SMS-сообщение и ввести хештег '#1234'. Там же показано, что получил сообщение 917r по сети Facebook® с указанием ссылки на URL, которую Joe может активировать, чтобы инициировать выплату ему $25.

Как показано на фиг.9Д, в некоторых других вариантах осуществления пользователь может выбрать опция торговцы 918 из списка режимов совершения покупок, чтобы просмотреть выборочный список торговцев 918А-Д. В одном из вариантов осуществления торговцы из списка могут быть привязаны к бумажнику или взаимосвязаны с бумажником по принципу родства. В другом варианте осуществления в список торговцев могут входить торговцы, отвечающие заданным пользователем или другим критериям. Например, списком может являться список, который курируется пользователем, список торговцев, у которых пользователь чаще всего совершает покупки или тратит сумму, превышающую сумму x, или совершает покупки в течение трех месяцев подряд и/или т.п. В одном из вариантов осуществления пользователь может дополнительно выбирать одного из торговцев, например, Amazon 918a. Затем пользователь может просматривать каталоги торговца, чтобы найти интересующие его наименования, такие как 918f-j. Пользователь может выбирать наименование 918j из каталога Amazon 918a непосредственно через бумажник без посещения сайта торговца на отдельной странице. Как показано на крайнем правом интерфейсе пользователя на фиг.9Г, затем выбранное наименование может быть помещено в корзину для виртуальных покупок. В сообщении 918k указано, что выбранное наименование помещено в корзину для виртуальных покупок, и обновленное число наименований в корзине для виртуальных покупок теперь составляет 13.

Как показано на фиг.9Е, в одном из вариантов осуществления предусмотрен опция 919 ближайшее соседство, который может выбираться пользователем для просмотра списка торговцев, находящихся в непосредственной близости от пользователя. Например, в список торговцев 919a-e могут входить торговцы, находящиеся вблизи пользователя. В одном из вариантов осуществления на основании местоположения пользователя мобильное приложение может дополнительно определять, что пользователь находится в магазине. Например, когда пользователь находится вблизи магазина, рядом с названием магазина (например, Walgreens) может отображаться иконка 919d положения. В одном из вариантов осуществления мобильное приложение может периодически обновлять местоположение пользователя в случае, когда пользователь отдаляется от магазина (например, Walgreens). В одном из дополнительных вариантов осуществления пользователь может посредством мобильного приложения просматривать рыночное изделие в выбранном магазине Walgreens. Например, пользователь может просматривать с использованием мобильного приложения наименования 919f-j, находящиеся в проходе 5 в магазине Walgreens. В одном из вариантов осуществления пользователь может выбрать кукурузу на шаге 919i с помощью своего мобильного приложения и добавить в корзину для виртуальных покупок на шаге 919k.

Как показано на фиг.9Ж, в другом варианте осуществления опция 919 ближайшее соседство может включать, в том числе, возможности отображения карты магазина в реальном времени. Например, после выбора магазина Walgreens пользователь может открыть карту 919l проходов с отображением карты 919m, на которой представлено устройство магазина и положение пользователя (указанно желтым кругом). В одном из вариантов осуществления пользователь может легко сконфигурировать карту на добавление одного или нескольких других пользователей (например, детей пользователя) для совместного использования местоположений друг друга в магазине. В другом варианте осуществления у пользователя может иметься опция "вид магазина" по аналогии с видом улиц на картах. Опция 919n вид магазина может отображать изображения/видео вокруг пользователя. Например, если пользователь собирается войти в проход 5, на карте с видом магазина может отображаться вид прохода 5. Кроме того, пользователь может управлять ориентацией карты с использованием навигационных средств 919o и перемещать вид магазина вперед, назад, вправо, влево, а также поворачивать его по часовой стрелке и против часовой стрелки.

На фиг.10А-Е схематически показаны интерфейсы пользователя, иллюстрирующие примеры возможностей приложений для виртуального бумажника в режиме платежа в некоторых вариантах осуществления РРТ. Как показано на фиг.10А, в одном из вариантов осуществления мобильное приложение для бумажника может предоставлять пользователю ряд опций платежа по транзакции в режиме 1010 бумажника. В одном из вариантов осуществления проиллюстрирован один из примеров интерфейса пользователя 1011 для совершения платежей, интерфейс пользователя может ясно указывать сумму 1012 и валюту 1013 транзакцию. Суммой может являться сумма к оплате, а валютой может являться реальная валюта, такая как доллары и евро, а также виртуальная валюта, такая как премиальные баллы. На интерфейсе пользователя также может отчетливо отображаться сумма 1014 транзакции. Пользователь может использовать ярлык 1016 средства для выбора одной или нескольких форм платежа 1017, которые могут включать различные кредитные, дебетовые, подарочные, бонусные и/или предоплаченные карты. У пользователя также может иметься опция частичного и полного платежа премиальными баллами. Например, на графическом индикаторе 1018 интерфейса пользователя показано число доступных баллов, на графическом индикаторе 1019 показано число баллов для использования в счет оплаты причитающейся суммы 234,56, а на графическом индикаторе 1020 показан эквивалент баллов в выбранной валюте (например, долларах США).

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

В одном из вариантов осуществления пользователь может выбирать безопасную авторизацию транзакции с помощью кнопки 1022 маскирования с целью эффективного маскирования или сохранения анонимности определенной (например, предварительно сконфигурированных) или всей идентифицирующая информация, в результате чего при выборе пользователем кнопку 1021 авторизация транзакция осуществляется в безопасном и анонимном режиме. В другом варианте осуществления пользователь может выбирать кнопку 1021 оплаты с использованием стандартных методов авторизации при обработке транзакций. В еще одном варианте осуществления при выборе пользователем кнопки 1023 социальные сети сообщение, касающееся транзакции, может передаваться одной или нескольким социальным сетям (установленным пользователям), которые могут сообщать или объявлять о транзакции покупки на социальном форуме, например, путем вывешивания или в форме твита. В одном из вариантов осуществления пользователь может выбирать опцию 1023 обработки платежей через социальные сети. Индикатор 1024 может отображать выполнение процесса авторизации и передачи данных, совместно используемых в социальных сетях.

В другом варианте осуществления для некоторых покупок, таких как товары, отпускаемые по рецепту, может активироваться режим 1025 ограниченных платежей. Этот режим может активироваться в соответствии с правилами, установленными эмитентами, страховыми компаниями, торговцами, процессором платежей и/или другими лицами с целью облегчения обработки покупок специализированных товаров и услуг. В этом режиме пользователь может прокручивать список форм платежей 1026 под ярлыком средства с целью выбора специализированных счетов, таких как счет с гибким расходованием средств (FSA) 1027, сберегательный счет здоровья (HAS), и/или т.п. и сумм для дебетования выбранных счетов. В одном из вариантов осуществления при обработке в таком режиме 1025 ограниченных платежей может блокироваться совместное использование данных о покупке в социальных сетях.

В одном из вариантов осуществления мобильное приложение для бумажника может способствовать внесению средств посредством интерфейса пользователя 1028. Например, не имеющий работы пользователь может получать пособие 1029 по безработице посредством мобильного приложения для бумажника. В одном из вариантов осуществления лицо, обеспечивающее средства, также может конфигурировать правила использования средств, как показано в сообщении 1030 индикатора обработки. Бумажник может заранее считывать и применять правила и может отклонять любые покупки на пособие по безработице, которые не отвечают критериям, установленным правилами. Примеры критериев могут включать, например, код категории торговца (МСС), время транзакции, местоположение транзакции и/или т.п. В качестве примера, транзакция с торговцем бакалейными товарами, имеющим МСС 5411, может быть одобрена, а транзакция торговцем в баре, имеющим МСС 5813, может быть отклонена.

Как показано на фиг.10Б, в одном из вариантов осуществления мобильное приложение для бумажника может способствовать оптимизации динамических платежей на основании таких факторов, как в том числе местоположение пользователя, предпочтения и предпочтительная валюта. Например, когда пользователь находится в США, индикатор 1031 страны может отображать флаг США и устанавливать значение 1033 для валюты США. В одном из дополнительных вариантов осуществления мобильное приложение для бумажника может автоматически изменять порядок следования форм платежа 1035 в списке, чтобы отразить популярность или приемлемость различных форме платежа. В одном из вариантов осуществления порядок следования может отражать предпочтения пользователя, которые не могут быть изменены мобильным приложением для бумажника.

Аналогичным образом, когда немецкий пользователь использует бумажник в Германии, интерфейс пользователя мобильного приложения для бумажника может динамически обновляться с целью отображения страны использования 1032 и валюты 1034. В одном из дополнительных вариантов осуществления приложение для бумажника может изменять порядок, в котором перечисляются различные формы платежа 1036, в зависимости от степени их приемлемости в стране. Разумеется, что порядок перечисления этих форм платежа может изменяться пользователем в соответствии с его предпочтениями.

Как показано на фиг.10В, в одном из вариантов осуществления ярлык 1037 получатель на интерфейсе пользователя мобильного приложения для бумажника может облегчать пользователю выбор одного или нескольких получателей средств, выбранных с помощью ярлыка средства. В одном из вариантов осуществления интерфейс пользователя может отображать список всех получателей 1038, с которыми пользователь ранее совершал транзакции и которые доступы для совершения транзакций. Затем пользователь может выбирать одного или нескольких получателей. Получателем 1038 могут являться крупные торговцы, например, Amazon.com Inc., и частные лица, например, Jane P. Doe. Рядом с именем каждого получателя может отображаться список приемлемых для получателя режимов платежа режимов платежа. В одном из вариантов осуществления пользователь может выбирать Jane P. Doe в качестве получателя 1039 платежа. После того, как выбор сделан, интерфейс пользователя может отображать дополнительную идентифицирующую информацию о получателе.

Как показано на фиг.10Г, в одном из вариантов осуществления ярлык 1040 режим может облегчать выбор приемлемого для получателя режима платежа. Для выбора может быть доступно несколько режимов платежа. Их примеры включают, в том числе систему BlueTooth 1041, беспроводную связь 1042, моментальные снимки посредством получаемого пользователем кода 1043 QR, защищенную микросхему 1044, TWITTER 1045, ближнюю связь (NFC) 1046, сотовую связь 1047, моментальные снимки посредством предоставляемого пользователем кода 1048 QR, USB 1049 и FACEBOOK 1050. В одном из вариантов осуществления пользователем могут выбираться только режимы платежа, приемлемые для получателя. Другие неприемлемые режима платежа могут блокироваться.

Как показано на фиг.10Д, в одном из вариантов осуществления ярлык 1051 предложения в реальном времени отображает предложения для выбора пользователем, которые могут иметь отношение к наименованиям в корзине пользователя для виртуальных покупок. Пользователь может выбирать одно или несколько предложений из списка доступных предложений 1052. В одном из вариантов осуществления некоторые предложения могут быть объединены, а другие не могут быть объединены. При выборе пользователем предложения, которое не может быть объединено с другим предложением, невыбранное предложение может быть заблокировано. В одном из дополнительных вариантов осуществления предложения, рекомендуемые рекомендательным механизмом приложения для бумажника, могут указываться индикатором, таким как индикатор, обозначенный позицией 1053. В одном из дополнительных вариантов осуществления пользователь может прочитать подробности предложения, развернув окно 1054 предложения на интерфейсе пользователя.

Как показано на фиг.10Е, в одном из вариантов осуществления ярлык 1055 социальные сети может облегчать интегрирование приложения для бумажника с социальными каналами 1056. В одном из вариантов осуществления пользователь может выбирать один или несколько социальных каналов 1056 и может подписываться на выбранный социальный канал из приложения для бумажника путем предоставления имени пользователя социального канала и пароля 1057 приложению для бумажника и осуществлять подписку на шаге 1058. Затем пользователь может использовать социальную кнопку 1059 для отправки или получения денег через интегрированные социальные каналы. В одном из дополнительных вариантов осуществления пользователь может отправлять совместно используемые в социальных сетях данные, такие как информация о покупке или ссылки по интегрированным социальным каналам. В другом варианте осуществления предоставляемые пользователем регистрационные сведения могут позволять РРТ заниматься анализом с целью перехвата.

На фиг.11 схематически показан интерфейс пользователя, иллюстрирующий примеры возможностей приложений для виртуального бумажника в режиме предыстории, в некоторых вариантах осуществления РРТ. В одном из вариантов осуществления пользователь может выбирать режим 1110 предыстории с целью просмотра предыстории предыдущих покупок и выполнения различных действий с этими предыдущими покупками. Например, пользователь может вводить идентифицирующую торговца информацию, такую как имя, продукт, МСС и/или т.п. на панели 1111 поиска. В другом варианте осуществления пользователь может использовать управляемый голосом поиск путем клика по иконке 1114 микрофона. Приложение для бумажника может запрашивать в областях памяти в мобильном устройстве или где-либо еще (например, в одной или нескольких базах данных и/или таблицах на удалении от мобильного устройства) транзакции с соответствующими ключевыми словами. Затем интерфейс пользователя может отображать результаты запроса, например, транзакцию 1115. интерфейс пользователя также может определять дату 1112 транзакции, торговцев и наименования 1113, относящиеся к транзакции, штриховой код квитанции, подтверждающей совершение транзакции, сумму транзакции и любую другую релевантную информацию.

В одном из вариантов осуществления пользователь может выбирать транзакцию, например транзакцию 1115, чтобы просмотреть ее подробности. Например, пользователь может просматривать подробности наименований, относящихся к транзакции, и суммы 1116 по каждому наименованию. В одном из дополнительных вариантов осуществления пользователь может выбирать опцию 1117 просмотра действий 1118, которые пользователь может предпринять в отношении транзакции или наименований, относящихся к транзакции. Например, пользователь может добавлять фото к транзакции (например, изображение пользователя и купленный им iPad). Если пользователь ранее совместно использовал данные покупки посредством социальных каналов, в одном из дополнительных вариантов осуществления может генерироваться сообщение, содержащее фото, и отправляться по социальным каналам для публикации. В одном из вариантов осуществления любое совместное использование может являться необязательным, и пользователь, который совместно не использовал данные покупки посредством социальных каналов, все же может совместно использовать фото посредством одного или нескольких социальных каналов по своему выбору непосредственно из режима предыстории приложения для бумажника. В другом варианте осуществления пользователь может относить транзакцию к определенной группе, такой как расходы компании, домашние расходы, командировочные расходы или к другим категориям, установленным пользователем. Такое группирование может облегчать годовой учет расходов, представление отчетов о рабочих расходах, требований возврата налога на добавленную стоимость (НДС), учет личных расходов и/или т.п. В еще одном варианте осуществления пользователь может купить одно или несколько наименований по транзакции. Затем пользователь может совершить транзакцию без обращения к каталогу или сайту торговца, чтобы найти наименования. В одном из дополнительных вариантов осуществления пользователь также может помещать в корзину для виртуальных покупок одно или несколько наименований для приобретения впоследствии.

В другом варианте осуществления режим предыстории может обеспечивать возможности получения и отображения рейтингов 1119 наименований по транзакции. Источником рейтингов может являться пользователь, друзья пользователя (например, из социальных каналов, контактов и т.д.), сводные отзывы из Интернета и/или т.п. В некоторых вариантах осуществления интерфейс пользователя также может разрешать пользователю вывешивать сообщения для других пользователей социальных каналов (например, TWITTER или FACEBOOK). Например, в области 1120 дисплея представлен обмен сообщениями в сети FACEBOOK между двумя пользователями. В одном из вариантов осуществления пользователь может совместно использовать ссылку посредством сообщения 1121. Выбор такого сообщения, в которое включена ссылка на продукт, может позволять пользователю просматривать описание продукта и/или приобретать продукт непосредственно из режима предыстории.

В одном из вариантов осуществления режим предыстории также может предусматривать возможности экспорта квитанций. Во всплывающем 1122 окне экспорта квитанций может предлагаться ряд опций экспорта квитанций по предыдущим транзакциям. Например, пользователь может использовать одну или несколько из опций 1125, включающих сохранение (в локальной памяти мобильного устройства, сервере, счете на основе облачных вычислений и/или т.п.), листинг на принтере, передачу по факсу, электронной почте и/или т.п. Пользователь может использовать свою адресную книгу 1123 для поиска адреса электронной почты или номера факса для экспорта. Пользователь также может выбирать опции 1124 формата для экспорта квитанций. Примеры опций форма могут включать без ограничения текстовой файл (с расширениями .doc, .txt, .rtf, iif и т.д.), электронную таблицу (с расширениями .csv, .xls и т.д.), файл изображений (с расширениями .jpg, .tff, .png и т.д.), формат переносимых документов (с расширением .pdf), язык PostSript (с расширением .ps) и/или т.п. Затем пользователь может щелкнуть по кнопке 1127 экспорта, чтобы инициировать экспорт квитанций.

На фиг.12А-Д схематически показаны интерфейсы пользователя, иллюстрирующие примеры возможностей приложений для виртуального бумажника в режиме моментальных снимков в некоторых вариантах осуществления РРТ. Как показано на фиг.12А, в одном из вариантов осуществления пользователь может выбирать режим 2110 моментальных снимков для доступа к возможностям моментальных снимков. Режим моментальных снимков позволяет оперировать с любым машиночитаемым представлением данных. Примеры таких данных могут включать линейчатые и двухмерные штриховые коды, такие как универсальный товарный код и QR-коды. Эти коды могут указываться на квитанциях, упаковке и/или т.п. Режим моментальных снимков также позволяет обрабатывать и оперировать с изображениями на квитанциях, товарах, предложениях, кредитных картах или других средствах платежа и/или т.п. На фиг.12А проиллюстрирован один из примеров интерфейса пользователя в режиме моментальных снимков. Пользователь может использовать свой мобильный телефон, чтобы получить изображение кода QR-кода 1216 и/или штрихового кода 1214. В одном из вариантов осуществления предусмотрены панель 1213 и рамка 1215, которые могут облегчать пользователю получение надлежащих моментальных снимков кодов. Например, код 1216 не входит целиком в показанную рамку 1215. По существу, такое изображение кода может являться неразличимым, поскольку информация, содержащаяся в коде, может оказаться неполной. Соответственно, в сообщение на панели 1213 указано, что поиск кода в режиме моментальных снимков продолжается. Когда код 1216 целиком находится в рамке 1215, сообщение может быть заменено, например, сообщением "код найден". В одном из вариантов осуществления после того, как код найден, пользователь может инициировать захват кода с использованием камеры мобильного устройства. В другом варианте осуществления, режим моментальных снимков может предусматривать автоматическое получение моментального снимка кода с использованием камеры мобильного устройства.

Как показано на фиг.12Б, в одном из вариантов осуществления режим моментальных снимков может облегчать перераспределение платежа после транзакции. Например, пользователь может приобрести бакалейные товары и отпускаемые по рецепту товары у розничного торговца Acme Supermarket. Пользователь может по невнимательности или для удобства расчетов, например, воспользоваться своей картой Visa, чтобы оплатить как бакалейные товары, так и отпускаемые по рецепту товары. Тем не менее, у пользователя может иметься счет FSA, который может использоваться для оплаты отпускаемых по рецепту товаров и обеспечивать налоговые льготы для пользователя. В таком случае пользователь может использовать режим моментальных снимков, чтобы инициировать перераспределение платежа по транзакции.

Как показано, пользователь может ввести элемент поиска (например, счет) на панели 1221 поиска. Затем пользователь может использовать ярлык 1222, чтобы указать квитанцию 1223, платеж по которой пользователь желает перераспределить. В качестве альтернативы, пользователь может непосредственно получить моментальный снимок штрихового кода на квитанции с целью генерирования и отображения квитанции 1223 в режиме моментальных снимков с использованием информации, содержащейся в штриховом коде. Теперь пользователь может осуществить перераспределение 1225. В некоторых вариантах осуществления пользователь также может оспорить транзакцию 1224 или архивировать квитанцию 1226.

При выборе кнопки 1225 перераспределения в одном из вариантов осуществления приложение для бумажника может выполнять оптическое распознавание символов (OCR) квитанции. Затем может быть проверено каждое из наименований в квитанции, чтобы определить, каким средством платежа, или с какого счета может быть оплачено одно или несколько наименований с целью получения налоговых или других льгот, таких как возврат денег наличными, премиальные баллы и т.д. В этом примере предусмотрена налоговая льгота, если отпускаемое по рецепту лекарство, оплаченное пользователем картой Visa, будет оплачено с его счета FSA. Затем приложение для бумажника может осуществить перераспределение платежа в качестве обратной связи. Процесс перераспределения может включать установление связи бумажником с процессором платежей с целью зачисления суммы, причитающейся за отпускаемое по рецепту лекарство, на карту Visa и списание такой же суммы со счета to FSA пользователя. В одном из альтернативных вариантов осуществления процессор платежей (например, Visa или MasterCard) может получать квитанцию и выполнять оптическое распознавание ее символов, определять наименования и счета для перераспределения платежа и выполнять перераспределение. В одном из вариантов осуществления приложение для бумажника может предлагать пользователю подтвердить перераспределение платежа по выбранным наименованиям на другой счет платежей. После завершения процесса перераспределения может генерироваться квитанция 1227. Как было описано, на квитанции указано, что некоторые платежи были перенесены со счета карты Visa на счет FSA.

Как показано на фиг.12В, в одном из вариантов осуществления режим моментальных снимков может облегчать платеж посредством платежного кода, такого как штриховой код или QR-коды. Например, пользователь может получать моментальный снимок QR-кода транзакции, которая еще не завершена. QR-код может отображаться в торговом терминале торговца, на веб-сайте или в веб-приложении, и в нем может быть закодирована информация, идентифицирующая наименования для приобретения, данные торговца и другая существенная информация. При получении пользователем моментального снимка, такого как снимок QR-кода в режиме моментальных снимков может декодироваться содержащаяся в QR-коде информация, которая может использоваться для генерирования квитанции 1232. После того как QR-код идентифицирован, на навигационной панели 1231 может указываться, что платежный код идентифицирован. Теперь пользователь может иметь возможность пополнять корзину 1233 для виртуальных покупок, осуществлять платеж с использованием стандартного счета 1234 платежей или бумажника 1235.

В одном из вариантов осуществления пользователь может выбирать оплату с использованием стандартного счета 1234. Затем приложение для бумажника может использовать стандартный способ платежа, в данном примере бумажник, чтоб завершить транзакцию покупки. После завершения транзакции может автоматически генерироваться квитанция для подтверждения покупки, интерфейс пользователя также может обновляться с целью обеспечения других возможностей оперирования с завершенной транзакцией. Примеры возможностей включают социальную опцию 1237 совместного использования информации о покупке, опцию 1238 перераспределения, описанную со ссылкой на фиг.12Б, и опцию 1239 архивирования с целью сохранения квитанции.

Как показано на фиг.12Г, в одном из вариантов осуществления режим моментальных снимков также может облегчать идентификацию, применение и сохранение предложений для использования в будущем. Например, в одном из вариантов осуществления пользователь может получать моментальный снимок кода 1241 предложения (например, штрихового кода, QR-кода и/или т.п.). Затем приложение для бумажника может генерировать текст 1242 предложения на основании информации, закодированной в коде предложения. Пользователь может выполнять ряд действий с кодом предложения. Например, пользователь может использовать кнопку 1243 поиска всех торговцев, принимающих код предложения, расположенных поблизости торговцев, принимающих код предложения, продуктов, соответствующих коду предложения, и/или т.п. Пользователь также может применять код предложения к наименованиям, находящимся в данный момент в корзине для виртуальных покупок, с использованием кнопки 1244 пополнения корзины для виртуальных покупок. Кроме того, пользователь также может сохранять предложение для использования в будущем с использованием кнопки 1245 сохранения.

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

Как показано на фиг.12Д, в одном из вариантов осуществления в режиме моментальных снимков также могут предлагаться средства добавления источника финансирования к приложению для бумажника. В одном из вариантов осуществления платежная карта, такая как кредитная карта, дебетовая карта, предварительно оплаченная карта, смарт-карта и другие счета платежей могут иметь соответствующий код, такой как штриховой код или QR-код. В таком коде может быть закодирована информация о платежной карте, включая без ограничения имя, адрес, тип платежной карты, подробности карточного счета платежей, остаток, лимит расходов, премиальный остаток и/или т.п. В одном из вариантов осуществления код может находиться на лицевой поверхности физической платежной карты. В другом варианте осуществления код может быть получен путем доступа к соответствующему интерактивному счету или другому защищенному местоположению. В еще одном варианте осуществления код может содержаться в письме, сопровождающем платежную карту. В одном из вариантов осуществления пользователь, может получать моментальный снимок кода. Приложение для бумажника может идентифицировать платежную карту 1251 и отображать текстовую информацию 1252, закодированную в платежной карте. Затем пользователь может проверять информацию 1252 путем выбора кнопки 1253 проверки. В одном из вариантов осуществления проверка может включать установление связи с эмитентом платежной карты с целью подтверждения декодированной информации 1252 и любой другой существенной информации. В одном из вариантов осуществления пользователь может добавлять платежную карту к бумажнику путем выбора кнопки 1254 добавления к бумажнику. В результате команды добавления платежной карты к бумажнику платежная карта может отображаться как одна из форм платежа под ярлыком 1016 средства, показанном на фиг.10А. Пользователь также может аннулировать добавление платежной карты в качестве источника финансирования путем выбора клавиши 1255 аннулирования. После того, как платежная карта добавлена к бумажнику, интерфейс пользователя может быть обновлен, чтобы указать, что добавление завершено посредством уведомляющего дисплея 1256. Затем пользователь может осуществить доступ к бумажнику 1257, чтобы начать использование добавленной платежной карты в качестве источника финансирования.

На фиг.13 схематически показан интерфейс пользователя, иллюстрирующий примеры возможностей приложений для виртуального бумажника в режиме предложений в некоторых вариантах осуществления РРТ. В некоторых вариантах осуществления РРТ может разрешать пользователю искать предложения товаров и/или услуг внутри мобильного приложения для виртуального бумажника. Например, пользователь может вводить текст в элемент 1311 графического интерфейса пользователя (ГИП) или отдавать речевые команды путем активации элемента 1312 ГИП и произнесения команд в устройство. В некоторых вариантах осуществления РРТ может предоставлять предложения на основании предыдущего поведения пользователя, демографических данных, текущего местоположения, текущего выбора корзины для виртуальных покупок или наименований и/или т.п. Например, если пользователь находится в традиционном магазине или на веб-сайте электронных продаж и покидает (виртуальный) магазин, торговец может пожелать сделать более привлекательное предложение, чтобы побудить пользователя вернуться в (виртуальный) магазин. Торговец может сделать такое предложение 1313. Например, предложение может предусматривать скидку и может иметь ограниченный срок действия. В некоторых вариантах осуществления другие пользователи могут предлагать подарки (например, 1314) пользователю, которые пользователь может выкупать. В некоторых вариантах осуществления в разделе предложений могут содержаться уведомления о платежах, причитающихся другим пользователям (например, 1315). В некоторых вариантах осуществления в разделе предложений могут содержаться уведомления о платежах, причитающихся с других пользователей (например, 1316). Например, могут указываться средства, подлежащие получению от других приложений (например, почта, календарь, задачи, заметки, программы-напоминания, предупреждение и т.д.), или пользователь может вручную вводить их в приложение для виртуального бумажника. В некоторых вариантах осуществления в разделе предложений могут содержаться предложения торговцев, участвующих в РРТ, например, 1317-1319, 1320. Иногда эти предложения могут группироваться с использованием сочетания участвующих торговцев, например, 1317. В некоторых вариантах осуществления РРТ может делать предложения пользователя, исходя из использования ими конкретных форм платежа в приложении для виртуального бумажника, например, 1320.

На фиг.14А-Б схематически показаны интерфейсы пользователя, иллюстрирующие примеры возможностей приложений для виртуального бумажника в защищенном и конфиденциальном режиме в некоторых вариантах осуществления РРТ. Как показано на фиг.14А, в некоторых вариантах осуществления пользователь может быть способен просматривать и/или изменять профиль пользователя и/или установочные параметры пользователя, например, путем активации элемента интерфейса пользователя. Например, пользователь может быть способен просматривать/изменять имя пользователя (например, 1411А-Б), номер счета (например, 1412А-Б), код защиты доступа пользователя (например, 1413-b), ПИН-код пользователя (например, 1414-b), адрес пользователя (например, 1415-b), номер социального страхования пользователя (например, 1416-b), текущее местоположение устройства согласно данным GPS (например, 1417-b), счет пользователя у торговца, в магазине которого в данный момент находится пользователь (например, 1418-b), поощрительные счета пользователя (например, 1419-b), и/или т.п. В некоторых вариантах осуществления пользователь может быть способен выбирать, какие поля данных и соответствующие значения следует передавать для совершения транзакции покупки, и тем самым обеспечивать улучшенную защиту данных. Например, в примере, проиллюстрированном на фиг.14А, пользователь выбрал имя 1411a, номер счета 1412a, код 1413a в системе защиты, ID 1418a счета у торговца и ID 1419a поощрительного счета в качестве полей для передачи в составе уведомления для обработки транзакции покупки. В некоторых вариантах осуществления пользователь может переключать поля и/или значения данных, передаваемые в составе уведомления для обработки транзакции покупки. В некоторых вариантах осуществления приложение может обеспечивать множество экранов полей данных и/или соответствующих значений, хранящихся для пользователя, с целью выбора для передачи в составе заказа на покупку. В некоторых вариантах осуществления приложение может обеспечивать РРТ с указанием местоположения пользователя согласно данным GPS. На основании местоположения пользователя согласно данным GPS РРТ может определять контекст пользователя (например, находится ли пользователь в магазине, на приеме у врача, в больнице, в почтовом отделении и т.д.). На основании контекста пользователя приложение может представлять пользователю соответствующие поля, из которых пользователь может выбирать поля и/или значения для передачи в составе заказа на покупку.

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

Как показано на фиг.14Б, в некоторых вариантах осуществления приложение, выполняемое в устройстве пользователя, может предоставлять возможность "VerifyChat" предотвращения мошенничества. Например, РРТ может обнаруживать необычную и/или подозрительную транзакцию. РРТ может использовать возможность VerifyChat для связи с пользователем и проверки подлинности инициатора транзакции покупки. В различных вариантах осуществления РРТ может передавать сообщение электронной почты, текстовые (SMS) сообщения, сообщения Facebook®, Twitter™, текстовый диалог в реальном времени, речевой диалог в реальном времени, видеодиалог в реальном времени (например, Apple FaceTime) и/или т.п. для связи с пользователем. Например, РРТ может инициировать видеозапрос пользователя, например, 1421. Например, от пользователя может потребоваться представиться посредством видеодиалога в реальном времени, например, 1422. В некоторых вариантах осуществления сотрудник отдела по работе с покупателями, например, 1424, может вручную устанавливать подлинность пользователя с использованием видеоизображения пользователя. В некоторых вариантах осуществления РРТ может использовать распознавание лица, биометрическую и/или подобную идентификацию (например, с использованием методов классификации образов), чтобы устанавливать личность пользователя. В некоторых вариантах осуществления приложение может предоставлять контрольную отметку (например, перекрестие, целевой прямоугольник и т.д.), например, 1423, чтобы пользователь мог использовать видео с целью облегчения автоматического распознания пользователя для РРТ. В некоторых вариантах осуществления пользователь мог не инициировать транзакцию, например, если транзакция является мошеннической. В таких вариантах осуществления пользователь может аннулировать запрос. Затем РРТ может аннулировать транзакцию и/или инициировать процедуру расследования мошенничества от имени пользователя.

В некоторых вариантах осуществления РРТ может использовать процедуру тестового запроса с целью проверки подлинности пользователя, например, 1425. Например, РРТ поддерживать связь с пользователем посредством текстового диалога в реальном времени, SMS-сообщений, электронной почты, сообщений Facebook®, Twitter™ и/или т.п. РРТ может задавать вопрос пользователю, например, 1426. Приложение может обеспечивать пользователя элементом(-ами) ввода (например, виртуальной клавиатурой 1428) для ответа на вопрос, заданный РРТ. В некоторых вариантах осуществления вопрос может произвольным образом автоматически выбираться РРТ; в некоторых вариантах осуществления сотрудник отдела по работе с покупателями может вручную связываться с пользователем. В некоторых вариантах осуществления пользователь мог не инициировать транзакцию, например, если транзакция является мошеннической. В таких вариантах осуществления, пользователь может аннулировать текстовой запрос. Затем РРТ может аннулировать транзакцию и/или инициировать процедуру расследования мошенничества от имени пользователя.

Контроллер РРТ

На фиг.15 проиллюстрирована блок-схема контроллера 1501 РРТ. В этом варианте осуществления контроллер 1501 РРТ может служить для накопления, обработки, хранения, поиска, обслуживания, идентификации, отдачи команд, генерирования, согласования и/или облегчения взаимодействий с компьютером посредством различных технологий и/или других связанных данных.

Обычно для облегчения обработки информации пользователи, которыми могут являться люди и/или другие системы, могут использовать системы на основе информационных технологий (например, компьютеры). В свою очередь, для обработки информации в компьютерах применяются процессоры; такие процессоры 1503 могут именоваться центральными процессорами (ЦП). Одна из форм процессора именуется микропроцессором. В ЦП используются схемы связи для передачи закодированных двоичных сигналов, действующих как команды, обеспечивающие различные операции. Эти команды могут являться оперативными командами и/или командами, содержащими и/или ссылающимися на другие команды и данные в различных областях памяти 1529 (например, регистрах, кэш-памяти, оперативном запоминающем устройстве и т.д.), доступных для процессора в целях обработки. Такие команды связи могут храниться и/или передаваться группами (например, группами команд) в виде программ и/или компонентов данных для облегчения желаемых операций. Эти хранящиеся коды команд, например, программы могут использовать компоненты схемы ЦП и другие компоненты системной и/или материнской платы для выполнения желаемых операций. Программой одного из типов является операционная система компьютера, которая может выполняться ЦП в компьютере; операционная система обеспечивает и облегчает доступ и пользователей к компьютерным информационным технологиям и ресурсам и работу с ними. Некоторые ресурсы, которые могут использоваться в системе на основе информационных технологий, включают: механизмы ввода и вывода, посредством которых данные могут вводиться в компьютер и выводиться из него; память, в которой могут сохраняться данные; и процессоры, которые могут обрабатывать данные. Эти системы на основе информационных технологий могут использоваться для сбора данных с целью последующей выборки, анализа и обращения, что может облегчаться посредством базы данных. Эти системы на основе информационных технологий обеспечивают сопряжения, которые позволяют пользователям получать доступ к различным компонентами системы и работать с ними.

В одном из вариантов осуществления контроллер 1501 РРТ может быть подсоединен и/или поддерживать связь с объектами, включающими без ограничения одного или нескольких пользователей пользовательских устройств 1511 ввода; периферийные устройства 1512; необязательный криптографическое процессорное устройство 1528; и/или сеть 1513 связи. Например, контроллер 1501 РРТ может быть подсоединен и/или поддерживать связь с пользователями клиентского устройства(-в), которые включают без ограничения персональный компьютер(-ы), сервер(-ы) и/или мобильное устройство(-а) различного рода, включая без ограничения сотовый телефон(-ы), смартфон(-ы) (например, iPhone®, Blackberry®, телефоны на основе операционной системы Android и т.д.), планшетный компьютер(-ы) (например, Apple iPad™, HP Slate™, Motorola Xoom™ и т.д.), устройство(-а) чтения электронных книг (например, Amazon Kindle™, Nook™ eReader компании Barnes and Noble и т.д.), портативный компьютер(-ы), ноутбук(-и), нетбук(-и), игровую консоль(-и) (например, ХВОХ Live™, Nintendo® DS, Sony PlayStation® Portable и т.д.), портативный сканер(-ы) и/или т.п.

Сети обычно представляют собой взаимосвязь и взаимодействие клиентов, серверов и промежуточных узлов в топологии графов. Следует отметить, что термин "сервер", используемый в настоящей заявке, относится в целом к компьютеру, другому устройству, программе или их сочетанию для обработки и ответа на запросы удаленных пользователей по сети сеть связи. Серверы предоставляют свою информацию запрашивающими "клиентам". Используемый термин "клиент" относится в целом к компьютеру, программе, другому устройству, пользователю и/или их сочетанию, способному обрабатывать и передавать запросы и получать и обрабатывать любые ответы от серверов по сети связи. Компьютер, другое устройство или их сочетание для облегчения обработки данных и запросов и/или передачи данных от пользователя-источника пользователю-адресату обычно именуется "узлом". Сети в целом облегчают передачу данных от источников адресатам. Узел, конкретной задачей которого является облегчение передачи данных от источника адресата, обычно именуется "маршрутизатором". Существуют сети множеств типов, такие как локальные вычислительные сети (ЛВС), пикосети, глобальные вычислительные сети (ГВС), беспроводные локальные сети (БЛС) и т.д. Например, общеизвестно, что сеть Интернет представляет собой взаимосвязь множества сетей, посредством которых удаленные клиенты и серверы могут получать доступ и взаимодействовать друг с другом.

Контроллер 1501 РРТ может быть реализован на основе компьютерных систем, которые могут содержать без ограничения такие компоненты, как компьютерная система 1502, соединенная с памятью 1529.

Компьютерная система

Компьютерная система 1502 может содержать тактовый генератор 1530, центральный процессор (ЦП и/или процессор(-ы) (эти термины используются взаимозаменяемо по всему описанию, если не указано иное)) 1503, память 1529 (например, постоянное запоминающее устройство (ПЗУ) 1506, оперативное запоминающее устройство (ОЗУ) 1505 и т.д.) и/или интерфейсную шину 1507, которые чаще всего, но необязательно взаимосвязаны и/или поддерживают связь посредством системной шины 1504 в одной или нескольких (материнских) платах 1502, имеющих проводящие и/или иные пути в передающих схемах, по которым могут распространяться команды (например, закодированные двоичные сигналы) для осуществления связи, выполнения операций, запоминания и т.д. Компьютерная система может быть необязательно соединена с внутренним источником 1586 питания; например, источник питания может необязательно являться внутренним. С системной шиной необязательно может быть соединен криптографический процессор 1526 и/или приемопередатчики (например, IC) 1574. В другом варианте осуществления криптографический процессор и/или приемопередатчики могут быть подсоединены как внутренние и/или внешние периферийные устройства 1512 посредством интерфейсной шины ввода-вывода. В свою очередь, приемопередатчики могут соединены с антенной(-ами) 1575, что обеспечивает беспроводную передачу и прием данных согласно различным протоколам связи и/или протоколам для сенсорных сетей; например антенна(-ы) могут быть соединены с приемопередающей микросхемой Texas Instruments WiLink WL1283 (например, обеспечивающей связь стандартов 802.11n, Bluetooth 3.0, ЧМ, системы глобального позиционирования (GPS) (что позволяет контроллеру РРТ определять его местоположение)); приемопередающей микросхемой Broadcom BCM4329FKUBG (например, обеспечивающей связь стандартов 802.11n, Bluetooth 2.1 + EDR, ЧМ и т.д.); приемной микросхемой Broadcom BCM4750IUB8 (например, GPS); микросхемой Infineon Technologies X-Gold 618-РМВ9800 (например, обеспечивающей связь стандартов 2G/3G HSDPA/HSUPA); и/или т.п. Системный тактовый генератор обычно имеет кварцевый генератор и генерирует базовый сигнал посредством путей в схеме компьютерной системы. Обычно тактовый генератор связан с системной шиной и различными умножителями, которые повышают или понижают базовую рабочую частоту для других компонентов, взаимосвязанных в компьютерной системе. Тактовый генератор и различные компоненты компьютерной системы возбуждают несущие информацию сигналы по всей системе. Такая передача и прием несущих информацию команд по всей компьютерной системе может обычно именоваться связью. Эти коммуникативные команды могут дополнительно передаваться, приниматься и являться причиной обратной и/или ответной связи за пределами настоящей компьютерной системы с сетями связи, устройствами ввода, другими компьютерными системами, периферийными устройствами и/или т.п. Разумеется, что любые из перечисленных компонентов могут быть соединены непосредственно друг с другом, с ЦП и/или организованы в виде множества разновидностей, примером применения которых являются различные компьютерным системы.

ЦП представляет собой, по меньшей мере, один высокоскоростной процессор данных, способный выполнять компоненты программ для выполнения запросов пользователя и/или генерированных системой запросов. Часто в сами процессоры входят различные специализированные блоки обработки, включая без ограничения встроенные системные контроллеры (шины), блоки управления распределением памяти, блоки с плавающей точкой и даже специализированные субблоки обработки, такие как блоки обработки графики, блоки цифровой обработки сигналов и/или т.п. Кроме того, процессоры могут содержать внутреннюю адресуемую память с быстрой выборкой и могут быть способны обеспечивать отображение и адресацию памяти 1529 вне самого процессора; внутреняя память может включать без ограничения быстрые регистры, различные уровни кэш-памяти (например, уровни 1, 2, 3 и т.д.), ОЗУ и т.д. Процессор может осуществлять доступ к этой памяти путем использования адресного пространства памяти, доступного посредством адреса команды, который процессор способен конструировать и декодировать, что позволяет ему получать доступ к пути в схеме до конкретного адресного пространства памяти, имеющего состояние памяти. ЦП может представлять собой микропроцессор, такой как: Athlon, Duron и/или Opteron компании AMD; прикладные, встроенные и защищенные процессоры компании; DragonBall и PowerPC производства компаний IBM и/или Motorola; процессор Cell производства компаний IBM и Sony; Celeron, Core (2) Duo, Itanium, Pentium, Xeon и/или XScale компании Intel; и/или тому подобные процессоры. ЦП взаимодействует с памятью посредством проходящих по проводящим и/или передающим путям (например, (печатным) электронным и/или оптическим схемам) команд выполнения хранящихся команд (т.е. программного кода) в соответствии с традиционными методами обработки данных. Такое прохождение команд облегчает связь внутри контроллера РРТ и за его пределами посредством различных интерфейсов. Если требованиями к обработке диктуется более высокая скорость и/или пропускная способность, также могут применяться распределенные процессоры (например, распределенные РРТ), архитектуры на основе мэйнфреймов, многоядерных, параллельных и/или суперкомпьютеров. В качестве альтернативы, если требованиями к размещению диктуется более высокая транспортабельность, могут примениться имеющие меньшие размеры персональные цифровые секретари (PDA).

В зависимости от конкретной реализации возможности РРТ могут обеспечиваться посредством микроконтроллера, такого как микроконтроллер R8051XC2 компании CAST; MCS 51 (т.е. микроконтроллера 8051) компании Intel; и/или т.п. Кроме того, реализация некоторых возможностей РРТ может достигаться за счет встроенных компонентов, таких как специализированная интегральная схема (ASIC), блок цифровой обработки сигналов (DSP), программируемая вентильная матрица (FPGA), и/или тому подобная встроенная технология. Например, любой из наборов (распределенных или иных) компонентов и/или возможностей РРТ может быть реализован посредством микропроцессора и/или встроенных компонентов; например, посредством ASIC, сопроцессора, DSP, FPGA и/или т.п. В качестве альтернативы, некоторые варианты РРТ могут быть реализованы с использованием встроенных компонентов, которые сконфигурированы и используются с целью обеспечения разнообразных возможностей или обработки сигналов.

В зависимости от конкретной реализации встроенные компоненты могут включать программно-реализованные решения, аппаратно-реализованные решения и/или определенной сочетание программно- и аппаратно-реализованных решений. Например, рассмотренные возможности РРТ могут быть реализованы посредством FPGA, которые представляют собой полупроводниковые устройства, содержащие программируемые логические компоненты, называемые "логическими блоками", и программируемые межсоединения, такие как высокопроизводительная FPGA серии Virtex и/или недорогой серии Spartan компании Xilinx. Логические блоки и межсоединения могут программироваться пользователем или разработчиком после изготовления FPGA с целью реализации любым из возможностей РРТ. Определенная иерархия программируемых межсоединений обеспечивает взаимное соединение логических блоков в соответствии с требованиями разработчика/администратора системы РРТ, несколько по аналогии с однокристальным программируемым макетом. Логические блоки FPGA могут быть запрограммированы на выполнение функции основных логических элементов, таких как И и ИЛИ, или более сложных комбинационных функций, таких как функции декодеров или простые математические функции. В большинстве FPGA логические блоки также содержат запоминающие элементы, которыми могут являться простые триггерные запоминающие устройства или более сложные блоки памяти. В некоторых случаях РРТ могут быть разработаны на основе обычных FPGA, а затем перенесены в постоянную версию, более походящую на реализации ASIC. В альтернативных или скоординированных реализациях возможности контроллера РРТ могут переноситься в окончательную ASIC вместо или помимо FPGA. В зависимости от реализации все упомянутые встроенные компоненты и микропроцессоры могут рассматриваться как ЦП и/или процессор РРТ.

Источник питания

Источник 1586 питания может представлять собой любое устройство стандартной формы для питания небольших электронных устройств на основе печатных плат, такое как следующие элементы питания: щелочные, литий-гидридные, ионно-литиевые, литий-полимерные, никель-кадмиевые, солнечные элементы и/или т.п. Также могут использоваться источник питания переменного или постоянного тока других типов. В случае солнечных элементов в одном из вариантов осуществления в корпусе предусмотрено отверстие, через которое солнечный элемент может улавливать световую энергию. Элемент 1586 питания соединен, по меньшей мере, с одним из взаимосвязанных последующих компонентов РРТ и подает электрический ток во все последующие компоненты. В одном из примеров источник 1586 питания соединен с компонентом 1504 системной шины. В одном из альтернативных вариантов осуществления используется внешний источник 1586 питания посредством соединения через интерфейс 1508 ввода-вывода. Например, как данные, так и питание передается по USB и/или шине стандарта IEEE 1394, которая, соответственно, является приемлемым источником питания.

Интерфейсные адаптеры

Интерфейсная шина(-ы) 1507 может принимать сигналы, быть подключена и/или поддерживать связь с рядом интерфейсных адаптеров, традиционно но необязательно в форме адаптерных плат, таких как без ограничения интерфейсы 1508 ввода-вывода, интерфейсы 1509 памяти, сетевые интерфейсы 1510 и/или т.п. С интерфейсной шиной также необязательно могут быть соединены интерфейсы 1527 криптографического процессора. Интерфейсная шина обеспечивает связь интерфейсных адаптеров друг с другом, а также с другими компонентами компьютерной системы. Интерфейсные адаптеры рассчитаны на совместимую интерфейсную шину. Интерфейсные адаптеры традиционно соединены с интерфейсной шиной посредством архитектуры слотов. Могут применяться традиционные архитектуры слотов, включая без ограничения ускоренный графический порт (AGP), шину CardBus, (расширенную) архитектуру шины промышленного стандарта ((E)ISA), микроканальную архитектуру шины (МСА), шину NuBus, (расширенную) архитектуру подключения периферийных компонентов (PCI(Х)), шину PCI Express, стандарт Международной ассоциации производителей плат памяти для персональных компьютеров (PCMCIA) и/или т.п.

Интерфейсы 1509 памяти могут принимать сигналы, быть подключены и/или поддерживать связь с рядом запоминающих устройств, включая без ограничения запоминающие устройства 1514, устройства на съемных дисках и/или т.п. В интерфейсах памяти могут применяться протоколы соединения, включающие без ограничения (пакетный интерфейс) стандарта (Ultra) (Serial) для подключения периферийных устройств для АТ-совместимых компьютеров ((Ultra) (Serial) ATA(PI)), (усовершенствованные) электронные схемы управления встроенным дисководом ((Е)IDE), стандарт Института инженеров по электротехнике и радиоэлектронике (IEEE) 1394, волоконно-оптический канал, интерфейс малых компьютерных систем (SCSI), универсальную последовательную шину (USB) и/или т.п.

Сетевые интерфейсы 1510 могут принимать сигналы, быть подключены и/или поддерживать связь с сетью 1513 связи. Контроллер РРТ доступен по сети 1513 связи посредством удаленных клиентов 1533b (например, компьютеров с веб-браузеров) для пользователей 1533a. В сетевых интерфейсах могут применяться протоколы соединения, включающие без ограничения прямое соединение, локальную сеть Ethernet ("толстую", "тонкую", стандарта 10/100/1000 Base Т с использованием витой пары и/или т.п.), кольцевую сеть с маркерным доступом, беспроволочное соединение, такое как соединение стандарта IEEE 802.11a-x и/или т.п. Если требованиями к обработке диктуется более высокая скорость и/или пропускная способность, также могут применяться распределенные сетевые контроллеры (например, распределенные РРТ), архитектуры для объединения ресурсов, выравнивания нагрузки и/или иного расширения полосы пропускания контроллером РРТ. Сетью связи может являться одно из следующего и/или сочетание следующего: прямая взаимосвязь; сеть Интернет; локальная вычислительная сеть (ЛВС); городская вычислительная сеть (ГВС); экипаж на орбите как узел Интернета (OMNI); защищенное заказное соединение; глобальная вычислительная сеть (ГВС); сеть беспроводной связи (например, с применением таких протоколов, как без ограничения протокол приложений для беспроводной связи (WAP), сервис i-mode и/или т.п.); и/или т.п. Сетевой интерфейс может считаться специализированной формой интерфейса ввода-вывода. Кроме того, для взаимодействия с сетями 1513 связи различных типов может использоваться множество сетевых интерфейсов 1510. Например, может применяться множество сетевых интерфейсов для обеспечения связи по широковещательным сетям, сетям многоадресной и/или одноадресной передачи.

Интерфейсы 1508 ввода-вывода могут принимать сигналы, поддерживать связь и/или быть подключены к пользовательским устройствам 1511 ввода, периферийным устройствам 1512, криптографическим процессорным устройствам 1528 и/или т.п. В интерфейсах 1508 ввода-вывода могут применяться протоколы соединения, включающие без ограничения аудиопротоколы: аналоговый, цифровой, монофонический, RCA, стерео и/или т.п.; протоколы передачи данных: протокол шины настольных компьютеров Apple (ADB), протокол стандарта IEEE 1394a-b, протокол последовательной передачи данных, протокол универсальной последовательной шины (USB); инфракрасный протокол передачи данных; протокол джойстика; протокол клавиатуры; протокол стандарта MIDI; оптический протокол; PC AT; PS/2; протокол параллельной передачи данных; радиопротокол; видеоинтерфейс: протокол шины настольных компьютеров Apple (ADC), BNC, коаксиальный, протокол связи компонентов, протокол передачи композитных видеосигналов, цифровой, цифровой видеоинтерфейс (DVI), интерфейс для мультимедиа высокой четкости (HDMI), RCA, РЧ-антенны, S-Video, VGA и/или т.п.; беспроводные приемопередатчики: стандарта 802.11a/b/g/n/x; стандарта Bluetooth; сотовые (например, стандарта коллективного доступа с кодовым разделением каналов (CDMA), высокоскоростной пакетной передачи (HSPA(+)), высокоскоростной пакетной передачи данных от базовой станции к мобильному телефону (HSDPA), глобальной системы связи с подвижными объектами (GSM), системы с перспективой развития (LTE), WiMax и т.д.); и/или т.п. Одно из типичных устройств вывода, которое может использоваться, может содержать видео дисплей, который обычно представляет собой монитор на основе электронно-лучевой трубки (ЭЛТ) или жидкокристаллического дисплея (ЖКД) с интерфейсом (например, схемами и кабелем DVI), принимающий сигналы от видеоинтерфейс. Видеоинтерфейс суммирует информацию, генерированную компьютерной системой, и на ее основе генерирует видеосигналы в кадре видеопамяти. Другим устройством вывода является телевизионный приемник, которые принимает сигналы от видеоинтерфейса. Обычно видеоинтерфейс обеспечивает композитную видеоинформацию посредством интерфейса разъема видео, рассчитанного на интерфейс видеодисплея (например, разъема RCA композитного видео, в который входит кабель RCA композитного видео; разъема DVI, в который входит кабель дисплея DVI и т.д.).

Пользовательские устройства 1511 ввода часто представляют собой разновидность периферийного устройства 1512 (смотри далее) и могу включать устройства для чтения карт, защитные ключи-заглушки, устройства для опознавания отпечатков пальцев, перчатки, графические планшеты, джойстики, клавиатуры, микрофоны, мышь (мыши), пульты дистанционного управления, устройства для сканирования сетчатой оболочки глаза, сенсорные экраны (например, емкостные, резистивные и т.д.), шаровые манипуляторы, сенсорные площадки, датчики (например, акселерометры, датчики общего освещения, GPS, гироскопы, бесконтактные датчик и т.д.), стило и/или т.п.

Периферийные устройства 1512 могут быть соединены и/или поддерживать связь с интерфейсом ввода-вывода и/или другими средствами такого рода, такими как сетевые интерфейсы, интерфейсы памяти, непосредственно с интерфейсной шиной, системной шиной, ЦП и/или т.п. Периферийные устройства могут являться внешними, внутренними и/или частью контроллера РРТ. Периферийные устройства могут содержать антенну, аудиоустройства (например, вход линии, выход в линию, микрофонный вход, громкоговорители и т.д.), камеры (например, фото, видео, веб-камеры и т.д.), защитные ключи-заглушки (например, для защиты от копирования, обеспечения защищенных транзакций с цифровой подписью и/или т.п.), внешние процессоры (для обеспечения дополнительных возможностей; например, криптографические процессорные устройства 1528), устройства с силовой обратной связью (например, вибродвигатели), сетевые интерфейсы, принтеры, сканеры, запоминающие устройства, приемопередатчики (например, сотовые, GPS и т.д.), видеоустройства (например, защитные очки, мониторы и т.д.), видеоисточники, козырьки и/или т.п. Периферийные устройства часто включают разновидности устройств ввода (например, камеры).

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

Криптографические устройства, такие как без ограничения микроконтроллеры, процессоры 1526, интерфейсы 1527 и/или устройства 1528 могут быть соединены и/или поддерживать связь с контроллером РРТ. Для криптографических устройств и/или в криптографических устройствах может использоваться микроконтроллер МС68НС16 компании Motorola Inc. В микроконтроллере МС68НС16 применяется 16-разрядная команда умножения и накопления в 16-МГц конфигурации, и требуется менее одной секунды для выполнения 512-разрядной операции RSA с секретным ключом. Криптографические устройства поддерживают аутентификацию сообщений от взаимодействующих агентов, а также обеспечивают анонимные транзакции. Криптографические устройства также могут быть сконфигурированы как часть ЦП. Также могут использоваться эквивалентные микроконтроллеры и/или процессоры. Другие предлагаемые на рынке специализированные криптографические процессоры включают CryptoNetX и другие процессоры системы безопасности компании Broadcom; процессор nShield компании nCipher, процессоры серии Luna PCI (например, 7100) компании SafeNet; 40-МГц процессор Roadrunner 184 компании Semaphore Communications; криптографические ускорители (например, Accelerator 6000 PCIe Board, Accelerator 500 Daughtercard) компании Sun; процессоры серии Via Nano (например, L2100, L2200, U2400), которые способны выполнять криптографические команды со скоростью 500+ мегабит в секунду; 33-МГц процессор 6868 компании VLSI Technology; и/или т.п.

Память

В целом, в качестве памяти 1529 рассматривается любая механизация и/или осуществление, позволяющее процессору воздействовать на хранение и/или выборку информации. Тем не менее, поскольку память является взаимозаменяемой технологией и ресурсом, взамен друг друга или во взаимодействии друг с другом может применяться любое число осуществлений памяти. Подразумевается, что в контроллере РРТ и/или компьютерной системе могут применяться различные формы памяти 1529. Например, может быть сконфигурирована компьютерная система, в которой функциональные возможности внутрикристальной памяти ЦП (например, регистров), ОЗУ, ПЗУ и любых других запоминающих устройств обеспечиваются механизмом на основе бумажной перфоленты или перфокарты; разумеется, при таком осуществлении быстродействие является крайне низким. В одной из типичных конфигураций память 1529 содержит include ПЗУ 1506, ОЗУ 1505 и запоминающее устройство 1514. Запоминающим устройством 1514 может являться любое традиционное запоминающее устройство компьютерной системы. Запоминающие устройства могут содержать барабан; (постоянный и/или съемный) накопитель на магнитных дисках; магнитооптический накопитель; оптический накопитель (т.е. Blueray, ПЗУ на компакт-диске/ОЗУ/одноразовой записи)/многократной перезаписи (RW), DVD R/RW, HD DVD R/RW и т.д.); массив устройств (например, массив независимых жестких дисков с избыточностью информации (RAID)); полупроводниковую память (память USB, полупроводниковые диски (SSD) и т.д.); другие машиночитаемые запоминающие среды; и/или другие устройства такого рода. Таким образом, в компьютерной системе в целом требуется и используется память.

Совокупность компонентов

В памяти 1529 может содержаться совокупность компонентов и/или данных программ и/или баз данных, включая без ограничения компонент(-ы) 1515 операционной системы (операционную систему); компонент(-ы) 1516 информационного сервера (информационный сервер); компонент(-ы) 1517 интерфейса пользователя (интерфейс пользователя); компонент(-ы) 1518 веб-браузера (веб-браузер); базу(ы) 1519 данных; компонент(-ы) 1521 почтового сервера; компонент(-ы) 1522 почтового клиента; компонент(-ы) 1520 криптографического сервера (криптографический сервер); компонент(-ы) 1535 РРТ; и/или т.п. (т.е. собирательно совокупность компонентов). Эти компоненты могут храниться, и к ним может осуществляться доступ из запоминающих устройств и/или запоминающих устройств, доступных через интерфейсную шину. Хотя нетрадиционные программные компоненты, такие как компоненты совокупности компонентов обычно хранятся в локальном запоминающем устройстве 1514, они также могут загружаться и/или храниться в памяти, такой как периферийные устройства, ОЗУ, удаленные хранилища посредством сети связи, ПЗУ, различные формы памяти и/или т.п.

Операционная система

Компонентом 1515 операционной системы является выполняемый программный компонент, облегчающий действие контроллера РРТ. Обычно операционная система облегчает доступ к системе ввода-вывода, сетевым интерфейсам, периферийным устройствам, запоминающим устройствам и/или т.п. Операционная система может представлять собой защищенную масштабируемую систему с высокой отказоустойчивостью, такую как Apple Macintosh OS X (сервер); AT&T Plan 9; Be OS; Unix и распространяемые реализации Unix-подобных систем (так как UNIX компании AT&T; разновидности системы Berkley Software Distribution (BSD), такие как FreeBSD, NetBSD, OpenBSD, и/или т.п.; распространяемые реализации системы Linux, такие как Red Hat, Ubuntu и/или т.п.); и/или тому подобные операционные системы. Тем не менее, также могут применяться более ограниченные и/или менее защищенные операционные системы, такие как Apple Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows 2000/2003/3.1/95/98/CE/Millenium/NT/Vista/XP (сервер), Palm OS и/или т.п. Операционная система может поддерживать связь с другими компонентами совокупности компонентов, включая саму себя и/или т.п. Чаще всего операционная система поддерживает связь с другими программными компонентами, интерфейсами пользователя и/или т.п. Например, операционная система может содержать, передавать, генерировать, получать и/или обеспечивать программный компонент, систему, пользователя и/или передачу данных, запросов и/или ответов. При выполнении в ЦП операционная система может обеспечивать взаимодействие с сетями связи, данными, системами ввода-вывода, периферийными устройствами, программными компонентами, памятью, пользовательскими устройствами ввода и/или т.п. Операционная система может обеспечивать протоколы связи протоколы связи, позволяющие контроллеру РРТ поддерживать связь с другими объектами по сети 1513 связи. Контроллером РРТ могут использоваться различные протоколы связи в качестве механизма транспорта поднесущей с целью взаимодействия, включая без ограничения многоадресную передачу, TCP/IP, UDP, одноадресную передачу и/или т.п.

Информационный сервер

Компонент 516 информационного сервера является хранящимся программным компонентом, который выполняется ЦП. Информационным сервером может являться традиционный информационный Интернет-сервер, такой как без ограничения Apache компании Apache Software Foundation, информационный Интернет-сервер компании Microsoft и/или т.п. Информационный сервер может предусматривать выполнение программных компонентов с использованием таких средств, как активные серверные страницы (ASP), ActiveX, (ANSI) (Objective-) С (++), C# и/или .NET, сценарии общего шлюзового интерфейса (CGI), динамический (D) язык разметки гипертекста (HTML), FLASH, Java, JavaScript, практический язык для извлечения данных и составления отчетов (PERL), язык гипертекстового препроцессора (РНР), каналы, Python, протокол приложений для беспроводной связи (WAP), WebObjects и/или т.п. Информационный сервер может поддерживать протоколы защищенной связи, такие как без ограничения протокол передачи файлов (FTP); протокол передачи гипертекста (HTTP); протокол защищенной передачи гипертекста (HTTPS), протокол безопасных соединений (SSL), протоколы обмена сообщениями (например, системы America Online (AOL) мгновенного обмена сообщениями (AIM), системы обмена приложениями (APEX), ICQ, системы диалогового общения по Интернету (IRC), службы обмена сообщениями Microsoft Network (MSN), протокол обмена сообщениями и уведомления о присутствии (PRIM), протокол инициации сеансов (SIP) Инженерной группы по развитию Интернета (IETF), набор профилей и расширений стандарта SIP для систем мгновенного обмена сообщениями и уведомления о присутствии (SIMPLE), открытый расширяемый протокол для обмена сообщениями и уведомления о присутствии (ХМРР) (т.е. Jabber или службы мгновенного обмена сообщениями и уведомления о присутствии (IMPS) Открытого мобильного альянса (ОМА), службы мгновенного обмена сообщениями Yahoo!) и/или т.п. Информационный сервер предоставляет результаты веб-браузерам в виде веб-страниц и предусматривает регулируемого генерирования веб-страниц посредством взаимодействия с другими программными компонентами. После того, как относящаяся к разрешению имени часть HTTP-запроса преобразована системой доменных имен (DNS) в адрес конкретного информационного сервера, информационный сервер преобразует запросы информации в заданных местоположениях контроллера РРТ на основании остального HTTP-запроса. Например, в запросе http://123.124.125.126/myInformation.html может содержаться IP-часть "123.124.125.126", преобразованная сервером DNS в соответствующий IP-адрес информационного сервера, который в свою очередь может проводить синтаксический анализ части "/myInformation.html" HTTP-запроса и преобразовывать ее в адрес ячейки памяти, содержащий "myInformation.html". Кроме того, в различных портах могут использоваться другие протоколы информационного обслуживания, например, FTP в порте 21 и/или т.п. Информационный сервер может поддерживать связь с другими компонентами совокупности компонентов, включая самого себя, и/или тому подобными устройствами. Чаще всего информационный сервер поддерживает связь с базой 1519 данных РРТ, операционными системами, другими программными компонентами, интерфейсами пользователя, веб-браузерами и/или т.п.

Доступ к базе данных РРТ может осуществляться посредством ряда мостовых механизмов базы данных, таких как перечисленные далее языки сценариев (например, CGI) и посредством перечисленных далее каналов связи между приложениями (например, CORBA, WebObjects и т.д.). Любые запросы данных посредством веб-браузера путем синтаксического анализа посредством мостового механизма преобразуются в соответствующие грамматические формы, требуемые РРТ. В одном из вариантов осуществления информационный сервер обеспечивает веб-бланк, доступный для веб-браузера. Записи, вносимые в поля веб-бланка, помечаются как внесенные в конкретные поля и подвергаются синтаксическому анализу как таковые. Затем внесенные элементы передаются вместе с пометками, которые служат для синтаксического анализатора указанием генерировать запросы, адресованные соответствующим таблицам и/или полям. В одном из вариантов осуществления синтаксический анализатор может генерировать запросы на стандартном SQL путем реализации строки поиска с соответствующими командами объединения/выбора на основе помеченных текстовых записей, при этом получаемая команда передается РРТ в виде запроса посредством мостового механизма. После получения результатов запроса они передаются посредством мостового механизма и могут подвергаться синтаксическому анализу с целью форматирования и генерирования мостовым механизмом веб-страницы новых результатов. Затем такая веб-страница новых результатов передается информационному серверу, который может предоставлять ее запрашивающему веб-браузеру.

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

Интерфейс пользователя

Компьютерные интерфейсы в некоторых отношениях аналогичны интерфейсам для управления автомобилем. Элементы интерфейса для управления автомобилем, такие как рулевое колесо, механизм переключения передач и спидометр способствуют доступу, эксплуатации и отображению ресурсов и состояния автомобиля. Элементы интерфейса ля взаимодействия с компьютером, такие как отмечаемые кнопки, курсоры, меню, полосы прокрутки и окна (обычно собирательно именуемые виджетами) также способствуют доступу, возможностям, эксплуатации и отображению данных и ресурсов и состояния аппаратного обеспечения компьютера и операционной системы. Рабочие интерфейсы обычно именуются интерфейсами пользователя. Графические интерфейсы пользователя (ГИП), такие как Aqua для операционной системы компании Apple Macintosh, OS/2 компании IBM, Windows 2000/2003/3.1/95/98/CE/Millenium/NT/XP/Vista/7 (т.е. Aero) компании Microsoft, X-Windows (например, который может содержать дополнительные библиотеки графических интерфейсов и слоев Unix, такие К Desktop Environment (KDE) компании Unix, mythTV и сетевая среда моделирования объектов для операционной системы GNU (GNOME)), библиотеки веб-интерфейсов (например, библиотеки интерфейсов ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript и т.д., такие как без ограничения Dojo, jQuery(UI), MooTools, Prototype, script.Aculo.us, SWFObject, Yahoo! User Interface с возможностью использования каждой из них) служат отправной точкой и средством доступа к информации и ее наглядного отображения для пользователей.

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

Веб-браузер

Компонент 1518 веб-браузера является хранящимся программным компонентом, который выполняется ЦП. Веб-браузер может представлять собой традиционное приложение для просмотра гипертекстовых документов, такое как Microsoft Internet Explorer или Netscape Navigator. Может обеспечиваться защищенный просмотр веб-странице 128-разрядным (или большим) шифрованием посредством HTTPS, SSL и/или т.п. Веб-браузеры предусматривают выполнение программных компонентов с помощью таких средств, как ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, подключаемые API для веб-браузера (например, FireFox, Safari Plug-in и/или т.п. API) и/или т.п. Веб-браузеры и подобные средства доступа к информации могут быть интегрированы в PDA, сотовые телефоны и/или другие мобильные устройства. Веб-браузер может поддерживать связь с другими компонентами совокупности компонентов, включая самого себя, и/или тому подобными средствами. Чаще всего веб-браузер поддерживает связь с информационными серверами, операционными системами, интегрированными программными компонентами (например, сменными платами) и/или т.п.; например, он может содержать, передавать, генерировать, получать и/или обеспечивать программный компонент, систему, пользователя и/или передачу данных, запросов и/или ответов. Разумеется, вместо веб-браузера и информационного сервера может быть разработано комбинированное приложение для выполнения аналогичных функций того и другого. Комбинированное приложение будет аналогичным образом воздействовать на получение и предоставление информации пользователям, агентам пользователей и/или т.п. от поддерживающих РРТ узлов. Комбинированное приложение может являться бесполезным в системах с применением стандартных веб-браузеров.

Почтовый сервер

Компонент 1521 почтового сервера является хранящимся программным компонентом, который выполняется ЦП 1503. Почтовый сервер может представлять собой традиционный почтовый сервер сети Интернет, такой как без ограничения sendmail, Microsoft Exchange, и/или т.п. Почтовый сервер может предусматривать выполнение программных компонентов с помощью таких средств, как ASP, ActiveX, (ANSI) (Objective-) С (++), C# и/или .NET, CGI-сценарии, Java, JavaScript, PERL, PHP, каналы, Python, WebObjects и/или т.п. Почтовый сервер может поддерживать протоколы связи, включающие без ограничения протокол доступа к Интернет-службе сообщений (IMAP), интерфейс прикладного программирования для сообщений (MAPI)/Microsoft Exchange, почтовый протокол (РОР3), простой протокол пересылки электронной почты (SMTP) и/или т.п. Почтовый сервер способен маршрутизировать, пересылать и обрабатывать входящие и исходящие сообщения электронной почты, которые отправлялись, ретранслировались и/или иначе проходили через РРТ и/или адресовались РРТ.

Доступ к почте РРТ может осуществляться посредством ряда API, предлагаемых отдельными компонентами веб-сервера и/или операционной системой.

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

Почтовый клиент

Компонент 1522 почтового клиента является хранящимся программным компонентом, который выполняется ЦП 1503. Почтовый клиент может представлять собой традиционное приложение для просмотра электронной почты, такое как Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla, Thunderbird и/или т.п. Почтовые клиенты могут поддерживать ряд протоколов передачи, таких как IMAP, Microsoft Exchange, РОР3, SMTP, и/или т.п. Почтовый клиент может поддерживать связь с другими компонентами совокупности компонентов, включая самого себя, и/или тому подобными средствами. Чаще всего почтовый клиент поддерживает связь с почтовыми серверами, операционными системами, другими почтовыми клиентами и/или т.п.; например, он может содержать, передавать, генерировать, получать и/или обеспечивать программный компонент, систему, пользователя и/или передачу данных, запросов и/или ответов. В целом, почтовый клиент обеспечивает средство составления и передачи сообщений электронной почты.

Криптографический сервер

Компонент 1520 криптографического сервера является хранящимся программным компонентом, который выполняется ЦП 1503, криптографическим процессором 1526, интерфейсом 1527 криптографического процессора, криптографическим процессорным устройством 1528 и/или т.п. Интерфейсы криптографического процессора предусматривают ускорение запросов шифрования и/или дешифрования криптографическим компонентом; тем не менее, в качестве альтернативы, криптографический компонент, может действовать в традиционном ЦП. Криптографический компонент предусматривает шифрование и/или дешифрование предоставляемых данных. Криптографический компонент предусматривает как симметричное, так и асимметричное (например, Pretty Good Protection (PGP)) шифрование и/или дешифрование. В криптографическом компоненте могут применяться криптографические методы, включающие без ограничения цифровые сертификаты (например, структура аутентификации Х.509), электронные цифровые подписи, двойные подписи, охватывающие подписи, защиту доступа к паролям, распределение открытых ключей и/или т.п. Криптографический компонент поддерживает множество протоколов (шифрования и/или дешифрования) безопасной пересылки данных, включая без ограничения вычисление контрольной суммы, стандарт шифрования данных (DES), шифрование эллиптической кривой (ЕСС), международный алгоритм шифрования данных (IDEA), метод формирования свертки сообщения (MD5, который является односторонней хэш-функцией), пароли, шифр Райвеста (RC5), Rijndael, RSA который является системой шифрования и аутентификация в сети Интернет с использованием алгоритма, разработанного в 1977 г. Роном Райвестос, Ади Шамиром и Леонардом Адлеманом), защищенный алгоритм хэширования (SHA), протокол безопасных соединений (SSL), протокол защищенной передачи гипертекста (HTTPS) и/или т.п. За счет применения таких протоколов шифрования безопасной пересылки данных РРТ может шифровать все входящие и исходящие сообщения и служить узлом связи виртуальной частной сети (VPN) с более широкой сетью связи. Криптографический компонент облегчает процесс "авторизации защиты", когда протокол безопасной пересылки данных предотвращает доступ к ресурсу, а криптографический компонент осуществляет авторизованный доступ к защищенному ресурсу. Кроме того, криптографический компонент может обеспечивать уникальные идентификаторы содержимого, например, с применением хэш-функции MD5 для получения уникальной подписи для цифрового аудиофайла. Криптографический компонент может поддерживать связь с другими компонентами совокупности компонентов, включая самого себя, и/или тому подобными средствами. Криптографический компонент поддерживает схемы шифрования, предусматривающие защищенную передачу информации по сети связи, чтобы позволить компоненту РРТ при желании участвовать в защищенных транзакциях. Криптографический компонент облегчает защищенный доступ к ресурсам в РРТ и облегчает доступ к защищенным ресурсам в удаленных системах; т.е. он может действовать как клиент и/или сервер защищенных ресурсов. Чаще всего криптографический компонент поддерживает связь с информационными серверами, операционными системами, другими программными компонентами и/или т.п. Криптографический компонент может содержать, передавать, генерировать, получать и/или обеспечивать программный компонент, систему, пользователя и/или передачу данных, запросов и/или ответов.

База данных РРТ

Компонент 1519 базы данных РРТ может быть реализован в базе данных и хранящихся в ней данных. База данных является хранящимся программным компонентом, который выполняется ЦП и часть которого конфигурирует ЦП на обработку хранящихся данных. База данных может представлять собой традиционную, отказоустойчивую, реляционную, масштабируемую, защищенную базу данных, такую как Oracle или Sybase. Реляционные базы данных представляют собой расширение плоского файла. Реляционные базы данных состоят из последовательности связанных таблиц. Таблицы взаимосвязаны посредством ключевого поля. Ключевое поле обеспечивает комбинирование таблиц путем индексации в зависимости от ключевого поля; т.е. ключевые поля действуют как размерные точки поворота для комбинирования информации из различных таблиц. Зависимости в целом определяют связи между таблицами путем согласования первичных ключей. Первичные ключи отображают поля, которые однозначно идентифицируют строки таблицы в реляционной базе данных. Более точно, они однозначно идентифицируют строки таблицы в "одной" стороны зависимости типа "один - множество".

В качестве альтернативы, база данных РРТ может быть реализована с использованием различных стандартных структур данных, таких как массив, хеш-функция, (связный) список, структура, структурированный текстовой файл (например, XML), таблица и/или т.п. Такие структуры данных могут храниться в памяти и/или в (структурированных) файлах. В качестве другой альтернативы, может использоваться объектно-ориентированная база данных, такая как Frontier, ObjectStore, Poet, Zope и/или т.п. В объектно-ориентированных базах данных может находиться ряд наборов объектов, которые сгруппированы и/или связаны друг с другом общими атрибутами; они могут быть связаны с другими наборами объектов некоторыми общими атрибутами. Объектно-ориентированные базы данных действуют аналогично реляционным базам данных за исключением того, что объекты являются не просто блоками данных, а могут иметь функциональные возможности других типов, инкапсулированные в заданный объект. Если база 1519 данных РРТ реализована как структура данных, она может быть интегрирована в другой компонент, такой как компонент 1535 РРТ. Кроме того, база данных может быть реализована как сочетание структур данных, объектов и реляционных структур. Базы данных могут представлять собой бесконечное число разновидностей, консолидированных и/или распределенных стандартными методами обработки данных. Части баз данных, например, таблицы, могут экспортироваться и/или импортироваться, и соответственно, могут являться децентрализованными и/или интегрированными.

В одном из вариантов осуществления компонент 1519 базы данных содержат несколько таблиц 1519a-n. В таблице 1519a пользователей могут содержаться поля, включающие без ограничения user_id, token_id, ssn, dob, first_name, last_name, age, state, address_firstline, address_secondline, zipcode, devices_list, contact_info, contact_type, alt_contact_info, alt_contact_type и/или т.п. Таблица пользователей может поддерживать и/или отслеживать счета множества лиц в РРТ. В таблице 1519b устройств могут содержаться поля, включающие без ограничения device_ID, device_name, device_IP, device_GPS, device_MAC, device_serial, device_ECID, device_UDID, device_browser, device_type, device_model, device_version, device_OS, device_apps_list, device_securekey, wallet_app_installed_flag и/или т.п. В таблице 1519c приложений могут содержаться поля, включающие без ограничения app_ID, app_name, app_type, app_dependencies, app_access_code, user_pin и/или т.п. В таблице 1519d счетов могут содержаться поля, включающие без ограничения account_number, account_security_code, account_name, issuer_acquirer_flag, issuer_name, acquirer_name, account_address, routing_number, access_API_call, linked_wallets_list и/или т.п. В таблице 1519e торговцев могут содержаться поля, включающие без ограничения merchant_id, merchant_name, merchant_address, store_id, ip_address, mac_address, auth_key, port_num, security_settings_list и/или т.п. В таблице 1519f эмитентов могут содержаться поля, включающие без ограничения issuer_id, issuer_name, issuer_address, ip_address, mac_address, auth_key, port_num, security_settings_list и/или т.п. В таблице 1519g торговых банков могут содержаться поля, включающие без ограничения account_firstname, account_lastname, account_type, account_num, account_balance_list, billingaddress_line1, billingaddress_line2, billing_zipcode, billing_state, shipping_preferences, shippingaddress_line1, shippingaddress_line2, shipping_zipcode, shipping_state и/или т.п. В таблице 1519h токенов могут содержаться поля, включающие без ограничения token_id, token_phrase, token_issuer, token_md5, token_security, user_id, password, token_composition_list, account_link и/или т.п. В таблице 1519i посещений магазинов могут содержаться поля, включающие без ограничения user_id, session_id, alerts_URL, timestamp, expiry_lapse, merchant_id, store_id, device_type, device_ID, device_IP, device_MAC, device_browser, device_serial, device_ECID, device_model, device_OS, wallet_app_installed, total_cost, cart_ID_list, product_params_list, social_flag, social_message, social_networks_list, coupon_lists, accounts_list, CVV2_lists, charge_ratio_list, charge_priority_list, value_exchange_symbols_list, bill_address, ship_address, cloak_flag, pay_mode, alerts_rules_list и/или т.п. В таблице 1519j транзакций могут содержаться поля, включающие без ограничения order_id, user_id, timestamp, transaction_cost, purchase_details_list, num_products, products_list, product_type, product_params_list, product_title, product_summary, quantity, user_id, client_id, client_ip, client_type, client_model, operating_system, os_version, app_installed_flag, user_id, account_firstname, account_lastname, account_type, account_num, account_priority_account_ratio, billingaddress_line1, billingaddress_line2, billing_zipcode, billing_state, shipping_preferences, shippingaddress_line1, shippingaddress_line2, shipping_zipcode, shipping_state, merchant_id, merchant_name, merchant_auth_key, и/или т.п. В таблице 1519k групп могут содержаться поля, включающие без ограничения batch_id, transaction_id_list, timestamp_list, cleared_flag_list, clearance_trigger_settings и/или т.п. В таблице 15191 бухгалтерских книг могут содержаться поля, включающие без ограничения request_id, timestamp, deposit_amount, batch_id, transaction_id, clear_flag, deposit_account, transaction_summary, payor_name, payor_account, и/или т.п. В таблице 1519m арбитраторов могут содержаться поля, включающие без ограничения arbitrator_id, arbitrator_name, arbitrator_geo, arbitrator_IP, arbitrator_URL, merchant_service_list и/или т.п. В таблице 1519n правил конфиденциальности могут содержаться поля, включающие без ограничения user_id, token_id, home_location, home_country, default_privacy_flag, privacy_rule_set_id, country, privacy_rule_data, privacy_rule_triggers_list, process_restriction_flag, process_restrictions_list, home_token_server_ip и/или т.п. В таблице 1519o кодов стран могут содержаться поля, включающие без ограничения token_hash_ID, country_code, privacy_rule_set_id и/или т.п.

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

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

База данных РРТ может поддерживать связь с другими компонентами совокупности компонентов, включая саму себя, и/или тому подобными средствами. Чаще всего база данных РРТ поддерживает связь с компонентом РРТ, другими программными компонентами и/или т.п. База данных может содержать, запоминать и предоставлять информацию, касающуюся других узлов и данных.

РРТ

Компонент 1535 РРТ является хранящимся программным компонентом, который выполняется ЦП. В одном из вариантов осуществления в компонент РРТ входят любые и/или все сочетания особенностей РРТ, рассмотренные ранее со ссылкой на чертежи. По существу, РРТ воздействует на доступ, получение и предоставление информации, услуг, транзакций и/или т.п. по различным сетям связи.

Компонент РРТ посредством компонентов РРТ может преобразовывать поручения токенизированной оплаты покупок в движение средств для оплаты покупок между счетами множества эмитентов и/или т.п. и использованием РРТ. В одном из вариантов осуществления компонент 1535 РРТ использует входные данные (например, данные 411 покупки, адрес 416 арбитратора токенов, данные 423 для создания токена, данные 611 покупки, адрес 616 арбитратора токенов, данные 620 эмитента, данные 626 опций платежа, данные 636 сервера эмитента, пользовательские данные 640a-n, данные 655 группы транзакций, данные 663 сервера эмитента и/или т.п.) и т.д. и посредством различных компонентов (например, ТРЕ 1541, tPTE 1542 и/или т.п.) преобразовывать их в выходные данные (например, предложение 420 токенизации, данные 426 токена, подтверждение 622a токена аутентификация, обновленные данные 629 эмитента, сообщение 630-31 "выполняется авторизация", данные 634 токена, сообщение 644 о неудачной попытке авторизации, данные 645 транзакции, ответ 642a-n на запрос авторизации, сообщение 646-47 об успешной авторизации, данные 649 для присоединения к группе, квитанцию 650 об оплате покупки, данные 661 транзакции, сообщение 668-69 о переводе средств и/или т.п.).

Компонент РРТ, обеспечивающий доступ к информации между узлами, может быть разработан с применением стандартных средств и языков разработки, включая без ограничения компоненты Apache, Assembly, ActiveX, двоичные исполнимые файлы, (ANSI) (Objective-) С (++), С# и/или .NET, адаптеры баз данных, CGI-сценарии, Java, JavaScript, средства отображения, процедурные и другие объектно-ориентированные средства разработки, PERL, PHP, Python, сценарии оболочки, команды SQL, расширения сервера веб-приложений, среды разработки и библиотеки веб-приложений (например, ActiveX компании Microsoft; Adobe AIR, FLEX & FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools; Prototype; script.aculo.us; простой протокол доступа к объектам (SOAP); SWFObject; Yahoo! User Interface; и/или т.п.), WebObjects и/или т.п. В одном из вариантов осуществления в сервере РРТ применяется криптографический сервер для шифрования и дешифрования сообщений. Компонент РРТ может поддерживать связь с другими компонентами совокупности компонентов, включая самого себя, и/или тому подобными средствами. Чаще всего компонент РРТ поддерживает связь с базой данных РРТ, операционными системами, другими программными компонентами и/или т.п. РРТ может содержать, передавать, генерировать, получать и/или обеспечивать программный компонент, систему, пользователя и/или передачу данных, запросов и/или ответов.

Распределенные РРТ

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

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

Конфигурация контроллера РРТ зависит от контекста развертывания системы. На требования к развертыванию и конфигурации могут влиять такие факторы, как без ограничения бюджет, пропускная способность, местоположение и/или использование базовых аппаратных ресурсов. Обмен данными, получение и/или предоставление данных может осуществляться независимо от того, обеспечивает ли конфигурация более консолидированные и/или интегрированные программные компоненты, более распределенную последовательность программных компонентов и/или определенное сочетание консолидированной и распределенной конфигурации. Экземпляры компонентов совокупности программных компонентов, консолидированные в общей базе кодов, могут обмениваться данными, получать и/или предоставлять данные. Это может делаться методами обработки данных и обмена данными между приложениями, включая без ограничения привязку данных (например, ссылки), обмен внутренними сообщениями, обмен переменными экземплярами объектов, совместно используемое пространство памяти, передачу переменных величин и/или т.п.

Если компоненты совокупности компонентов являются дискретными, отдельными и/или внешними по отношению друг к другу, обмен данными с другими компонентами, получение и/или предоставление данных другим компонентам может осуществляться методами обработки данных и обмена данными между приложениями, включая без ограничения передачу информации через интерфейсы прикладных программ (API); (распределенную) модель компонентных объектов ((D)COM), (распределенное) связывание и внедрение объектов ((D)OLE) и/или т.п.), стандартную архитектуру брокеров объектных запросов (CORBA), локальные и удаленные интерфейсы прикладных программ технологии Jini, представление объектов на языке JavaScript (JSON), вызов удаленных методов (RMI), SOAP, каналы выполнения процессов, совместно используемые файлы и/или т.п. Передача сообщений между дискретными компонентами с целью обмена между приложениями или в пределах областей памяти одного компонента для обмена внутри приложения может облегчаться за счет создания и анализа грамматики. Грамматика может разрабатываться путем использования средств разработки, таких как lex, yacc, XML и/или т.п., предусматривающих возможности генерирования и анализа грамматики, которая в свою очередь может служить основой для обмена сообщениями внутри и между компонентами.

Например, может быть создана грамматика для распознавания токенов http-команды post, например:

где Valuel рассматривается как параметр, поскольку "http://" является частью синтаксиса, а то, что следует далее, рассматривается как часть значения post. Аналогичным образом, при использовании такой грамматики переменная величина "Valuel" может вводиться в "http://" команду post и затем передаваться. Сам синтаксис может быть представлен как структурированные данные, которые интерпретируются или иным образом используются, чтобы генерировать механизм синтаксического анализа (например, текстовой файл описания синтаксиса для обработки посредством lex, yacc и т.д.). Кроме того, после того как генерирован и/или создан экземпляр механизма синтаксического анализа, он сам может обрабатывать и/или проводить синтаксический анализ структурированных данных, включая без ограничения представленный символами (например, ярлыками) текст, HTML, структурированные текстовые потоки, XML и/или тому подобные структурированные данные. В другом варианте осуществления сами протоколу обработки данных между приложениями могут содержать интегрированные и/или легкодоступные синтаксические анализаторы (например, JSON, SOAP и/или тому подобные синтаксические анализаторы), которые могут применяться для проведения синтаксического анализа данных (например, сообщений). Кроме того, помимо анализа сообщения также может использоваться грамматически анализ баз данных, совокупностей данных, складов данных, структурированных данных и/или т.п. И в этом случае желаемая конфигурация зависит от контекста, среды и требований к развертыванию системы.

Например, в некоторых вариантах осуществления контроллер РРТ может выполнять сценарий РНР, в котором посредством информационного сервера реализован сервер соединений по протоколу безопасных соединений (SSL), прослушивающий входящие сообщения в порте, на который клиент может отправлять данные, например, данные, закодированные в формате JSON. После обнаружения входящего сообщения оно может считываться его из клиентского устройства, может проводиться синтаксический анализ принятых текстовых данных, закодированных в формате JSON, с целью извлечения информации и ее преобразования в переменные величины РНР, и данные (например, идентифицирующая клиента информация и т.д.) и/или извлеченная информация может сохраняться в реляционной базе данных, доступной с использованием языка структурированных запросов (SQL). Далее приведен один из примеров листинга, записанного преимущественно в форме команд PHP/SQL приема закодированных в формате JSON входных данных от клиентского устройства посредством соединения по протоколу SSL, синтаксического анализа данных с целью извлечения переменных величин и сохранения данных в базе данных:

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

и других реализаций синтаксического анализатора:

.

В настоящей заявке (включая титульный лист, название, заголовки, разделы Область техники, к которой относится изобретение, Предпосылки создания изобретения, Краткое изложение сущности изобретения, Краткое описание чертежей, Подробное описание, Формулу изобретения, Реферат, Чертежи, Приложения и/или иное) проиллюстрированы различные возможные варианты осуществления заявленных изобретений на практике. Преимущества и признаки изобретений лишь наглядно отображают варианты осуществления и не являются исчерпывающими и/или исключительными. Они представлены лишь для облечения понимания и разъяснения заявленных принципов. Подразумевается, что они не отображают всех заявленных изобретений. По существу, некоторые особенности изобретений не были рассмотрены в описании. Тот факт, что могли быть не раскрыты альтернативные варианты осуществления конкретной части изобретений или дополнительные неописанные альтернативные варианты осуществления части изобретений, которые могут существовать, не должен рассматриваться как отказ от прав на эти альтернативные варианты осуществления. Следует учесть, что во многих из этих неописанных вариантов осуществления содержаться такие же принципы изобретения, а другие варианты осуществления являются эквивалентными. Так, подразумевается, что могут использоваться другие варианты осуществления, и возможны функциональные, логические, организационные, структурные и/или топологические модификации, не выходящие за пределы существа и/или объема изобретения. Все примеры и/или варианты осуществления считаются неограничивающими изобретения. Кроме того, что касается не рассмотренных в описании вариантов осуществления, они опущены лишь для краткости и во избежание повторов. Так, подразумевается, что логическая и/или топологическая структура любого сочетания любых программных компонентов (совокупности компонентов), другие компоненты и/или любые существующие сочетания признаков, проиллюстрированные на чертежах и/или в описании, на ограничены фиксированным порядком и/или расположением, любой описанный порядок является примером, и описанием предусмотрены все эквиваленты независимо от порядка. Помимо этого, подразумевается, что такие признаки не ограничены последовательным выполнением, описанием предусмотрено любое число потоков, процессов, услуг, серверов и/или т.п., которые могут выполняться асинхронно, одновременно, параллельно, совместно, синхронно и/или т.п. Некоторые из этих признаков могут являться по существу взаимно противоречащими в том смысле, что они могут одновременно присутствовать в одном варианте осуществления. Аналогичным образом, некоторые признаки применимы к одной особенности изобретения и неприменимы к другим особенностям. Кроме того, в описание входят другие изобретения, не заявленные в настоящей заявке. Заявитель оставляет за собой все права на такие не заявленные в данный момент изобретения, включая право притязания на такие изобретения, подачи дополнительных заявок, продолжающих заявок, частично продолжающих заявок, выделенных заявок и/или т.п. Подразумевается, что преимущества, варианты осуществления, примеры, функции, признаки, логические, организационные, структурные, топологические и/или другие особенности описания не должны считаться ограничивающими изобретение, охарактеризованное его формулой, или ограничивающими эквиваленты формул изобретения. Подразумевается, что в зависимости от конкретных потребностей и/или характеристик индивидуального и/или корпоративного пользователя РРТ, конфигурации и/или реляционной модели баз данных, типа данных, структуры передачи данных и/или сетей, синтаксической структуры и/или т.п. могут быть реализованы различные варианты осуществления РРТ, обеспечивающие высокую степень гибкости и соответствия требованиям заказчика. Например, особенности РРТ могут быть приспособлены к алгоритмам сжатия, система обеспечения безопасности, оптимизации связи, и/или т.п. Хотя в различных вариантах осуществления и при рассмотрении РРТ речь шла о транзакциях покупки, тем не менее, подразумевается, что описанные варианты осуществления могут быть легко сконфигурированы и/или приспособлены к самым разнообразным применениям и/или реализациям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

31. Способ по п.30, в котором пользовательским устройством является мобильное устройство.

32. Способ по п.31, в котором мобильным устройством является одно из следующего: смарт-карта, предоплаченная карта, кредитная карта, дебетовая карта, смартфон, PDA, портативный компьютер и карманное вычислительное устройство.

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

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

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

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

37. Способ по п.30, в котором токен покупки повышенной конфиденциальности шифруется с использованием хеш-функции MD5.

38. Способ по п.30, в котором токен покупки повышенной конфиденциальности шифруется с использованием хеш-функции Elf64.

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

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

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

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

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

44. Способ по п.43, в котором заданным регионом является Европейский союз.

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

46. Способ по п.45, в котором эффективная обработка платежей включает передачу обработки платежей менее загруженному серверу.

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

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

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

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

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

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

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

54. Система по п.53, в которой пользовательским устройством является мобильное устройство.

55. Система по п.53, в которой мобильным устройством является одно из следующего: смарт-карта, предоплаченная карта, кредитная карта, дебетовая карта, смартфон, PDA, портативный компьютер и карманное вычислительное устройство.

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

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

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

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

60. Система по п.53, в которой токен покупки повышенной конфиденциальности шифруется с использованием хеш-функции MD5.

61. Система по п.53, в которой токен покупки повышенной конфиденциальности шифруется с использованием хеш-функции Elf64.

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

63. Система по п.53, в которой токен покупки повышенной конфиденциальности шифруется с использованием двунаправленного алгоритма шифрования.

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

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

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

67. Система по п.66, в которой заданным регионом является Европейский союз.

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

69. Система по п.68, в которой эффективная обработка платежей включает передачу обработки платежей менее загруженному серверу.

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

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

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

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

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

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

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

77. Устройство по п.76, в котором пользовательским устройством является мобильное устройство.

78. Устройство по п.77, в котором мобильным устройством является одно из следующего: смарт-карта, предоплаченная карта, кредитная карта, дебетовая карта, смартфон, PDA, портативный компьютер и карманное вычислительное устройство.

79. Устройство по п.76, в котором токен покупки повышенной конфиденциальности генерируется с использованием идентификатора счета пользователя.

80. Устройство по п.79, в котором токен покупки повышенной конфиденциальности дополнительно генерируется с использованием идентификатора страны постоянного местожительства.

81. Устройство по п.76, в котором токен покупки повышенной конфиденциальности содержит идентификатор местоположения страны постоянного местожительства пользователя.

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

83. Устройство по п.76, в котором токен покупки повышенной конфиденциальности шифруется с использованием хеш-функции MD5.

84. Устройство по п.76, в котором токен покупки повышенной конфиденциальности шифруется с использованием хеш-функции Elf64.

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

86. Устройство по п.76, в котором токен покупки повышенной конфиденциальности шифруется с использованием двунаправленного алгоритма шифрования.

87. Устройство по п.76, дополнительно включающее распознавание содержимого токена покупки повышенной конфиденциальности.

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

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

90. Устройство по п.89, в котором заданным регионом является Европейский союз.

91. Устройство по п.76, в котором в наборе правил с требованиями сохранения конфиденциальности отсутствуют требования, препятствующие совместному использованию информации пользователя, и содержатся правила эффективной обработки платежей.

92. Устройство по п.91, в котором эффективная обработка платежей включает передачу обработки платежей менее загруженному серверу.

93. Устройство по п.91, в котором эффективная обработка платежей включает передачу обработки платежей серверу в сети с меньшей перегрузкой.

94. Устройство по п.76, в котором определение набора правил с требованиями сохранения конфиденциальности включает:
запрос пользовательской базы данных конфиденциальности данных с кодами стран с использованием зашифрованного односторонней хеш-функцией токена покупки с целью определения кода страны постоянного местожительства пользователя, и
запрос в базе данных правил конфиденциальности с кодами стран кода страны постоянного местожительства пользователя с целью определения набора правил с требованиями сохранения конфиденциальности.

95. Устройство по п.94, в котором в пользовательской базе данных конфиденциальности данных с кодами стран содержится, по меньшей мере, идентификатор пользователя и код страны.

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

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

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

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

100. Среда по п.99, в которой пользовательским устройством является мобильное устройство.

101. Среда по п.100, в которой мобильным устройством является одно из следующего: смарт-карта, предоплаченная карта, кредитная карта, дебетовая карта, смартфон, PDA, портативный компьютер и карманное вычислительное устройство.

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

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

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

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

106. Среда по п.99, в которой токен покупки повышенной конфиденциальности шифруется с использованием хеш-функции MD5.

107. Среда по п.99, в которой токен покупки повышенной конфиденциальности шифруется с использованием хеш-функции Elf64.

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

109. Среда по п.99, в которой токен покупки повышенной конфиденциальности шифруется с использованием двунаправленного алгоритма шифрования.

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

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

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

113. Среда по п.112, в которой заданным регионом является Европейский союз.

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

115. Среда по п.114, в которой эффективная обработка платежей включает передачу обработки платежей менее загруженному серверу.

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

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

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

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

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