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

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

Info

Publication number
RU2602394C2
RU2602394C2 RU2013158683/08A RU2013158683A RU2602394C2 RU 2602394 C2 RU2602394 C2 RU 2602394C2 RU 2013158683/08 A RU2013158683/08 A RU 2013158683/08A RU 2013158683 A RU2013158683 A RU 2013158683A RU 2602394 C2 RU2602394 C2 RU 2602394C2
Authority
RU
Russia
Prior art keywords
purchase
country
payment
user
token
Prior art date
Application number
RU2013158683/08A
Other languages
English (en)
Other versions
RU2013158683A (ru
Inventor
Тимоти Вильям ОБОРН
Original Assignee
Виза Интернешнл Сервис Ассосиэйшн
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Виза Интернешнл Сервис Ассосиэйшн filed Critical Виза Интернешнл Сервис Ассосиэйшн
Publication of RU2013158683A publication Critical patent/RU2013158683A/ru
Application granted granted Critical
Publication of RU2602394C2 publication Critical patent/RU2602394C2/ru

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/384—Payment protocols; Details thereof using social networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/386—Payment protocols; Details thereof using messaging services or messaging apps
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Abstract

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

Description

В настоящем изобретении раскрыты и описаны новые усовершенствования и особенности технологии токенизации конфиденциальности платежей (далее "изобретение") и содержатся сведения, подлежащие охране законами об авторском праве, о правах на топологию и/или другими законами о защите интеллектуальной собственности. Соответствующие владельцы такой интеллектуальной собственности не возражают против факсимильного воспроизведения изобретения путем публикации в досье/документах патентных ведомств, но в остальном резервирует все права.
Притязания на приоритет
Заявитель настоящим притязает на приоритет предварительной патентной заявки США 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 с заказом на покупку для сервера торговца:
Figure 00000001
Figure 00000002
Figure 00000003
В некоторых вариантах осуществления сервер торговца может получать сообщение с заказом на покупку от клиента и может проводить его синтаксический анализ с целью извлечения подробностей поступившего от пользователя заказа на покупку. На основании анализа сервер торговца может определять, что сообщение с заказом на покупку не токенизировано, например, на шаге 414. После определения того, что сообщение с заказом на покупку не токенизировано, сервер торговца может определять, что пользователю требуется предоставить возможность зарегистрироваться с целью получения услуг токенизации платежей. Сервер торговца может попытаться идентифицировать арбитратора токенов для предоставления пользователю услуг токенизации платежей. Например, сервер торговца может запрашивать, например, на шаге 415 в базе данных торговца, например, 404 адрес арбитратора токенов. Например, сервер торговца может использовать сценарий гипертекстовой предобработки (РНР), содержащий команды на языке структурированных запросов (SQL), для запроса адреса арбитратора токенов в реляционной базе данных. Далее приведен один из примеров листинга команд PHP/SQL с целью запроса адреса арбитратора токенов в базе данных:
Figure 00000004
В ответ база данных торговца может предоставить адрес арбитратора токенов, например, на шаге 416. Сервер торговца может генерировать запрос с предложением токенизации от имени пользователя, например, на шаге 417 и передавать запрос с предложением токенизации серверу токенов, например, 405. Например, сервер торговца может передавать сообщение POST по протоколу HTTP(S), содержащее запрос с предложением токенизации согласно приведенному далее примеру:
Figure 00000005
В некоторых вариантах осуществления сервер токенов может проводить синтаксический анализ сообщения, содержащего запрос с предложением токенизации, с целью извлечения из него подробностей, касающихся пользователя и клиента. Сервер токенов может генерировать, например, на шаге 419, предложение токенизации и форму заявления для заполнения пользователем с целью подписки на услуги токенизации. Сервер токенов может передавать клиенту (непосредственно клиенту или через сервер торговца), например, предложение токенизации и форму 420 заявления. Например, сервер токенов передавать сообщение HTTP(S) POST, содержащее данные на языке XML, отображающие форму 420 ввода токенизации, такое как сообщение HTTP(S) POST согласно приведенному далее примеру:
Figure 00000006
Figure 00000007
Клиент может воспроизводить, например, на шаге 421, предложение токенизации и форму заявления и отображать для пользователя, например, на шаге 422 предложение токенизации и форму заявления о создании токена, например, 423.
В некоторых вариантах осуществления пользователь может пожелать зарегистрироваться с целью подписки на услуги токенизации платежей и может заполнить форму 423 заявления о создании токена путем ввода данных. Клиент может генерировать заполненную форму заявления и передать серверу токенов (непосредственно или через сервер торговца) заявление о создании токена, например 424. Например, клиент может использовать сообщение HTTP(S) POST для заявления 424 о создании токена согласно приведенному далее примеру:
Figure 00000008
Figure 00000009
Сервер токенов может получать форму заявления и проводить ее синтаксический анализ, чтобы извлечь из нее поля и значения данных для генерирования записи данных токена, например, 425. Сервер токенов также может задавать набор правил конфиденциальности, ограничений, правил обработки транзакций (например, в какой стране должны находиться серверы, участвующие в обработке транзакций) и т.д., применимых к токену, созданному для пользователя. Например, такими ограничениями может быть установлено, что все транзакции с использованием токена могут обрабатываться только серверами (например, платежей), находящимися на территории определенной страны. В качестве другого примера, ограничения могут обновляться (например, периодически, автоматически, по требованию) в соответствии с законами о неприкосновенности личной жизни и/или другими законами, регламентирующими обработку транзакций в этой стране. В качестве другого примера, ограничениями могут устанавливаться весовые коэффициенты для различных факторов (например, выравнивания связанной с обработкой транзакций нагрузки на сервер, перегрузки сети, ограничений по конфиденциальности, ограничений по защите и т.д.), и может требоваться взвешивание факторов (например, путем вычисления средневзвешенного показателя на основании факторов), чтобы определять страну, в которой должна выполняться обработка транзакции с использованием токена. В качестве другого примера, для токена может быть установлен набор стран, в которых (не) может обрабатываться транзакция. Лишь в качестве неограничивающего пояснения, в приведенной далее структуре данных на языке проиллюстрирован пример правил 427, которые могут создаваться для токена и храниться в таблице (смотри, например, таблицу правил 1519n конфиденциальности на фиг.15) в базе 406b данных правил конфиденциальности:
Figure 00000010
Figure 00000011
Например, правилами может устанавливаться, где должны совершаться платежные операции, чтобы предотвратить использование не подлежащей огласке платежной информации пользователя вне территорий, предписанных правилами конфиденциальности. Например, в некоторых странах с жесткими мерами контроля конфиденциальности требуется, чтобы обработка платежей совершалась только в стране, в которой у пользователя имеется счет (смотри далее правило 1); в других странах мерами контроля конфиденциальности может требоваться, чтобы обработка платежей совершалась только в определенном регионе (например, в любой стране ЕС, смотри далее правило 2); в других странах могут отсутствовать ограничения по конфиденциальности, и обработка платежей может совершаться по существу где угодно (например, смотри далее правило 3) и могут существовать правила, способствующие выравниванию нагрузку и повышению производительности сетей за счет делегирования обработки менее загруженным серверам (например, смотри далее правило 4).
Figure 00000012
Figure 00000013
В некоторых вариантах осуществления пользователь может задавать собственные установочные параметры, отменяющие установки по умолчанию, которые могут использоваться сервером токенов на основании местоположения эмитента(-ов) источников финансирования, лежащих в основе токена. Если пользователь использует собственные установочные параметры для отмены установок по умолчанию, используемых сервером токенов, в некоторых вариантах осуществления сервер токенов может осуществлять их проверку на наличие ошибок, чтобы гарантировать их внутреннюю непротиворечивость, соответствие применимым законам и правилам и/или согласованность с установленной по умолчанию перегрузкой сети и правилами выравнивания нагрузки на серверы при обработке транзакций в платежных сетях, активизируемых источниками финансирования, лежащими в основе токена. Кроме того, в некоторых вариантах осуществления для токена могут отсутствовать правила конфиденциальности, но он может иметь уникальный идентификатор, который может использоваться РРТ для запроса базы данных защитных кодов стран с целью идентификации страны постоянного местожительства и установленных в ней ограничений по конфиденциальности на основании владельца токена; например, на основании однозначно идентифицирующей пользователя информации (например, идентификатора счета, сочетаний уникального имени/адреса/возраста/и т.д., номера социального страхования, и/или т.п.) может генерироваться хеш-токена, который по существу является уникальным для этого пользователя и служит основой запроса, который может использоваться для идентификации страны постоянного местожительства пользователя, и впоследствии правила конфиденциальности, релевантные для этой страны постоянного местожительства, могут применяться для маршрутизации платежной разрешающей способности токена.
Сервер токенов может сохранять данные, извлеченные из формы заявления, в базе данных токенов, например, 406а, а установочные параметры 427 конфиденциальности/ограничений - в базе 406b данных правил конфиденциальности. Например, сервер токенов подавать команды PHP/SQL согласно приведенному далее примеру:
Figure 00000014
На фиг.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 согласно приведенном далее примеру:
Figure 00000015
Figure 00000016
Figure 00000017
Figure 00000018
Figure 00000019
Сервер токенов также может задавать набор правил конфиденциальности, ограничений, правил обработки транзакций (например, в какой стране должны находиться серверы, участвующие в обработке транзакций) и т.д., применимых к токену, созданному для пользователя. Сервер токенов может сохранять структуру данных токена в базе данных токенов, а установочные параметры конфиденциальности/ограничения/ - в базе данных правил конфиденциальности, например, на шаге 516. Сервер токенов также может предоставлять клиенту идентификатор токена, например, на шаге 517. Токен может предоставляться клиентскому устройству в виде структуры данных посредством сообщения POST по протоколу HTTP(S), в виде файла (по протоколам передачи файлов), в виде вложения (например, по электронной почте) и/или иным способом для последующего использования. Клиент сохранять идентификатор токена и/или отображать идентификатор токена для пользователя, например, на шаге 518.
На фиг.6А-Д показаны схемы потоков данных, иллюстрирующие один из примеров процедуры выполнения токенизированной транзакции покупки в некоторых вариантах осуществления РРТ. В некоторых вариантах осуществления пользователь, например, 601, может пожелать приобрести товар, услугу, рыночное изделие, и/или т.п. (продукт) у торговца. Пользователь может связываться с сервером торговца, например, 603а посредством клиента, включая без ограничения персональный компьютер, мобильное устройство, телевизионный приемник, торговый терминал, киоск, банкомат, и/или т.п. (например, 602). Например, пользователь может вводить в клиента данные, например, данные покупки на шаге 611 с указанием желания пользователя приобрести продукт. В различных вариантах осуществления ввод данных пользователем может включать без ограничения: ввод с клавиатуры, считывание карты, активацию поддерживающего RFID/NFC аппаратного устройства (например, электронной карты с множеством счетов, смартфона, планшета и т.д.), щелчки клавишей мыши, нажатие кнопок на джойстике/игровой приставке, речевые команды, одно/многоточечные жесты на сенсорном интерфейсе, касание пользователем элементов интерфейса на сенсорном дисплее и/или т.п. Например, пользователь может адресовать просмотровое приложение, выполняемое в клиентском устройстве, на веб-сайт торговца и может выбирать продукт с веб-сайт путем щелчка по гиперссылке, представляемой пользователю посредством веб-сайта. В качестве другого примера, клиент может извлекать дорожку 1 данных из карты пользователя (например, кредитной карты, дебетовой карты, предоплаченной карты, платежной карты и т.д.), такие как дорожка 1 данных согласно приведенному далее примеру:
Figure 00000020
В некоторых вариантах осуществления клиент может генерировать сообщение с заказом на покупку, например, на шаге 612 и передавать, например, на шаге 613 генерированное сообщение с заказом на покупку серверу торговца. Например, просмотровое приложение, выполняемое в клиенте, может от лица пользователя передавать серверу торговца сообщение GET по протоколу протоколу (защищенной) передачи гипертекстов (HTTP(S)), содержащее подробности заказа продукта, в виде данных расширяемого языка разметки гипертекста (XML). Далее приведен пример сообщения GET по протоколу HTTP(S), содержащего сообщение на языке XML с заказом на покупку для сервера торговца:
Figure 00000021
Figure 00000022
В некоторых вариантах осуществления сервер торговца может получать от клиента сообщение с заказом на покупку и проводить его синтаксический анализ с целью извлечения подробностей поступившего от пользователя заказа на покупку. На основании анализа сервер торговца может определять, что сообщение с заказом на покупку токенизировано. Сервер торговца запросить на шаге 615 базу данных, например, базу данных торговца, например, 604 с целью определения арбитратора для обработки токенизированного заказа на покупку. Например, сервер торговца может использовать сценарий гипертекстовой предобработки (РНР), содержащий команды на языке структурированных запросов (SQL), для запроса адреса арбитратора токенов в реляционной базе данных. Далее приведен один из примеров листинга команд PHP/SQL с целью запроса адреса арбитратора токенов в базе данных:
Figure 00000023
В ответ база данных торговца может предоставить адрес арбитратора токенов, например, 616. Сервер торговца генерировать запрос арбитража токенов, например, на шаге 617 и передать запрос арбитража токенов, например, на шаге 618 серверу токенов, например, 605. Например, сервер торговца может передавать сообщение POST по протоколу HTTP(S), содержащее запрос арбитража токенов, согласно приведенному далее примеру:
Figure 00000024
Figure 00000025
Figure 00000026
В различных вариантах осуществления сервер токенов может являться частью системы торговца (например, процесса торговли) или частью платежной сети (например, сервера платежной сети) или может представлять собой независимый сервер, взаимодействующий с торговцем, эмитентом, торговым банком и платежной сетью. В целом, подразумевается, что арбитратором токенов может служить любой объект и/или компонент, входящий в РРТ. В некоторых вариантах осуществления сервер токенов может проводить синтаксический анализ сообщения с запросом арбитража токенов и извлекать из него платежный токен. Сервер токенов может определять опции платежа для использования (или определять, следует ли запросить у пользователя подробности опций платежа) при обработке транзакция с использованием платежного токена. Например, сервер токенов может передавать, например, на шаге 619 базе данных, например, базе 606 данных токенов запрос эмитента пользователя с использованием в запросе платежного токена в качестве элемент поиска. Например, сервер токенов может использовать команды PHP/SQL по аналогии с описанными выше примерами. В ответ база данных токенов может предоставлять, например, на шаге 620, данные эмитентов, с которыми следует связаться в связи с платежом. Например, в ответе с данными эмитентов может содержаться файл данных на языке XML с предназначенными для сервера токенов указаниями по обработке платежей по транзакции. Далее приведен один из примеров файла данных эмитента на языке XML:
Figure 00000027
Figure 00000028
В некоторых вариантах осуществления сервер токенов может определять, например, на шаге 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, иллюстрирующий существенные особенности запросов базы данных:
Figure 00000029
В ответ на запрос сервера эмитента, например, 635 база данных платежной сети может передавать, например, на шаге 636 серверу платежной сети запрошенные данные сервера эмитента. В некоторых вариантах осуществления сервер платежной сети может использовать данные сервера эмитента, чтобы генерировать, например, на шаге 637, запрос(-ы) авторизации каждого из серверов эмитентов, выбранного на основании предварительно заданных установочных параметров, связанных с токеном, и/или введенных пользователем опций платежа, и передавать запрос(-ы) авторизации карты, например, 638a-n, серверу(-ам) эмитентов, например, 609a-n. В некоторых вариантах осуществления запрос(-ы) авторизации может содержать подробности, включающие без ограничения расходы пользователя, участвующего в транзакции, подробности карточного счета пользователя, сведения о выставлении счетов пользователю и/или отправке и/или т.п. Например, сервер платежной сети может передавать сообщение POST по протоколу HTTP(S), содержащее запрос авторизации на языке XML, согласно приведенному далее примеру:
Figure 00000030
Figure 00000031
В некоторых вариантах осуществления сервер эмитента может проводить синтаксический анализ запроса(-ов) авторизации и на основании подробностей запроса может запрашивать в базе данных, например, базе 610a-n данных профилей пользователей данные, касающиеся счета, привязанного к платежному токену пользователя. Например, сервер эмитента может передавать команды PHP/SQL согласно приведенному далее примеру:
Figure 00000032
Figure 00000033
В некоторых вариантах осуществления после получения пользовательских данных, например, 640a-n сервер эмитента может определять, например, на шаге 641a-n, может ли пользователь оплатить транзакцию с использованием средств, доступных на счете. Например, сервер эмитента может определять, достаточен ли остаток на счете пользователе, достаточен кредит по счету и/или т.п. В зависимости от результата сервер(-ы) эмитентов может передавать, например, на шаге 642a-n ответ на запрос авторизации серверу платежной сети. Например, сервер(-ы) эмитентов может передавать сообщение POST по протоколу HTTP(S) по аналогии с приведенными выше примерами. Если, по меньшей мере, один сервер эмитента установит, что пользователь не способен оплатить транзакцию с использованием средств, доступных на счете, например, на шагах 643, 644, в некоторых вариантах осуществления сервер платежной сети может снова запросить у пользователя опции платежа (например, путем передачи серверу токенов сообщения 644 о неудачной попытке авторизации, чтобы сервер токенов снова получил от пользователя опции платежа) и может повторить попытку авторизации для совершения транзакция покупки. Если число неудачных попыток авторизации превысит определенный предел, в некоторых вариантах осуществления сервер платежной сети может отказаться от выполнения процедуры авторизации и передать серверу торговца, серверу токенов и/или клиенту сообщение "авторизация не удалась".
В некоторых вариантах осуществления сервер платежной сети может получать сообщение об авторизации, содержащее уведомление об успешной авторизации, например, на шагах 643, 646 и проводить синтаксический анализ сообщения с целью извлечения подробностей авторизации. После того, как установлено, что пользователь имеет достаточно средств для совершения транзакции, сервер платежной сети может генерировать запись данных транзакции, например, 645 на основании запроса авторизации и/или ответа на запрос авторизации и сохранять подробности транзакции и авторизации, связанной с транзакцией, в базе данных транзакций. Например, чтобы сохранить данные транзакции базе данных, сервер платежной сети может передавать команды PHP/SQL согласно приведенном далее примеру:
Figure 00000034
Figure 00000035
В некоторых вариантах осуществления сервер платежной сети может пересылать сообщение об успешной авторизации, например, 646 серверу токенов, который в свою очередь может пересылать сообщение об успешной авторизации, например, 647 серверу торговца. Торговец может получать сообщение об авторизации и на его основании определять, что пользователь имеет достаточно средств на карточном счете для совершения транзакции. Сервер торговца может вносить дополнительную запись о транзакции пользователя в данные группы транзакций авторизованных транзакций. Например, торговец может присоединять, например, на шаге 648 данные на языке XML, касающиеся транзакции пользователя, к файлу данных на языке XML, содержащему данные группы транзакций, которые были авторизованы для различных пользователей, и сохранять, например, на шаге 649 файл данных на языке XML в базе данных, например, базе 604 данных торговца. Например, файл данных на языке XML может иметь структуру, сходную с приведенным далее примером образца структуры данных на языке XML:
Figure 00000036
Figure 00000037
В некоторых вариантах осуществления сервер также может генерировать, например, на шаге 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) согласно приведенному далее примеру:
Figure 00000038
Figure 00000039
В некоторых вариантах осуществления сервер эмитента может генерировать команду оплаты, например, на шаге 666. Например, сервер эмитента может передавать команду снятия средств со счета пользователя (или списания со счета кредитной карты пользователя). Сервер эмитента может передавать команду оплаты, например, на шаге 667 базе данных, в которой хранятся данные счета пользователя, например, базе 610 данных профилей пользователей. Сервер эмитента может передавать сообщение о переводе средств, например, на шаге 668 серверу платежной сети, который может пересылать его, например, на шаге 669 торговому банку сервер. Далее приведено один из примеров сообщения POST о переводе средств по протоколу HTTP(S):
Figure 00000040
Figure 00000041
В некоторых вариантах осуществления сервер торгового банка может проводить синтаксический анализ сообщения о переводе средств и сопоставлять увязывать (например, с использованием поля 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, например:
Figure 00000042
где Valuel рассматривается как параметр, поскольку "http://" является частью синтаксиса, а то, что следует далее, рассматривается как часть значения post. Аналогичным образом, при использовании такой грамматики переменная величина "Valuel" может вводиться в "http://" команду post и затем передаваться. Сам синтаксис может быть представлен как структурированные данные, которые интерпретируются или иным образом используются, чтобы генерировать механизм синтаксического анализа (например, текстовой файл описания синтаксиса для обработки посредством lex, yacc и т.д.). Кроме того, после того как генерирован и/или создан экземпляр механизма синтаксического анализа, он сам может обрабатывать и/или проводить синтаксический анализ структурированных данных, включая без ограничения представленный символами (например, ярлыками) текст, HTML, структурированные текстовые потоки, XML и/или тому подобные структурированные данные. В другом варианте осуществления сами протоколу обработки данных между приложениями могут содержать интегрированные и/или легкодоступные синтаксические анализаторы (например, JSON, SOAP и/или тому подобные синтаксические анализаторы), которые могут применяться для проведения синтаксического анализа данных (например, сообщений). Кроме того, помимо анализа сообщения также может использоваться грамматически анализ баз данных, совокупностей данных, складов данных, структурированных данных и/или т.п. И в этом случае желаемая конфигурация зависит от контекста, среды и требований к развертыванию системы.
Например, в некоторых вариантах осуществления контроллер РРТ может выполнять сценарий РНР, в котором посредством информационного сервера реализован сервер соединений по протоколу безопасных соединений (SSL), прослушивающий входящие сообщения в порте, на который клиент может отправлять данные, например, данные, закодированные в формате JSON. После обнаружения входящего сообщения оно может считываться его из клиентского устройства, может проводиться синтаксический анализ принятых текстовых данных, закодированных в формате JSON, с целью извлечения информации и ее преобразования в переменные величины РНР, и данные (например, идентифицирующая клиента информация и т.д.) и/или извлеченная информация может сохраняться в реляционной базе данных, доступной с использованием языка структурированных запросов (SQL). Далее приведен один из примеров листинга, записанного преимущественно в форме команд PHP/SQL приема закодированных в формате JSON входных данных от клиентского устройства посредством соединения по протоколу SSL, синтаксического анализа данных с целью извлечения переменных величин и сохранения данных в базе данных:
Figure 00000043
Figure 00000044
Figure 00000045
Кроме того, в настоящее описание в прямой форме в порядке ссылки включены следующие ресурсы, которые могут использоваться в примерах реализации синтаксического анализатора SOAP:
Figure 00000046
и других реализаций синтаксического анализатора:
Figure 00000047
.
В настоящей заявке (включая титульный лист, название, заголовки, разделы Область техники, к которой относится изобретение, Предпосылки создания изобретения, Краткое изложение сущности изобретения, Краткое описание чертежей, Подробное описание, Формулу изобретения, Реферат, Чертежи, Приложения и/или иное) проиллюстрированы различные возможные варианты осуществления заявленных изобретений на практике. Преимущества и признаки изобретений лишь наглядно отображают варианты осуществления и не являются исчерпывающими и/или исключительными. Они представлены лишь для облечения понимания и разъяснения заявленных принципов. Подразумевается, что они не отображают всех заявленных изобретений. По существу, некоторые особенности изобретений не были рассмотрены в описании. Тот факт, что могли быть не раскрыты альтернативные варианты осуществления конкретной части изобретений или дополнительные неописанные альтернативные варианты осуществления части изобретений, которые могут существовать, не должен рассматриваться как отказ от прав на эти альтернативные варианты осуществления. Следует учесть, что во многих из этих неописанных вариантов осуществления содержаться такие же принципы изобретения, а другие варианты осуществления являются эквивалентными. Так, подразумевается, что могут использоваться другие варианты осуществления, и возможны функциональные, логические, организационные, структурные и/или топологические модификации, не выходящие за пределы существа и/или объема изобретения. Все примеры и/или варианты осуществления считаются неограничивающими изобретения. Кроме того, что касается не рассмотренных в описании вариантов осуществления, они опущены лишь для краткости и во избежание повторов. Так, подразумевается, что логическая и/или топологическая структура любого сочетания любых программных компонентов (совокупности компонентов), другие компоненты и/или любые существующие сочетания признаков, проиллюстрированные на чертежах и/или в описании, на ограничены фиксированным порядком и/или расположением, любой описанный порядок является примером, и описанием предусмотрены все эквиваленты независимо от порядка. Помимо этого, подразумевается, что такие признаки не ограничены последовательным выполнением, описанием предусмотрено любое число потоков, процессов, услуг, серверов и/или т.п., которые могут выполняться асинхронно, одновременно, параллельно, совместно, синхронно и/или т.п. Некоторые из этих признаков могут являться по существу взаимно противоречащими в том смысле, что они могут одновременно присутствовать в одном варианте осуществления. Аналогичным образом, некоторые признаки применимы к одной особенности изобретения и неприменимы к другим особенностям. Кроме того, в описание входят другие изобретения, не заявленные в настоящей заявке. Заявитель оставляет за собой все права на такие не заявленные в данный момент изобретения, включая право притязания на такие изобретения, подачи дополнительных заявок, продолжающих заявок, частично продолжающих заявок, выделенных заявок и/или т.п. Подразумевается, что преимущества, варианты осуществления, примеры, функции, признаки, логические, организационные, структурные, топологические и/или другие особенности описания не должны считаться ограничивающими изобретение, охарактеризованное его формулой, или ограничивающими эквиваленты формул изобретения. Подразумевается, что в зависимости от конкретных потребностей и/или характеристик индивидуального и/или корпоративного пользователя РРТ, конфигурации и/или реляционной модели баз данных, типа данных, структуры передачи данных и/или сетей, синтаксической структуры и/или т.п. могут быть реализованы различные варианты осуществления РРТ, обеспечивающие высокую степень гибкости и соответствия требованиям заказчика. Например, особенности РРТ могут быть приспособлены к алгоритмам сжатия, система обеспечения безопасности, оптимизации связи, и/или т.п. Хотя в различных вариантах осуществления и при рассмотрении РРТ речь шла о транзакциях покупки, тем не менее, подразумевается, что описанные варианты осуществления могут быть легко сконфигурированы и/или приспособлены к самым разнообразным применениям и/или реализациям.

Claims (120)

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, в которой выбор местоположения в заданной стране для обработки запроса покупки включает установление того, что первая страна неприемлема для обработки запроса покупки согласно набору правил с требованиями сохранения конфиденциальности, и выбор второй страны, приемлемой для обработки запроса покупки на основании набора правил с требованиями сохранения конфиденциальности.
RU2013158683/08A 2011-06-07 2012-06-07 Устройства, способы и системы токенизации конфиденциальности платежей RU2602394C2 (ru)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201161494402P 2011-06-07 2011-06-07
US61/494,402 2011-06-07
PCT/US2012/041437 WO2013101297A1 (en) 2011-06-07 2012-06-07 Payment privacy tokenization apparatuses, methods and systems

Publications (2)

Publication Number Publication Date
RU2013158683A RU2013158683A (ru) 2015-07-20
RU2602394C2 true RU2602394C2 (ru) 2016-11-20

Family

ID=47293969

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2013158683/08A RU2602394C2 (ru) 2011-06-07 2012-06-07 Устройства, способы и системы токенизации конфиденциальности платежей

Country Status (6)

Country Link
US (1) US20120316992A1 (ru)
EP (1) EP2718886A4 (ru)
CN (1) CN103765454B (ru)
AU (1) AU2012363110A1 (ru)
RU (1) RU2602394C2 (ru)
WO (1) WO2013101297A1 (ru)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2693638C1 (ru) * 2017-08-08 2019-07-03 Общество с ограниченной ответственностью "Цифровой Платеж" Способ оплаты товара и (или) услуги с помощью мобильного терминала
RU2730417C1 (ru) * 2019-05-24 2020-08-21 Петр Анатольевич Беликов Способ онлайн-продаж товаров и услуг и вендинговое устройство, реализующее способ
RU2736507C1 (ru) * 2019-09-18 2020-11-17 Александр Юрьевич Баранов Способ и система создания и использования доверенного цифрового образа документа и цифровой образ документа, созданный данным способом
US20230012458A1 (en) * 2021-07-07 2023-01-12 Paypal, Inc. Identifying transaction processing retry attempts based on machine learning models for transaction success
RU2792695C2 (ru) * 2018-07-03 2023-03-23 Виза Интернэшнл Сервис Ассосиэйшн Синхронизация состояния маркера
US11847233B2 (en) 2018-07-03 2023-12-19 Visa International Service Association Token state synchronization

Families Citing this family (394)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2003209194A1 (en) 2002-01-08 2003-07-24 Seven Networks, Inc. Secure transport for mobile communication network
US20140019352A1 (en) 2011-02-22 2014-01-16 Visa International Service Association Multi-purpose virtual card transaction apparatuses, methods and systems
US8438633B1 (en) 2005-04-21 2013-05-07 Seven Networks, Inc. Flexible real-time inbox access
WO2006136660A1 (en) 2005-06-21 2006-12-28 Seven Networks International Oy Maintaining an ip connection in a mobile network
EP1920393A2 (en) * 2005-07-22 2008-05-14 Yogesh Chunilal Rathod Universal knowledge management and desktop search system
US8762263B2 (en) 2005-09-06 2014-06-24 Visa U.S.A. Inc. System and method for secured account numbers in proximity devices
US8805425B2 (en) 2007-06-01 2014-08-12 Seven Networks, Inc. Integrated messaging
US8121956B2 (en) 2007-06-25 2012-02-21 Visa U.S.A. Inc. Cardless challenge systems and methods
US7739169B2 (en) 2007-06-25 2010-06-15 Visa U.S.A. Inc. Restricting access to compromised account information
US7937324B2 (en) 2007-09-13 2011-05-03 Visa U.S.A. Inc. Account permanence
US9002828B2 (en) 2007-12-13 2015-04-07 Seven Networks, Inc. Predictive content delivery
US8862657B2 (en) 2008-01-25 2014-10-14 Seven Networks, Inc. Policy based content service
US20090193338A1 (en) 2008-01-28 2009-07-30 Trevor Fiatal Reducing network and battery consumption during content delivery and playback
US9704161B1 (en) * 2008-06-27 2017-07-11 Amazon Technologies, Inc. Providing information without authentication
US8788945B1 (en) 2008-06-30 2014-07-22 Amazon Technologies, Inc. Automatic approval
US9449319B1 (en) 2008-06-30 2016-09-20 Amazon Technologies, Inc. Conducting transactions with dynamic passwords
US8219489B2 (en) 2008-07-29 2012-07-10 Visa U.S.A. Inc. Transaction processing using a global unique identifier
AU2009311303B2 (en) 2008-11-06 2015-09-10 Visa International Service Association Online challenge-response
US9715681B2 (en) 2009-04-28 2017-07-25 Visa International Service Association Verification of portable consumer devices
US8602293B2 (en) 2009-05-15 2013-12-10 Visa International Service Association Integration of verification tokens with portable computing devices
US9105027B2 (en) 2009-05-15 2015-08-11 Visa International Service Association Verification of portable consumer device for secure services
US9038886B2 (en) 2009-05-15 2015-05-26 Visa International Service Association Verification of portable consumer devices
US10846683B2 (en) 2009-05-15 2020-11-24 Visa International Service Association Integration of verification tokens with mobile communication devices
US8534564B2 (en) 2009-05-15 2013-09-17 Ayman Hammad Integration of verification tokens with mobile communication devices
US7891560B2 (en) 2009-05-15 2011-02-22 Visa International Service Assocation Verification of portable consumer devices
US8893967B2 (en) 2009-05-15 2014-11-25 Visa International Service Association Secure Communication of payment information to merchants using a verification token
US10140598B2 (en) 2009-05-20 2018-11-27 Visa International Service Association Device including encrypted data for expiration date and verification value creation
US10255591B2 (en) 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
AU2011205391B2 (en) 2010-01-12 2014-11-20 Visa International Service Association Anytime validation for verification tokens
US10255601B2 (en) 2010-02-25 2019-04-09 Visa International Service Association Multifactor authentication using a directory server
US9245267B2 (en) 2010-03-03 2016-01-26 Visa International Service Association Portable account number for consumer payment account
US8838783B2 (en) 2010-07-26 2014-09-16 Seven Networks, Inc. Distributed caching for resource and mobile network traffic management
PL3407673T3 (pl) 2010-07-26 2020-05-18 Seven Networks, Llc Koordynacja ruchu w sieci komórkowej pomiędzy różnymi aplikacjami
US9342832B2 (en) 2010-08-12 2016-05-17 Visa International Service Association Securing external systems with account token substitution
US8843153B2 (en) 2010-11-01 2014-09-23 Seven Networks, Inc. Mobile traffic categorization and policy for network use optimization while preserving user experience
WO2012060995A2 (en) 2010-11-01 2012-05-10 Michael Luna Distributed caching in a wireless network of content delivered for a mobile application over a long-held request
BR112013021059A2 (pt) 2011-02-16 2020-10-27 Visa International Service Association sistemas, métodos e aparelhos de pagamento móvel por snap
US10586227B2 (en) 2011-02-16 2020-03-10 Visa International Service Association Snap mobile payment apparatuses, methods and systems
AU2012220669A1 (en) 2011-02-22 2013-05-02 Visa International Service Association Universal electronic payment apparatuses, methods and systems
CN107967602A (zh) 2011-03-04 2018-04-27 维萨国际服务协会 支付能力结合至计算机的安全元件
US9280765B2 (en) 2011-04-11 2016-03-08 Visa International Service Association Multiple tokenization for authentication
US8538845B2 (en) 2011-06-03 2013-09-17 Mozido, Llc Monetary transaction system
US9355393B2 (en) 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
WO2013006725A2 (en) 2011-07-05 2013-01-10 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
US20130159154A1 (en) * 2011-08-18 2013-06-20 Thomas Purves Wallet service enrollment platform apparatuses, methods and systems
US9582598B2 (en) 2011-07-05 2017-02-28 Visa International Service Association Hybrid applications utilizing distributed models and views apparatuses, methods and systems
US20130018759A1 (en) * 2011-07-13 2013-01-17 Ebay Inc. Third party token system for anonymous shipping
WO2013019567A2 (en) 2011-07-29 2013-02-07 Visa International Service Association Passing payment tokens through an hop/sop
US10825001B2 (en) 2011-08-18 2020-11-03 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US10242358B2 (en) 2011-08-18 2019-03-26 Visa International Service Association Remote decoupled application persistent state apparatuses, methods and systems
US9710807B2 (en) 2011-08-18 2017-07-18 Visa International Service Association Third-party value added wallet features and interfaces apparatuses, methods and systems
WO2013029014A2 (en) 2011-08-24 2013-02-28 Visa International Service Association Method for using barcodes and mobile devices to conduct payment transactions
US10223730B2 (en) 2011-09-23 2019-03-05 Visa International Service Association E-wallet store injection search apparatuses, methods and systems
US10438196B2 (en) 2011-11-21 2019-10-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
US9208488B2 (en) 2011-11-21 2015-12-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
WO2013086225A1 (en) 2011-12-06 2013-06-13 Seven Networks, Inc. A mobile device and method to utilize the failover mechanisms for fault tolerance provided for mobile traffic management and network/device resource conservation
US8934414B2 (en) 2011-12-06 2015-01-13 Seven Networks, Inc. Cellular or WiFi mobile traffic optimization based on public or private network destination
EP2788889A4 (en) 2011-12-07 2015-08-12 Seven Networks Inc FLEXIBLE AND DYNAMIC INTEGRATION SCHEMES OF A TRAFFIC MANAGEMENT SYSTEM WITH VARIOUS NETWORK OPERATORS TO REDUCE NETWORK TRAFFIC
CN103186853B (zh) * 2011-12-31 2016-07-13 北大方正集团有限公司 一种服务器端和客户端移动支付方法、装置及系统
US10223710B2 (en) 2013-01-04 2019-03-05 Visa International Service Association Wearable intelligent vision device apparatuses, methods and systems
RU2631983C2 (ru) 2012-01-05 2017-09-29 Виза Интернэшнл Сервис Ассосиэйшн Защита данных с переводом
US9830595B2 (en) 2012-01-26 2017-11-28 Visa International Service Association System and method of providing tokenization as a service
AU2013214801B2 (en) 2012-02-02 2018-06-21 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems
US8893250B2 (en) 2012-02-10 2014-11-18 Protegrity Corporation Tokenization in mobile environments
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
WO2013134832A1 (en) * 2012-03-15 2013-09-19 Mikoh Corporation A biometric authentication system
US9202086B1 (en) * 2012-03-30 2015-12-01 Protegrity Corporation Tokenization in a centralized tokenization environment
US8812695B2 (en) 2012-04-09 2014-08-19 Seven Networks, Inc. Method and system for management of a virtual network connection without heartbeat messages
US20130282588A1 (en) * 2012-04-22 2013-10-24 John Hruska Consumer, Merchant and Mobile Device Specific, Real-Time Dynamic Tokenization Activation within a Secure Mobile-Wallet Financial Transaction System
GB2501478A (en) * 2012-04-23 2013-10-30 Icheque Network Ltd Verification of electronic payment
WO2013166501A1 (en) 2012-05-04 2013-11-07 Visa International Service Association System and method for local data conversion
US9524501B2 (en) 2012-06-06 2016-12-20 Visa International Service Association Method and system for correlating diverse transaction data
US9547769B2 (en) 2012-07-03 2017-01-17 Visa International Service Association Data protection hub
US8775631B2 (en) 2012-07-13 2014-07-08 Seven Networks, Inc. Dynamic bandwidth adjustment for browsing or streaming activity in a wireless network based on prediction of user behavior when interacting with mobile applications
US20140025585A1 (en) * 2012-07-19 2014-01-23 Bank Of America Corporation Distributing authorized tokens to conduct mobile transactions
US9043609B2 (en) * 2012-07-19 2015-05-26 Bank Of America Corporation Implementing security measures for authorized tokens used in mobile transactions
US9846861B2 (en) 2012-07-25 2017-12-19 Visa International Service Association Upstream and downstream data conversion
US9256871B2 (en) 2012-07-26 2016-02-09 Visa U.S.A. Inc. Configurable payment tokens
US9311672B2 (en) * 2012-08-09 2016-04-12 American Express Travel Related Services Company, Inc. Systems and methods for fraud detection using a cooperative data exchange
US10521819B2 (en) 2012-08-09 2019-12-31 American Express Travel Related Services Company, Inc. Systems and methods for analytics in a cooperative data exchange
US9665722B2 (en) 2012-08-10 2017-05-30 Visa International Service Association Privacy firewall
AU2013315510B2 (en) 2012-09-11 2019-08-22 Visa International Service Association Cloud-based Virtual Wallet NFC Apparatuses, methods and systems
US9355392B2 (en) * 2012-09-14 2016-05-31 Bank Of America Corporation Gift card association with account
US20140108264A1 (en) * 2012-10-17 2014-04-17 Tencent Technology (Shenzhen) Company Limited Service interaction method of flash service platform and corresponding flash service platform
US9082119B2 (en) 2012-10-17 2015-07-14 Royal Bank of Canada. Virtualization and secure processing of data
US11080701B2 (en) 2015-07-02 2021-08-03 Royal Bank Of Canada Secure processing of electronic payments
US11210648B2 (en) 2012-10-17 2021-12-28 Royal Bank Of Canada Systems, methods, and devices for secure generation and processing of data sets representing pre-funded payments
WO2014066559A1 (en) 2012-10-23 2014-05-01 Visa International Service Association Transaction initiation determination system utilizing transaction data elements
US20140122215A1 (en) * 2012-10-26 2014-05-01 Ncr Corporation Techniques to maximize retail traffic
US9911118B2 (en) 2012-11-21 2018-03-06 Visa International Service Association Device pairing via trusted intermediary
GB2508621A (en) * 2012-12-05 2014-06-11 Barclays Bank Plc Mobile payment method
US10304047B2 (en) 2012-12-07 2019-05-28 Visa International Service Association Token generating component
US10592888B1 (en) * 2012-12-17 2020-03-17 Wells Fargo Bank, N.A. Merchant account transaction processing systems and methods
US10740731B2 (en) 2013-01-02 2020-08-11 Visa International Service Association Third party settlement
US9741051B2 (en) 2013-01-02 2017-08-22 Visa International Service Association Tokenization and third-party interaction
US8874761B2 (en) * 2013-01-25 2014-10-28 Seven Networks, Inc. Signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols
US20140244513A1 (en) * 2013-02-22 2014-08-28 Miguel Ballesteros Data protection in near field communications (nfc) transactions
US8750123B1 (en) 2013-03-11 2014-06-10 Seven Networks, Inc. Mobile device equipped with mobile network congestion recognition to make intelligent decisions regarding connecting to an operator network
US8875247B2 (en) * 2013-03-14 2014-10-28 Facebook, Inc. Instant personalization security
US11055710B2 (en) 2013-05-02 2021-07-06 Visa International Service Association Systems and methods for verifying and processing transactions using virtual currency
US11410173B1 (en) * 2013-05-07 2022-08-09 Amazon Technologies, Inc. Tokenization web services
CA2912695A1 (en) 2013-05-15 2014-11-20 Visa International Service Association Mobile tokenization hub
US10387874B1 (en) * 2013-05-30 2019-08-20 Google Llc Mobile transactions with merchant identification codes
US10878422B2 (en) * 2013-06-17 2020-12-29 Visa International Service Association System and method using merchant token
US9621625B2 (en) * 2013-07-11 2017-04-11 Cinarra Systems Method and system for correlation of internet application domain identities and network device identifiers
US9065765B2 (en) 2013-07-22 2015-06-23 Seven Networks, Inc. Proxy server associated with a mobile carrier for enhancing mobile traffic management in a mobile network
AU2014293042A1 (en) 2013-07-24 2016-02-11 Visa International Service Association Systems and methods for communicating risk using token assurance data
CN105518733A (zh) 2013-07-26 2016-04-20 维萨国际服务协会 向消费者提供支付凭证
CN105612543B (zh) 2013-08-08 2022-05-27 维萨国际服务协会 用于为移动设备供应支付凭证的方法和系统
US10496986B2 (en) 2013-08-08 2019-12-03 Visa International Service Association Multi-network tokenization processing
GB2517723A (en) * 2013-08-29 2015-03-04 Belegin Ltd Token verification
US10123063B1 (en) * 2013-09-23 2018-11-06 Comscore, Inc. Protecting user privacy during collection of demographics census data
US11694256B1 (en) 2013-10-10 2023-07-04 Wells Fargo Bank, N.A. Mobile enabled activation of a bank account
US9978094B2 (en) 2013-10-11 2018-05-22 Visa International Service Association Tokenization revocation list
JP6386567B2 (ja) 2013-10-11 2018-09-05 ビザ インターナショナル サービス アソシエーション ネットワーク・トークン・システム
US10515358B2 (en) 2013-10-18 2019-12-24 Visa International Service Association Contextual transaction token methods and systems
US10963906B2 (en) 2013-10-21 2021-03-30 Transform Sr Brands Llc Method and system for optimizing value of consumer offers
US10489779B2 (en) 2013-10-21 2019-11-26 Visa International Service Association Multi-network token bin routing with defined verification parameters
US10366387B2 (en) 2013-10-29 2019-07-30 Visa International Service Association Digital wallet system and method
CN104599126B (zh) * 2013-10-30 2017-04-12 腾讯科技（深圳）有限公司 一种安全支付方法、相关装置及系统
EP3063691B1 (en) 2013-11-01 2020-03-11 Anonos Inc. Dynamic de-identification and anonymity
US11030341B2 (en) 2013-11-01 2021-06-08 Anonos Inc. Systems and methods for enforcing privacy-respectful, trusted communications
US10043035B2 (en) 2013-11-01 2018-08-07 Anonos Inc. Systems and methods for enhancing data protection by anonosizing structured and unstructured data and incorporating machine learning and artificial intelligence in classical and quantum computing environments
US10572684B2 (en) 2013-11-01 2020-02-25 Anonos Inc. Systems and methods for enforcing centralized privacy controls in de-centralized systems
US9087215B2 (en) 2013-11-01 2015-07-21 Anonos Inc. Dynamic de-identification and anonymity
US9619669B2 (en) 2013-11-01 2017-04-11 Anonos Inc. Systems and methods for anonosizing data
US9361481B2 (en) 2013-11-01 2016-06-07 Anonos Inc. Systems and methods for contextualized data protection
US20150142604A1 (en) * 2013-11-18 2015-05-21 Benjamin Kneen Codes with user preferences
AU2014353151B2 (en) 2013-11-19 2018-03-08 Visa International Service Association Automated account provisioning
RU2019111186A (ru) 2013-12-19 2019-05-07 Виза Интернэшнл Сервис Ассосиэйшн Способы и системы облачных транзакций
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
US10433128B2 (en) 2014-01-07 2019-10-01 Visa International Service Association Methods and systems for provisioning multiple devices
US20150199671A1 (en) * 2014-01-13 2015-07-16 Fidelity National E-Banking Services, Inc. Systems and methods for processing cardless transactions
US9846878B2 (en) 2014-01-14 2017-12-19 Visa International Service Association Payment account identifier system
US9965606B2 (en) 2014-02-07 2018-05-08 Bank Of America Corporation Determining user authentication based on user/device interaction
US9223951B2 (en) 2014-02-07 2015-12-29 Bank Of America Corporation User authentication based on other applications
US9208301B2 (en) 2014-02-07 2015-12-08 Bank Of America Corporation Determining user authentication requirements based on the current location of the user in comparison to the users's normal boundary of location
US9647999B2 (en) 2014-02-07 2017-05-09 Bank Of America Corporation Authentication level of function bucket based on circumstances
US9286450B2 (en) 2014-02-07 2016-03-15 Bank Of America Corporation Self-selected user access based on specific authentication types
US20150248673A1 (en) * 2014-02-28 2015-09-03 Sayed Abbas Almohri Methods and apparatus for a token management system for transactions
US9600844B2 (en) 2014-03-04 2017-03-21 Bank Of America Corporation Foreign cross-issued token
US9406065B2 (en) 2014-03-04 2016-08-02 Bank Of America Corporation Customer token preferences interface
US9600817B2 (en) 2014-03-04 2017-03-21 Bank Of America Corporation Foreign exchange token
US9721248B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation ATM token cash withdrawal
US9830597B2 (en) 2014-03-04 2017-11-28 Bank Of America Corporation Formation and funding of a shared token
US9721268B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation Providing offers associated with payment credentials authenticated in a specific digital wallet
US10002352B2 (en) 2014-03-04 2018-06-19 Bank Of America Corporation Digital wallet exposure reduction
US9424572B2 (en) 2014-03-04 2016-08-23 Bank Of America Corporation Online banking digital wallet management
US10026087B2 (en) 2014-04-08 2018-07-17 Visa International Service Association Data passed in an interaction
US9942043B2 (en) 2014-04-23 2018-04-10 Visa International Service Association Token security on a communication device
SG11201608973TA (en) 2014-05-01 2016-11-29 Visa Int Service Ass Data verification using access device
CA2945193A1 (en) 2014-05-05 2015-11-12 Visa International Service Association System and method for token domain control
EP3146747B1 (en) 2014-05-21 2020-07-01 Visa International Service Association Offline authentication
US20150339663A1 (en) * 2014-05-21 2015-11-26 Mastercard International Incorporated Methods of payment token lifecycle management on a mobile device
US9525690B2 (en) * 2014-05-27 2016-12-20 Bank Of Ozarks Securely integrating third-party applications with banking systems
US10586073B1 (en) * 2014-05-27 2020-03-10 Amazon Technologies, Inc. Preserving customer data privacy for merchant orders
US11023890B2 (en) 2014-06-05 2021-06-01 Visa International Service Association Identification and verification for provisioning mobile application
CN104021469A (zh) * 2014-06-13 2014-09-03 捷德（中国）信息科技有限公司 进行支付交易的方法、设备以及系统
SG10201404112WA (en) * 2014-07-16 2016-02-26 Msc Consulting S Pte Ltd Service management method
US9780953B2 (en) 2014-07-23 2017-10-03 Visa International Service Association Systems and methods for secure detokenization
US10484345B2 (en) 2014-07-31 2019-11-19 Visa International Service Association System and method for identity verification across mobile applications
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
US10140615B2 (en) 2014-09-22 2018-11-27 Visa International Service Association Secure mobile device credential provisioning using risk decision non-overrides
EP3198907B1 (en) * 2014-09-26 2019-04-10 Visa International Service Association Remote server encrypted data provisioning system and methods
US11257074B2 (en) 2014-09-29 2022-02-22 Visa International Service Association Transaction risk based token
CN107004190A (zh) * 2014-10-10 2017-08-01 加拿大皇家银行 用于处理电子交易的系统
US10015147B2 (en) 2014-10-22 2018-07-03 Visa International Service Association Token enrollment system and method
GB201419016D0 (en) 2014-10-24 2014-12-10 Visa Europe Ltd Transaction Messaging
US10402794B2 (en) 2014-10-31 2019-09-03 Square, Inc. Money transfer in a forum using a payment proxy
US10325261B2 (en) 2014-11-25 2019-06-18 Visa International Service Association Systems communications with non-sensitive identifiers
CN107004192B (zh) 2014-11-26 2021-08-13 维萨国际服务协会 用于经由访问装置的令牌化请求的方法和设备
WO2016094122A1 (en) 2014-12-12 2016-06-16 Visa International Service Association Provisioning platform for machine-to-machine devices
US9990613B1 (en) 2014-12-12 2018-06-05 Square, Inc. Bill payment using direct funds transfer
US10257185B2 (en) 2014-12-12 2019-04-09 Visa International Service Association Automated access data provisioning
US10373134B1 (en) 2014-12-15 2019-08-06 Wells Fargo Bank, N.A. Scrub and match and payee account match
US10062072B2 (en) 2014-12-19 2018-08-28 Facebook, Inc. Facilitating sending and receiving of peer-to-business payments
EP3035265A1 (en) * 2014-12-19 2016-06-22 Facebook, Inc. Facilitating sending and receiving of peer-to-business payments
US10187363B2 (en) 2014-12-31 2019-01-22 Visa International Service Association Hybrid integration of software development kit with secure execution environment
US11354651B2 (en) 2015-01-19 2022-06-07 Royal Bank Of Canada System and method for location-based token transaction processing
CN113379401A (zh) * 2015-01-19 2021-09-10 加拿大皇家银行 电子支付的安全处理
US10096009B2 (en) 2015-01-20 2018-10-09 Visa International Service Association Secure payment processing using authorization request
US20160217461A1 (en) * 2015-01-23 2016-07-28 Ajit Gaddam Transaction utilizing anonymized user data
US11250391B2 (en) 2015-01-30 2022-02-15 Visa International Service Association Token check offline
US11176554B2 (en) 2015-02-03 2021-11-16 Visa International Service Association Validation identity tokens for transactions
US11250421B2 (en) 2015-02-08 2022-02-15 Apple Inc. Storing secure credential information in different regions
US10977657B2 (en) 2015-02-09 2021-04-13 Visa International Service Association Token processing utilizing multiple authorizations
WO2016129863A1 (en) 2015-02-12 2016-08-18 Samsung Electronics Co., Ltd. Payment processing method and electronic device supporting the same
US20160253651A1 (en) * 2015-02-27 2016-09-01 Samsung Electronics Co., Ltd. Electronic device including electronic payment system and operating method thereof
KR102460459B1 (ko) * 2015-02-27 2022-10-28 삼성전자주식회사 전자 장치를 이용한 카드 서비스 방법 및 장치
CN107408251B (zh) * 2015-02-27 2022-01-25 三星电子株式会社 提供电子支付功能的电子设备及其操作方法
WO2016137277A1 (en) 2015-02-27 2016-09-01 Samsung Electronics Co., Ltd. Electronic device providing electronic payment function and operating method thereof
WO2016137271A1 (en) * 2015-02-27 2016-09-01 Samsung Electronics Co., Ltd. Payment means operation supporting method and electronic device for supporting the same
US10193700B2 (en) 2015-02-27 2019-01-29 Samsung Electronics Co., Ltd. Trust-zone-based end-to-end security
CA2975151A1 (en) * 2015-03-03 2016-09-09 Purple Deck Media, Inc. A networked computer system for remote rfid device management and tracking
WO2016144904A1 (en) * 2015-03-06 2016-09-15 Mastercard International Incorporated Secure mobile remote payments
US10164996B2 (en) 2015-03-12 2018-12-25 Visa International Service Association Methods and systems for providing a low value token buffer
CN107438992B (zh) 2015-04-10 2020-12-01 维萨国际服务协会 浏览器与密码的集成
CN106156149B (zh) * 2015-04-14 2020-01-03 阿里巴巴集团控股有限公司 一种数据转移方法及装置
US9998978B2 (en) 2015-04-16 2018-06-12 Visa International Service Association Systems and methods for processing dormant virtual access devices
US11954671B2 (en) * 2015-04-27 2024-04-09 Paypal, Inc. Unified login across applications
US10552834B2 (en) 2015-04-30 2020-02-04 Visa International Service Association Tokenization capable authentication framework
WO2016179197A1 (en) * 2015-05-04 2016-11-10 Onepin, Inc. Automatic aftercall directory and phonebook entry advertising
SG10201503701PA (en) * 2015-05-11 2016-12-29 Mastercard Asia Pacific Pte Ltd Method and system for rewarding customers in a tokenized payment transaction
US10878411B2 (en) * 2015-05-13 2020-12-29 Sony Corporation Method and apparatus for issued token management
WO2016205645A1 (en) * 2015-06-19 2016-12-22 Moreton Paul Y Systems and methods for managing electronic tokens for device interactions
DE102015110366A1 (de) * 2015-06-26 2016-12-29 Deutsche Telekom Ag Nachrichtenbereitstellungs- und Bewertungssystem
CN105447687A (zh) * 2015-06-30 2016-03-30 上海易码信息科技有限公司 一种线上到线下移动支付方法
US11599879B2 (en) 2015-07-02 2023-03-07 Royal Bank Of Canada Processing of electronic transactions
AU2016287789A1 (en) * 2015-07-02 2018-02-01 Royal Bank Of Canada Secure processing of electronic payments
US20170053281A1 (en) * 2015-08-20 2017-02-23 Mastercard International Incorporated Card Continuity System and Method
US9666013B2 (en) * 2015-09-29 2017-05-30 Google Inc. Cloud-based vending
US10049349B1 (en) 2015-09-29 2018-08-14 Square, Inc. Processing electronic payment transactions in offline-mode
US10453059B2 (en) 2015-09-30 2019-10-22 Bank Of America Corporation Non-intrusive geo-location determination associated with transaction authorization
US10607215B2 (en) 2015-09-30 2020-03-31 Bank Of America Corporation Account tokenization for virtual currency resources
US20170091757A1 (en) * 2015-09-30 2017-03-30 Bank Of America Corporation Tokenization provisioning and allocating system
RU2018117661A (ru) 2015-10-15 2019-11-18 Виза Интернэшнл Сервис Ассосиэйшн Система мгновенной выдачи маркеров
US9729536B2 (en) 2015-10-30 2017-08-08 Bank Of America Corporation Tiered identification federated authentication network system
US10685352B2 (en) * 2015-11-09 2020-06-16 Paypal, Inc. System, method, and medium for an integration platform to interface with third party channels
US11120443B2 (en) * 2015-11-11 2021-09-14 Visa International Service Association Browser extension with additional capabilities
US10339529B2 (en) 2015-11-18 2019-07-02 Mastercard Internatioinal Incorporated Rules engine for applying rules from a reviewing network to signals from an originating network
US10430795B2 (en) 2015-11-18 2019-10-01 Mastercard International Incorporated Rules engine for applying rules from a reviewing network to signals from an originating network
US20170161733A1 (en) * 2015-12-02 2017-06-08 Mastercard International Incorporated Method and system for validation of a token requestor
WO2017096300A1 (en) 2015-12-04 2017-06-08 Visa International Service Association Unique code for token verification
US10243958B2 (en) 2016-01-07 2019-03-26 Visa International Service Association Systems and methods for device push provisoning
KR102576420B1 (ko) * 2016-01-15 2023-09-08 삼성전자 주식회사 결제 수단의 인디케이션을 표시하는 방법 및 장치
US20170213206A1 (en) * 2016-01-25 2017-07-27 Apple Inc. Conducting transactions using electronic devices with geographically restricted non-native credentials
WO2017136418A1 (en) 2016-02-01 2017-08-10 Visa International Service Association Systems and methods for code display and use
US11501288B2 (en) 2016-02-09 2022-11-15 Visa International Service Association Resource provider account token provisioning and processing
US10373199B2 (en) * 2016-02-11 2019-08-06 Visa International Service Association Payment device enrollment in linked offers
US10529015B1 (en) 2016-04-01 2020-01-07 Wells Fargo Bank, N.A. Systems and methods for onboarding customers through a short-range communication channel
US10313321B2 (en) 2016-04-07 2019-06-04 Visa International Service Association Tokenization of co-network accounts
US11250432B2 (en) * 2016-04-13 2022-02-15 America Express Travel Related Services Company, Inc. Systems and methods for reducing fraud risk for a primary transaction account
SG11201808714WA (en) * 2016-04-15 2018-11-29 Visa Int Service Ass System and method for secure web payments
AU2016403734B2 (en) 2016-04-19 2022-11-17 Visa International Service Association Systems and methods for performing push transactions
US10460367B2 (en) 2016-04-29 2019-10-29 Bank Of America Corporation System for user authentication based on linking a randomly generated number to the user and a physical item
US11250424B2 (en) 2016-05-19 2022-02-15 Visa International Service Association Systems and methods for creating subtokens using primary tokens
KR20230038810A (ko) 2016-06-03 2023-03-21 비자 인터네셔널 서비스 어소시에이션 접속된 디바이스를 위한 서브토큰 관리 시스템
CN109313755A (zh) * 2016-06-15 2019-02-05 万事达卡国际公司 用于桥接eft支付网络和支付卡网络之间的交易的系统和方法
US11068899B2 (en) 2016-06-17 2021-07-20 Visa International Service Association Token aggregation for multi-party transactions
US10268635B2 (en) 2016-06-17 2019-04-23 Bank Of America Corporation System for data rotation through tokenization
EP4303797A1 (en) 2016-06-22 2024-01-10 National Payments Corporation of India An electronic payment system and method thereof
CN109328445B (zh) 2016-06-24 2022-07-05 维萨国际服务协会 唯一令牌认证验证值
CN116471105A (zh) 2016-07-11 2023-07-21 维萨国际服务协会 使用访问装置的加密密钥交换过程
WO2018017068A1 (en) 2016-07-19 2018-01-25 Visa International Service Association Method of distributing tokens and managing token relationships
US10509779B2 (en) 2016-09-14 2019-12-17 Visa International Service Association Self-cleaning token vault
US10567408B2 (en) * 2016-09-23 2020-02-18 Apple Inc. Managing credentials of multiple users on an electronic device
AU2017365115A1 (en) * 2016-11-24 2019-05-30 Diversify Finance Limited System and method for processing a request token
WO2018098492A1 (en) 2016-11-28 2018-05-31 Visa International Service Association Access identifier provisioning to application
CN107067240B (zh) 2016-12-12 2020-09-08 创新先进技术有限公司 资源调配方法和装置以及电子支付方法
US11341489B1 (en) * 2016-12-19 2022-05-24 Amazon Technologies, Inc. Multi-path back-end system for payment processing
US11354659B1 (en) 2016-12-19 2022-06-07 Amazon Technologies, Inc. Securing transaction messages based on a dynamic key selection
TWI615735B (zh) * 2017-01-03 2018-02-21 應用符記於隱藏網路服務之方法
US11687997B2 (en) * 2017-01-27 2023-06-27 Visa International Service Association Browser extension for client-side tokenized authentication
US10915899B2 (en) 2017-03-17 2021-02-09 Visa International Service Association Replacing token on a multi-token user device
US10755339B2 (en) 2017-03-17 2020-08-25 Team Labs, Inc. System and method of purchase request management using plain text messages
WO2018175701A1 (en) 2017-03-23 2018-09-27 Mastercard International Incorporated Digital wallet for the provisioning and management of tokens
US11720924B2 (en) 2017-04-05 2023-08-08 Cinarra Systems, Inc. Systems and methods for cookieless opt-out of device specific targeting
US11164212B2 (en) 2017-04-12 2021-11-02 Cinarra Systems, Inc. Systems and methods for relevant targeting of online digital advertising
US10380366B2 (en) * 2017-04-25 2019-08-13 Sap Se Tracking privacy budget with distributed ledger
US10902418B2 (en) 2017-05-02 2021-01-26 Visa International Service Association System and method using interaction token
US11494765B2 (en) 2017-05-11 2022-11-08 Visa International Service Association Secure remote transaction system using mobile devices
EP3416121B1 (en) * 2017-06-15 2020-08-19 IDEMIA France Digital wallet application for mobile payment
US10524165B2 (en) 2017-06-22 2019-12-31 Bank Of America Corporation Dynamic utilization of alternative resources based on token association
US10511692B2 (en) 2017-06-22 2019-12-17 Bank Of America Corporation Data transmission to a networked resource based on contextual information
US10313480B2 (en) 2017-06-22 2019-06-04 Bank Of America Corporation Data transmission between networked resources
US10491389B2 (en) 2017-07-14 2019-11-26 Visa International Service Association Token provisioning utilizing a secure authentication system
EP3679685A1 (en) * 2017-09-08 2020-07-15 Nchain Holdings Limited Improved time lock technique for securing a resource on a blockchain
US20200410493A1 (en) * 2017-12-27 2020-12-31 Mandar Agashe Computer Implemented System and Method for Cashless and Cardless Transactions
EP3762844A4 (en) 2018-03-07 2021-04-21 Visa International Service Association SECURE REMOTE TOKEN RELEASE WITH ONLINE AUTHENTICATION
CN108805540B (zh) * 2018-05-04 2021-10-29 中电信用服务有限公司 一种支付处理系统、方法和数字对象标识
US11037162B2 (en) * 2018-05-14 2021-06-15 Visa International Service Association System, method, and computer program product for determining an event in a distributed data system
US11256789B2 (en) 2018-06-18 2022-02-22 Visa International Service Association Recurring token transactions
US10546444B2 (en) 2018-06-21 2020-01-28 Capital One Services, Llc Systems and methods for secure read-only authentication
US11777934B2 (en) 2018-08-22 2023-10-03 Visa International Service Association Method and system for token provisioning and processing
WO2020041722A1 (en) * 2018-08-24 2020-02-27 Mastercard International Incorporated Systems and methods for secure remote commerce
US10909526B2 (en) * 2018-09-28 2021-02-02 The Toronto-Dominion Bank System and method for activating a physical token in augmented reality
JP2022501861A (ja) 2018-10-02 2022-01-06 キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニーCapital One Services, LLC 非接触カードの暗号化認証のためのシステムおよび方法
KR20210069033A (ko) 2018-10-02 2021-06-10 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
KR20210065961A (ko) 2018-10-02 2021-06-04 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
WO2020072474A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072670A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10542036B1 (en) 2018-10-02 2020-01-21 Capital One Services, Llc Systems and methods for signaling an attack on contactless cards
WO2020072537A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US11210664B2 (en) 2018-10-02 2021-12-28 Capital One Services, Llc Systems and methods for amplifying the strength of cryptographic algorithms
US10733645B2 (en) 2018-10-02 2020-08-04 Capital One Services, Llc Systems and methods for establishing identity for order pick up
US10909527B2 (en) 2018-10-02 2021-02-02 Capital One Services, Llc Systems and methods for performing a reissue of a contactless card
US10565587B1 (en) 2018-10-02 2020-02-18 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10505738B1 (en) 2018-10-02 2019-12-10 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
SG11202102543WA (en) 2018-10-02 2021-04-29 Capital One Services Llc Systems and methods for cryptographic authentication of contactless cards
US10949520B2 (en) 2018-10-02 2021-03-16 Capital One Services, Llc Systems and methods for cross coupling risk analytics and one-time-passcodes
US10511443B1 (en) 2018-10-02 2019-12-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10607214B1 (en) 2018-10-02 2020-03-31 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10582386B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10489781B1 (en) 2018-10-02 2019-11-26 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10581611B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072440A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
CA3115252A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
KR20210066798A (ko) 2018-10-02 2021-06-07 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
US10579998B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
KR20210069643A (ko) 2018-10-02 2021-06-11 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
US10623393B1 (en) 2018-10-02 2020-04-14 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10771254B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for email-based card activation
US10554411B1 (en) 2018-10-02 2020-02-04 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10771253B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
CA3115064A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10592710B1 (en) 2018-10-02 2020-03-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US11301862B2 (en) 2018-10-04 2022-04-12 Capital One Services, Llc Secure transfer of tokens between devices
CN109299385A (zh) * 2018-11-06 2019-02-01 浙江执御信息技术有限公司 一种利用支付令牌进行支付方式推荐的方法及其装置
EP3881258A4 (en) 2018-11-14 2022-01-12 Visa International Service Association SUPPLY OF TOKENS IN THE CLOUD OF MULTIPLE TOKENS
CN109472681B (zh) * 2018-11-22 2022-03-04 泰康保险集团股份有限公司 一种企业批次付款方法及装置
US11361302B2 (en) 2019-01-11 2022-06-14 Capital One Services, Llc Systems and methods for touch screen interface interaction using a card overlay
US11037136B2 (en) 2019-01-24 2021-06-15 Capital One Services, Llc Tap to autofill card data
US11120453B2 (en) 2019-02-01 2021-09-14 Capital One Services, Llc Tap card to securely generate card data to copy to clipboard
US10467622B1 (en) 2019-02-01 2019-11-05 Capital One Services, Llc Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms
US10510074B1 (en) 2019-02-01 2019-12-17 Capital One Services, Llc One-tap payment using a contactless card
US10425129B1 (en) 2019-02-27 2019-09-24 Capital One Services, Llc Techniques to reduce power consumption in near field communication systems
US10523708B1 (en) 2019-03-18 2019-12-31 Capital One Services, Llc System and method for second factor authentication of customer support calls
US10984416B2 (en) 2019-03-20 2021-04-20 Capital One Services, Llc NFC mobile currency transfer
US10643420B1 (en) 2019-03-20 2020-05-05 Capital One Services, Llc Contextual tapping engine
US10438437B1 (en) 2019-03-20 2019-10-08 Capital One Services, Llc Tap to copy data to clipboard via NFC
US10535062B1 (en) 2019-03-20 2020-01-14 Capital One Services, Llc Using a contactless card to securely share personal data stored in a blockchain
US10970712B2 (en) 2019-03-21 2021-04-06 Capital One Services, Llc Delegated administration of permissions using a contactless card
US10467445B1 (en) 2019-03-28 2019-11-05 Capital One Services, Llc Devices and methods for contactless card alignment with a foldable mobile device
WO2020204743A1 (ru) * 2019-04-02 2020-10-08 Александр Анатольевич КУЗЬМИН Способ и система осуществления вознаграждения в сети интернет
US11200545B2 (en) * 2019-05-10 2021-12-14 Mastercard International Incorporated Mediator website for authenticating payment entities and supporting dynamic interface objects for payments
WO2020236135A1 (en) 2019-05-17 2020-11-26 Visa International Service Association Virtual access credential interaction system and method
US11521262B2 (en) 2019-05-28 2022-12-06 Capital One Services, Llc NFC enhanced augmented reality information overlays
US10516447B1 (en) 2019-06-17 2019-12-24 Capital One Services, Llc Dynamic power levels in NFC card communications
US10871958B1 (en) 2019-07-03 2020-12-22 Capital One Services, Llc Techniques to perform applet programming
US11392933B2 (en) 2019-07-03 2022-07-19 Capital One Services, Llc Systems and methods for providing online and hybridcard interactions
US11694187B2 (en) 2019-07-03 2023-07-04 Capital One Services, Llc Constraining transactional capabilities for contactless cards
US10713649B1 (en) 2019-07-09 2020-07-14 Capital One Services, Llc System and method enabling mobile near-field communication to update display on a payment card
US10498401B1 (en) 2019-07-15 2019-12-03 Capital One Services, Llc System and method for guiding card positioning using phone sensors
US10885514B1 (en) 2019-07-15 2021-01-05 Capital One Services, Llc System and method for using image data to trigger contactless card transactions
US11182771B2 (en) 2019-07-17 2021-11-23 Capital One Services, Llc System for value loading onto in-vehicle device
US10832271B1 (en) 2019-07-17 2020-11-10 Capital One Services, Llc Verified reviews using a contactless card
US10733601B1 (en) 2019-07-17 2020-08-04 Capital One Services, Llc Body area network facilitated authentication or payment authorization
US11521213B2 (en) 2019-07-18 2022-12-06 Capital One Services, Llc Continuous authentication for digital services based on contactless card positioning
US10506426B1 (en) 2019-07-19 2019-12-10 Capital One Services, Llc Techniques for call authentication
US10541995B1 (en) 2019-07-23 2020-01-21 Capital One Services, Llc First factor contactless card authentication system and method
US11068881B2 (en) 2019-09-20 2021-07-20 Bank Of America Corporation System for resource distribution within an offline environment
CN110738495A (zh) * 2019-09-20 2020-01-31 苏宁云计算有限公司 会员资源分摊方法及装置
EP4038587A4 (en) 2019-10-02 2023-06-07 Capital One Services, LLC CUSTOMER DEVICE AUTHENTICATION USING EXISTING CONTACTLESS MAGNETIC STRIP DATA
US11652813B2 (en) 2019-10-04 2023-05-16 Mastercard International Incorporated Systems and methods for real-time identity verification using a token code
US11449636B2 (en) 2019-10-04 2022-09-20 Mastercard International Incorporated Systems and methods for secure provisioning of data using secure tokens
CN110781508B (zh) * 2019-10-25 2022-06-03 四川长虹电器股份有限公司 一种基于区块链技术的个人数据托管方法
US11244312B2 (en) * 2019-11-13 2022-02-08 Bank Of America Corporation One-time abstraction coding for resource deployment
US11238429B2 (en) * 2019-11-25 2022-02-01 Capital One Services, Llc Automatic optimal payment type determination systems
US11651361B2 (en) 2019-12-23 2023-05-16 Capital One Services, Llc Secure authentication based on passport data stored in a contactless card
US11615395B2 (en) 2019-12-23 2023-03-28 Capital One Services, Llc Authentication for third party digital wallet provisioning
US10733283B1 (en) 2019-12-23 2020-08-04 Capital One Services, Llc Secure password generation and management using NFC and contactless smart cards
US10657754B1 (en) 2019-12-23 2020-05-19 Capital One Services, Llc Contactless card and personal identification system
US10862540B1 (en) 2019-12-23 2020-12-08 Capital One Services, Llc Method for mapping NFC field strength and location on mobile devices
US10885410B1 (en) 2019-12-23 2021-01-05 Capital One Services, Llc Generating barcodes utilizing cryptographic techniques
US11113685B2 (en) 2019-12-23 2021-09-07 Capital One Services, Llc Card issuing with restricted virtual numbers
US10853795B1 (en) 2019-12-24 2020-12-01 Capital One Services, Llc Secure authentication based on identity data stored in a contactless card
US10664941B1 (en) 2019-12-24 2020-05-26 Capital One Services, Llc Steganographic image encoding of biometric template information on a card
US11200563B2 (en) 2019-12-24 2021-12-14 Capital One Services, Llc Account registration using a contactless card
US10757574B1 (en) 2019-12-26 2020-08-25 Capital One Services, Llc Multi-factor authentication providing a credential via a contactless card for secure messaging
US10909544B1 (en) 2019-12-26 2021-02-02 Capital One Services, Llc Accessing and utilizing multiple loyalty point accounts
US11038688B1 (en) 2019-12-30 2021-06-15 Capital One Services, Llc Techniques to control applets for contactless cards
US11455620B2 (en) 2019-12-31 2022-09-27 Capital One Services, Llc Tapping a contactless card to a computing device to provision a virtual number
US10860914B1 (en) 2019-12-31 2020-12-08 Capital One Services, Llc Contactless card and method of assembly
US11210656B2 (en) 2020-04-13 2021-12-28 Capital One Services, Llc Determining specific terms for contactless card activation
WO2021211773A1 (en) * 2020-04-14 2021-10-21 Tbcasoft, Inc. Method and system for resolving a target
US11030339B1 (en) 2020-04-30 2021-06-08 Capital One Services, Llc Systems and methods for data access control of personal user data using a short-range transceiver
US10861006B1 (en) 2020-04-30 2020-12-08 Capital One Services, Llc Systems and methods for data access control using a short-range transceiver
US11823175B2 (en) 2020-04-30 2023-11-21 Capital One Services, Llc Intelligent card unlock
US10915888B1 (en) 2020-04-30 2021-02-09 Capital One Services, Llc Contactless card with multiple rotating security keys
US11222342B2 (en) 2020-04-30 2022-01-11 Capital One Services, Llc Accurate images in graphical user interfaces to enable data transfer
US10963865B1 (en) 2020-05-12 2021-03-30 Capital One Services, Llc Augmented reality card activation experience
US11063979B1 (en) 2020-05-18 2021-07-13 Capital One Services, Llc Enabling communications between applications in a mobile operating system
US11100511B1 (en) 2020-05-18 2021-08-24 Capital One Services, Llc Application-based point of sale system in mobile operating systems
US11062098B1 (en) 2020-08-11 2021-07-13 Capital One Services, Llc Augmented reality information display and interaction via NFC based authentication
US11482312B2 (en) 2020-10-30 2022-10-25 Capital One Services, Llc Secure verification of medical status using a contactless card
US11165586B1 (en) 2020-10-30 2021-11-02 Capital One Services, Llc Call center web-based authentication using a contactless card
US11373169B2 (en) 2020-11-03 2022-06-28 Capital One Services, Llc Web-based activation of contactless cards
US11216799B1 (en) 2021-01-04 2022-01-04 Capital One Services, Llc Secure generation of one-time passcodes using a contactless card
US11682012B2 (en) 2021-01-27 2023-06-20 Capital One Services, Llc Contactless delivery systems and methods
US11792001B2 (en) 2021-01-28 2023-10-17 Capital One Services, Llc Systems and methods for secure reprovisioning
US11687930B2 (en) 2021-01-28 2023-06-27 Capital One Services, Llc Systems and methods for authentication of access tokens
US11562358B2 (en) 2021-01-28 2023-01-24 Capital One Services, Llc Systems and methods for near field contactless card communication and cryptographic authentication
US11438329B2 (en) 2021-01-29 2022-09-06 Capital One Services, Llc Systems and methods for authenticated peer-to-peer data transfer using resource locators
US11777933B2 (en) 2021-02-03 2023-10-03 Capital One Services, Llc URL-based authentication for payment cards
US11637826B2 (en) 2021-02-24 2023-04-25 Capital One Services, Llc Establishing authentication persistence
US11245438B1 (en) 2021-03-26 2022-02-08 Capital One Services, Llc Network-enabled smart apparatus and systems and methods for activating and provisioning same
US11935035B2 (en) 2021-04-20 2024-03-19 Capital One Services, Llc Techniques to utilize resource locators by a contactless card to perform a sequence of operations
US11961089B2 (en) 2021-04-20 2024-04-16 Capital One Services, Llc On-demand applications to extend web services
US11902442B2 (en) 2021-04-22 2024-02-13 Capital One Services, Llc Secure management of accounts on display devices using a contactless card
US11354555B1 (en) 2021-05-04 2022-06-07 Capital One Services, Llc Methods, mediums, and systems for applying a display to a transaction card
CN113553450B (zh) * 2021-08-03 2024-01-30 广东新学未科技有限公司 Ppt演示文稿自动生成方法、装置、计算设备及存储介质
US20230061819A1 (en) * 2021-09-01 2023-03-02 Crystal Walker Method and System for Verifying Restricted Purchases
US20230087584A1 (en) * 2021-09-10 2023-03-23 Amazon Technologies, Inc. Reconciliating payment transactions performed by a payment service provider
WO2023163794A1 (en) * 2022-02-28 2023-08-31 Verifone, Inc. Systems and methods for online payment on a payment terminal

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2402814C2 (ru) * 2005-04-19 2010-10-27 Майкрософт Корпорейшн Сетевые коммерческие транзакции

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7177848B2 (en) * 2000-04-11 2007-02-13 Mastercard International Incorporated Method and system for conducting secure payments over a computer network without a pseudo or proxy account number
US7209950B2 (en) * 2000-08-15 2007-04-24 Zonamovil.Com, Inc. Method and apparatus for a network independent short message delivery system
US7133862B2 (en) * 2001-08-13 2006-11-07 Xerox Corporation System with user directed enrichment and import/export control
US20050137969A1 (en) * 2003-12-19 2005-06-23 Dharmesh Shah Secure financial transaction gateway and vault
US7958087B2 (en) * 2004-11-17 2011-06-07 Iron Mountain Incorporated Systems and methods for cross-system digital asset tag propagation
US20100063903A1 (en) * 2008-03-10 2010-03-11 Thayne Whipple Hierarchically applied rules engine ("hare")
US20090327088A1 (en) * 2008-06-26 2009-12-31 Utstarcom, Inc. System and Method for performing International Transactions
US8229853B2 (en) * 2008-07-24 2012-07-24 International Business Machines Corporation Dynamic itinerary-driven profiling for preventing unauthorized card transactions
CN101414370A (zh) * 2008-12-15 2009-04-22 阿里巴巴集团控股有限公司 利用虚拟卡提高支付安全的支付方法、系统及支付平台
US20100191622A1 (en) * 2009-01-28 2010-07-29 Zvi Reiss Distributed Transaction layer
US20100312645A1 (en) * 2009-06-09 2010-12-09 Boku, Inc. Systems and Methods to Facilitate Purchases on Mobile Devices
US20110047075A1 (en) * 2009-08-19 2011-02-24 Mastercard International Incorporated Location controls on payment card transactions
KR20110033337A (ko) * 2009-09-25 2011-03-31 나도진 무선 통신 망 또는 인터넷 망을 이용한 결제 및 이체 관리 시스템 및 방법
US9558494B2 (en) * 2010-04-19 2017-01-31 Tokenex, L.L.C. Devices, systems, and methods for tokenizing sensitive information
US8442913B2 (en) * 2010-06-29 2013-05-14 Visa International Service Association Evolving payment device
US20120173431A1 (en) * 2010-12-30 2012-07-05 First Data Corporation Systems and methods for using a token as a payment in a transaction
US20120231844A1 (en) * 2011-03-11 2012-09-13 Apriva, Llc System and device for facilitating a transaction by consolidating sim, personal token, and associated applications for electronic wallet transactions
US8943574B2 (en) * 2011-05-27 2015-01-27 Vantiv, Llc Tokenizing sensitive data

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2402814C2 (ru) * 2005-04-19 2010-10-27 Майкрософт Корпорейшн Сетевые коммерческие транзакции

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2693638C1 (ru) * 2017-08-08 2019-07-03 Общество с ограниченной ответственностью "Цифровой Платеж" Способ оплаты товара и (или) услуги с помощью мобильного терминала
RU2792695C2 (ru) * 2018-07-03 2023-03-23 Виза Интернэшнл Сервис Ассосиэйшн Синхронизация состояния маркера
US11847233B2 (en) 2018-07-03 2023-12-19 Visa International Service Association Token state synchronization
RU2730417C1 (ru) * 2019-05-24 2020-08-21 Петр Анатольевич Беликов Способ онлайн-продаж товаров и услуг и вендинговое устройство, реализующее способ
RU2736507C1 (ru) * 2019-09-18 2020-11-17 Александр Юрьевич Баранов Способ и система создания и использования доверенного цифрового образа документа и цифровой образ документа, созданный данным способом
WO2021054854A1 (ru) * 2019-09-18 2021-03-25 Александр Юрьевич БАРАНОВ Создание и использование доверенного цифрового образа документа
US20230012458A1 (en) * 2021-07-07 2023-01-12 Paypal, Inc. Identifying transaction processing retry attempts based on machine learning models for transaction success

Also Published As

Publication number Publication date
EP2718886A4 (en) 2015-01-14
CN103765454B (zh) 2018-02-27
EP2718886A1 (en) 2014-04-16
RU2013158683A (ru) 2015-07-20
CN103765454A (zh) 2014-04-30
WO2013101297A1 (en) 2013-07-04
US20120316992A1 (en) 2012-12-13
AU2012363110A1 (en) 2013-12-12

Similar Documents

Publication Publication Date Title
RU2602394C2 (ru) Устройства, способы и системы токенизации конфиденциальности платежей
US11727392B2 (en) Multi-purpose virtual card transaction apparatuses, methods and systems
AU2018204759B2 (en) Snap mobile payment apparatuses, methods and systems
US11023886B2 (en) Universal electronic payment apparatuses, methods and systems
US10482398B2 (en) Secure anonymous transaction apparatuses, methods and systems
US10586227B2 (en) Snap mobile payment apparatuses, methods and systems
US8577803B2 (en) Virtual wallet card selection apparatuses, methods and systems
AU2017202809A1 (en) Social media payment platform apparatuses, methods and systems
US20130024371A1 (en) Electronic offer optimization and redemption apparatuses, methods and systems
US20130024364A1 (en) Consumer transaction leash control apparatuses, methods and systems
WO2013049329A1 (en) Electronic offer optimization and redemption apparatuses, methods and systems

Legal Events

Date Code Title Description
FA93 Acknowledgement of application withdrawn (no request for examination)

Effective date: 20150608

FZ9A Application not withdrawn (correction of the notice of withdrawal)

Effective date: 20150825