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

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

Иллюстрации

Показать все

Реферат

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

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

Заявитель настоящим притязает на приоритет предварительной патентной заявки США 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 данных из карты пользователя (например, кредитной карты, дебетовой карты, предоплаченной карты, платежной к