RU2292589C2 - Аутентифицированный платеж - Google Patents

Аутентифицированный платеж Download PDF

Info

Publication number
RU2292589C2
RU2292589C2 RU2002130717/09A RU2002130717A RU2292589C2 RU 2292589 C2 RU2292589 C2 RU 2292589C2 RU 2002130717/09 A RU2002130717/09 A RU 2002130717/09A RU 2002130717 A RU2002130717 A RU 2002130717A RU 2292589 C2 RU2292589 C2 RU 2292589C2
Authority
RU
Russia
Prior art keywords
buyer
customer
payment
transaction
authentication
Prior art date
Application number
RU2002130717/09A
Other languages
English (en)
Other versions
RU2002130717A (ru
Inventor
Майкл Е. ГРЭЙВС (US)
Майкл Е. ГРЭЙВС
Питер Е. ФРЭНК (US)
Питер Е. ФРЭНК
Тэйн ПЛЭМБЕК (US)
Тэйн ПЛЭМБЕК
Грегори Р. УАЙТХЕД (US)
Грегори Р. УАЙТХЕД
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 RU2002130717A publication Critical patent/RU2002130717A/ru
Application granted granted Critical
Publication of RU2292589C2 publication Critical patent/RU2292589C2/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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • 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
    • 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/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Holo Graphy (AREA)
  • Control Of Eletrric Generators (AREA)
  • Credit Cards Or The Like (AREA)

Abstract

Изобретение относится к аутентификации покупателей при осуществлении интерактивных коммерческих транзакций. Техническим результатом является обеспечение защиты от несанкционированного доступа. В системе и способе покупатель предпочитает использовать средство электронных платежей как часть коммерческой транзакции с продавцом, осуществляемой в интерактивном режиме, при этом требуется аутентифицировать наличие у покупателя полномочий использовать средство платежей. Отдельная служба аутентификации выполнена на WEB-сервере и предназначена для определения, имеет ли покупатель доступ к некоторой секретной информации без раскрытия секретной информации продавцу. Служба аутентификации информирует продавца, имеет ли покупатель полномочия использовать средство платежей. При идентификации покупателя используют данные о профиле покупателя, включающем данные о множестве инструментов платежа и адресов отгрузки, которые использует покупатель. 2 н. и 12 з.п. ф-лы, 9 ил.

Description

Данная заявка испрашивает приоритет предварительной заявки на патент США, регистрационный номер 60/198.110, называемой "Аутентифицированный платеж", поданной 17 апреля 2002 года на имя Greg Whitehead, Michael Graves, Thane Plambeck.
Область техники
Настоящее изобретение относится к аутентификации покупателей при осуществлении интерактивных коммерческих транзакций и, более конкретно, к использованию отдельной службы аутентификации, осуществляющей аутентификацию покупателя.
Предшествующий уровень техники
В результате роста популярности и использования Интернета и других форм сетевой связи широко применяется интерактивная коммерция (коммерция в режиме реального времени). Например, постоянно увеличивается объем покупок пользователей, торговых операций между торгово-промышленными предприятиями, продажа акций и другие формы вложения капитала, осуществляемые через Интернет и/или беспроводные сети связи, и другие формы интерактивной коммерции. Кроме того, для использования преимуществ уникальных свойств интерактивной коммерции значительные усилия прилагаются для разработки альтернативных бизнес-моделей (например, аукционов и оптовых покупок) и альтернативных форм электронного платежа (например, электронного наличного расчета и авторизованных переводов денежных средств через Интернет).
Однако одним из недостатков интерактивной коммерции является сложность аутентификации покупателя. Примером может служить случай, когда пользователь предпочитает приобрести товар с использованием кредитной карточки. При приобретении товара в реальном мире от покупателя требуется предъявить свою кредитную карточку (возможно, имеющую фотографию) и подписать бланк кредитной карточки подписью, соответствующей подписи на кредитной карточке. Эти действия выполняют две важные задачи. Во-первых, они с определенной достоверностью устанавливают, что покупатель имеет полномочия использовать кредитную карточку. Во-вторых, они формируют запись, которая затрудняет отрицание покупателем впоследствии того, что он санкционировал покупку. Эти два фактора значительно уменьшают риск мошеннической транзакции.
В интерактивном варианте данной транзакции действия, которые соответствуют предъявлению кредитной карточки и подписанию бланка кредитной карточки, или не существуют, или, если они существуют, то не так эффективны в смысле уменьшения риска. Например, во многих случаях от покупателя требуется просто напечатать номер своей кредитной карточки и затем щелкнуть кнопку Осуществить Покупку. Эти два действия допускают мошенничество в большей степени, чем их аналоги в реальном мире, поскольку продавец не знает, действительно ли человек, предпринимающий эти действия, имеет полномочия использовать эту кредитную карточку. Другими словами, продавцу сложно аутентифицировать покупателя. Дополнительно, даже если транзакция санкционирована истинным владельцем кредитной карточки, то повышенный риск мошенничества означает, что полученная в результате запись не имеет юридического значения, поскольку владелец кредитной карточки может утверждать, что транзакцию санкционировал самозванец. Этот дополнительный риск мошенничества в ситуации "карточка не представлена" приводит к более высоким тарифам взаимного обмена и плате за транзакции, обрабатываемые через Интернет и другие системы интерактивной коммерции, и, возможно, обеспечивает наибольшую составляющую стоимости коммерции через Интернет.
Одной из причин роста мошенничества при использовании Интернета и роста другого электронного мошенничества является то, что личная информация средств платежа, например номера кредитных карточек, номера контрольных счетов, и связанные с ними данные стали по существу "информацией общего пользования" в том смысле, что эти данные легко доступны. Например, пользователь в незащищенном формате передает номер своей кредитной карточки, дату конечного срока и т.д. каждому электронному продавцу при каждой транзакции. Дополнительно такая информация, как имя, адрес, номер социального страхования и т.д. также является доступной из других источников, отличных от держателя карточки. Например, много информации такого вида может содержаться в телефонных каталогах и каталогах другого вида, доступных для просмотра средствами Web. Информация средств платежа, которая приводится в незащищенном виде и повторяется, совместно с тем фактом, что многое из этой информации также является доступным из других источников, увеличивает риск мошеннических транзакций. Например, хакерам зачастую необходимо только захватить базы данных номеров кредитных карточек и информацию соответствующих им имен и адресов, чтобы во многих средах осуществления интерактивных транзакций подменить фактического держателя карточки.
Обычно проблема аутентификации покупателя решалась посредством использования паролей, что представляет собой подход, стандартно используемый в коммерческих средах Интернета (Web), где покупатель аутентифицирует себя, используя просто имя пользователя и пароль. Как описано выше, пароли имеют свойственные им недостатки и при использовании для этой цели нынешние реализации еще более усугубляют эти недостатки. Например, обычно пользователи должны регистрироваться индивидуально каждым электронным продавцом, использующим интерактивный процесс. В результате электронный продавец имеет ограниченную возможность подтвердить регистрацию пользователя, поскольку время интерактивной регистрации часто не позволяет осуществить существенную проверку, и даже если имеется возможность осуществить такую проверку, то препятствовать будет оплата, поскольку каждый электронный продавец должен сам оплачивать осуществляемую им проверку. Дополнительно пользователи часто используют одни и те же имена пользователя и пароли для нескольких учетных записей. Это увеличивает возможность подвергнуть риску имя пользователя и пароль, и если они подверглись риску, то увеличивает потенциально возможный ущерб. Дополнительно, поскольку имя пользователя и пароль обычно передаются электронному продавцу незащищенным текстом, то недобросовестные электронные продавцы могут также использовать эту информацию, чтобы подвергнуть риску другие учетные записи пользователя. В качестве последнего примера можно отметить, что многие существующие системы аутентификации аутентифицируют идентичность пользователя (например, подтверждая, что пользователь действительно является Джоном До), но аутентификация идентичности кого-то не обязательно является подтверждением того, что этот кто-то имеет полномочия использовать конкретное средство платежа.
Одной из попыток решить проблему аутентификации покупателя, содействующей осуществлению через Интернет защищенных транзакций с использованием платежных карточек, является протокол Защищенных электронных транзакций (или ЗЭТ). В ЗЭТ использовались цифровые сертификаты для образования достоверной последовательности в ходе транзакции. Например, пользователь должен иметь цифровой сертификат, который он предъявляет электронному продавцу. Электронный продавец должен иметь цифровой сертификат, который он предъявляет пользователю. Для обеспечения достоверности каждый должен проверить цифровой сертификат другого и основную последовательность цифровых сертификатов. Однако этот подход вносит значительное административное и операционное усложнение для пользователей, для электронных продавцов и в соответствующую инфраструктуру обработки транзакций. Например, покупателям и электронным продавцам для использования протокола требуется специализированная технология, и они будут вынуждены обновлять технологию при каждом принятии новых цифровых сертификатов. В результате протокол ЗЭТ не получил широкого распространения.
Следовательно, существует потребность в существенной аутентификации покупателя при интерактивных коммерческих транзакциях. Дополнительно существует потребность в способе аутентификации покупателя, который является достаточно гибким для обеспечения возможности разного уровня защиты для разных приложений и также для принятия новых технологий. Также предпочтительно, чтобы способ не вносил значительных трудностей в существующую инфраструктуру обработки транзакций или не требовал ее сильной модификации.
Сущность изобретения
Согласно настоящему изобретению интерактивная система (100) коммерческих транзакций содержит покупателя (110), продавца (120) и службу (130) аутентификации. Для продавца (120) требуется аутентифицировать (204), что покупатель (110) имеет полномочия использовать средство платежа как часть интерактивной коммерческой транзакции с продавцом (120). Для этого служба (130) аутентификации выполняет следующие этапы, которые осуществляются в режиме реального времени, как часть интерактивной коммерческой транзакции. Служба (130) аутентификации принимает (230) запрос на подтверждение наличия у покупателя (110) полномочий использовать средство платежа.
Она определяет (246), имеет ли покупатель (110) доступ к некоторой секретной информации без раскрытия секретной информации продавцу (120). Доступ к секретной информации должен подтвердить наличие полномочий на использование средства платежа. В зависимости от определения, имеет ли покупатель (110) доступ к секретной информации, служба (130) аутентификации передает (250) продавцу (120) ответ, содержащий информацию о том, имеет ли покупатель (110) полномочия использовать средство платежа. Согласно другому аспекту изобретения служба (130) аутентификации также применяет (260) информацию с личными данными (информацию профиля) покупателя (110) в интерактивную коммерческую транзакцию и/или обрабатывает (270) или по меньшей мере частично обрабатывает транзакцию платежа. Служба (130) аутентификации также может хранить (280) запись об использовании средства платежа и/или о транзакции.
В предпочтительном варианте осуществления (300) интерактивная коммерческая транзакция осуществляется через Интернет. Покупатель (110) осуществляет доступ к Интернету через средство просмотра Web (Web-браузер), продавец (120) использует электронную витрину Интернет, размещенную на Web сервере, и служба (130) аутентификации реализуется на Web сервере. Дополнительно секретная информация содержит секретный ключ. Другими словами, создание цифровых подписей, использующих секретный ключ, должно являться доказательством того, что подписывающееся лицо имеет полномочия использовать соответствующее средство платежа. В этом варианте осуществления запрос (330) на аутентификацию инициируется представлением покупателем формы (400), которая содержит активный элемент, идентифицирующий службу (130) аутентификации. Запрос (330) в службу (130) аутентификации также содержит адрес продавца, чтобы служба аутентификации имела информацию о том, куда передать (350) результаты процесса аутентификации. Для аутентификации продавца (120) служба (130) аутентификации передает (340) запрос покупателю (110), требующий, чтобы покупатель (110) использовал секретный ключ для подписи цифровой подписью некоторых данных. Служба (130) аутентификации использует ответ (342) покупателя для определения (346), имеет ли покупатель (110) доступ к секретному ключу, и затем передает (350) результаты продавцу (120). Служба (130) аутентификации может запросить у покупателя (110) дополнительно подписать цифровой подписью запись транзакции, создавая (380), таким образом, строгую запись транзакции (имеющую юридическое значение).
Настоящее изобретение имеет особенное преимущество, поскольку для аутентификации покупателя (110) используется отдельная служба (130) аутентификации, а не продавец (120). В результате продавец (120) не получает доступ к секретной информации, связанной со средством платежа покупателя. Это предотвращает повторное использование секретной информации продавцом (120) для санкционирования впоследствии мошеннических транзакций.
Дополнительно сосредоточение функции аутентификации в службе (130) аутентификации приводит к значительной гибкости и снижению расходов на масштабирование системы. Могут быть использованы различные виды секретной информации, причем каждый вид для своей реализации требует отличающейся технологии. Сосредоточение функции аутентификации в службе (130) аутентификации позволяет разделить стоимость требуемой технологии на многих продавцов (120). Дополнительно при изменении вида секретной информации или соответствующей процедуры аутентификации покупателя большая часть изменений повлияет только на службу (130) аутентификации (130), следовательно, легко обеспечивается реализация новых технологий аутентификации. Если служба (130) аутентификации выполняет другие функции, такие как добавление к транзакции информации профиля покупателя, обработку средства платежа или создание и хранение записей транзакций, то может быть произведено дополнительное снижение расходов на масштабирование, поскольку служба (130) аутентификации естественным образом является централизованным пунктом для этих других функций.
Краткое описание чертежей
Описанные выше и другие более детализированные и конкретные задачи и свойства настоящего изобретения раскрыты более полно в последующем описании, иллюстрируемом чертежами, на которых представлено следующее:
фиг.1 - блок-схема системы, соответствующей настоящему изобретению;
фиг.2 - запись событий, иллюстрирующая способ функционирования системы, изображенной на фиг.1;
фиг. 3 - запись событий, иллюстрирующая предпочтительный способ функционирования предпочтительного варианта осуществления системы, изображенной на фиг.1;
фиг. 4-7 - разные экранные изображения и диалоговые окна, иллюстрирующие способ, представленный на фиг. 3.
Подробное описание предпочтительных вариантов осуществления
На фиг.1 изображена блок-схема системы 100 согласно настоящему изобретению. Система 100 содержит покупателя 110, продавца 120 и службу 130 аутентификации, связанные друг с другом. Система 100 также может содержать каталог 140 служб аутентификации, который является доступным для покупателя 110, и базу данных 150 профилей покупателей и архив 170 транзакций, которые доступны для службы 130 аутентификации. Необязательный шлюз 160, используемый для осуществления платежа, (шлюз платежа) также доступен для службы 130 аутентификации, хотя в альтернативных вариантах осуществления доступ к шлюзу 160 платежа может иметь продавец 120 или служба 130 аутентификации и продавец 120. Шлюз 160 платежа является просто каналом, через который передаются к соответствующим финансовым учреждениям транзакции платежа. Настоящее изобретение может использоваться с многими разными видами шлюзов 160 платежа (или даже без шлюза платежа) и не ограничено использованием конкретного вида технологии шлюзов.
Покупатель 110 предпочитает использовать средство платежа как часть интерактивной коммерческой транзакции с продавцом 120. Например, в одном приложении покупателем 110 является пользователь, продавцом 120 является электронныйпродавец с электронной витриной в Интернете, и пользователь для покупки у электронного продавца некоторого продукта, информации или услуги предпочитает использовать свою кредитную карточку. В качестве другого возможного варианта покупателем 110 является индивидуальное лицо, соединяющееся с продавцом 120 через радиотелефон или карманный персональный цифровой ассистент (ПЦА), продавцом 120 является служба оплаты счетов, и для упомянутого лица предпочтительно выписать "Интернет-чеки" для оплаты своих ежемесячных счетов. В качестве другого возможного варианта покупателем 110 является корпорация или лицо, действующее от имени корпорации, покупающее материалы или услуги у поставщика 120 корпорации. Другие возможные варианты средств платежа включают текущие номера контрольного счета, виртуальные деньги или электронные представления наличных, значение денежной предоплаты, которое хранится в электронных бумажниках, платежные карточки и кредиты или купоны Интернета.
Из рассмотренных возможных вариантов ясно, что возможны многие другие приложения и термины "покупатель" и "продавец" используются как удобные обозначения, но не ограничивают эти сущности. В действительности, от "покупателя 110" не требуется покупать что-либо, а от "продавца 120" не требуется продавать. Аналогично, "интерактивная коммерческая транзакция" не ограничивается транзакциями купли-продажи. Скорее интерактивной коммерческой транзакцией может быть любая транзакция, в которой покупатель 110 предпочитает использовать средство платежа как часть транзакции, или, более обобщенно, любая транзакция, для которой должна быть использована аутентификация покупателя 110. В качестве возможного варианта приложения, не использующего средство платежа, "покупателем" 110 может быть некоторое лицо, "продавцом" 120 может быть страховая компания, полис которой имеет покупатель, и "транзакцией" может быть то, что покупатель предпочитает изменить лицо, получающее пособие. Продавец предпочитает сначала аутентифицировать покупателя, до получения покупателем доступа к своей учетной записи.
На фиг.2 изображена запись событий, иллюстрирующая функционирование 200 системы 100. Способ 200 может быть приближенно разделен на три основных части: регистрация 202 покупателя, аутентификация 204 покупателя и регистрация 206 транзакции. Не во всех реализациях используются все три стадии 202-206, или все индивидуальные этапы, изображенные на фиг.2, но в рассматриваемом возможном варианте они содержатся для иллюстрации различных аспектов изобретения. При регистрации 202 покупателя между покупателем 110 и службой 130 аутентификации устанавливается секретная информация, которая будет использована на стадии 204 для аутентификации покупателя и средства платежа. Регистрация 202 покупателя предпочтительно для каждого средства платежа происходит только один раз. Аутентификация 204 покупателя происходит в режиме реального времени, как часть интерактивной коммерческой транзакции. На этой стадии покупатель 110 демонстрирует службе 130 аутентификации, что имеет доступ к секретной информации. Если демонстрация доступа прошла успешно, то служба 130 аутентификации информирует продавца 120 о том, что покупатель 110 имеет полномочия использовать средство платежа. На стадии 206 регистрации транзакций служба 130 аутентификации создает запись о транзакции, и эта запись впоследствии может использоваться как доказательство проведения конкретной транзакции.
Использование отдельной службы 130 аутентификации имеет много преимуществ. Например, как будет более понятно из последующего описания, большая часть процесса 204 аутентификации покупателя выполняется службой 130 аутентификации. Служба 130 аутентификации определяет, продемонстрировал ли покупатель 110 доступ к секретной информации и, следовательно, имеет полномочия использовать средство платежа. Покупатель 110 принимает участие только в минимальной степени, а продавец 120, по существу, не принимает участия совсем. Сосредоточение этой функции в службе 130 аутентификации приводит к значительной гибкости и снижает расходы на масштабирование. Например, для создания защиты разного уровня для разных средств платежа могут использоваться разные виды секретной информации, от простых персональных идентификационных номеров (ПИН) до сложных протоколов цифровой сертификации. Разные виды секретной информации обычно требуют разной инфраструктуры для выполнения стадии 204 аутентификации покупателя. Сосредоточение стадии 204 аутентификации покупателя в службе 130 аутентификации позволяет распределить стоимость этой инфраструктуры на многих продавцов 120. Дополнительно, если меняется вид секретной информации или соответствующая процедура аутентификации покупателя, то большая часть изменений повлияет только на службу 130 аутентификации, следовательно, позволяя легко реализовать новые технологии аутентификации. Напротив, известные способы, такие как ЗЭТ, требовали от продавца 120 обеспечения большой части необходимой инфраструктуры. Это приводило к большим затратам, медленному внедрению и трудности перехода на новые технологии, что в итоге привело к отказу от ЗЭТ и от подобных подходов.
Этот способ также имеет преимущество, поскольку продавец 120 не получает доступ к секретной информации покупателя 110, так как продавец не принимает участие в аутентификации 204 покупателя. Это предотвращает повторное использование продавцом 120 секретной информации покупателя 110 для санкционирования впоследствии мошеннических транзакций. Например, допустим, что секретной информацией является ПИН. Если бы продавец 120 был ответственен за аутентификацию 204 покупателя, то покупатель 110 должен был раскрыть свой ПИН продавцу 120, который имел возможность использовать его впоследствии в мошеннических целях. Однако в настоящем способе покупатель 110 раскрывает ПИН не продавцу 120, а только службе 310 аутентификации.
Дополнительно, как будет описано ниже, поскольку стадия 204 аутентификации покупателя сосредоточена в службе 130 аутентификации, то может быть осуществлено дополнительное снижение расходов на масштабирование при выполнении службой 130 аутентификации также других функций. Например, служба аутентификации 130 может добавлять к транзакции дополнительную информацию (например, адрес транспортировки для покупателя), обрабатывать или частично обрабатывать средство платежа покупателя и/или создавать и хранить записи транзакций.
Согласно фиг.2 каждый из блоков 110, 120 и 130, выделенных штриховыми линиями, представляет один из компонентов в системе 100. Блоки, выделенные сплошной линией, представляют разные этапы способа 200. Размещение блока, выделенного сплошной линией, внутри блока, выделенного штриховой линией, указывает, что этап, по существу, выполняется этим компонентом. Например, этап 210 размещен внутри блока, выделенного штриховой линией, для службы 130 аутентификации. Это указывает на то, что служба аутентификации 130, по существу, выполняет этап 210. Некоторые этапы имеют два блока, что указывает на то, что этапы выполняются в двух компонентах. Например, один компонент может передавать сообщение другому компоненту. Предпочтительно, этапы реализуются программным обеспечением, выполняющимся на разных компонентах внутри системы 100, возможно, с помощью блоков аппаратного обеспечения. Этапы могут быть реализованы также в аппаратном обеспечении и/или аппаратно-программном обеспечении.
Стадия 202 регистрации покупателя предпочтительно осуществляется перед фактической интерактивной коммерческой транзакцией. На этой стадии 202 между покупателем 110 и службой 130 аутентификации 130 устанавливается секретная информация. Информация является секретной в том смысле, что в идеале она известна и/или доступна только покупателю (или покупателю 110 и службе 130 аутентификации, в случае секретной информации, совместно используемой покупателем и службой аутентификации). Она не является, по существу, доступной общественности или продавцам 120. Дополнительно секретная информация соответствует конкретному средству(ам) платежа, и доказательство доступа к секретной информации будет принято за подтверждение полномочий на использование средства платежа.
Могут использоваться разные виды секретной информации, в зависимости от вида требуемой защиты. Возможные варианты секретной информации включают ПИН или пароль, удостоверение личности, которое хранится в сети (например, для поддержки роуминга), цифровую подпись, используемую при роуминге, программное обеспечение, удостоверяющее личность, например секретный ключ, локальный для машины покупателя, аппаратное обеспечение, удостоверяющее личность, такое как маркер оборудования, или секретный ключ, содержащийся на интеллектуальной карточке, биометрические данные, удостоверяющие личность, и информацию, используемую в криптографических протоколах типа запрос-ответ.
В конкретном возможном варианте, иллюстрируемом фиг.2, секретная информация устанавливается следующим образом. Служба 130 аутентификации принимает (210) информацию подтверждения, которая впоследствии обеспечивает службе аутентификации возможность определить, имеет ли покупатель 110 доступ к секретной информации. Затем служба 130 аутентификации хранит (212) информацию подтверждения, соответствующую средству платежа, например, как часть базы 150 данных профилей покупателя. В одном варианте осуществления, следующим за этой моделью, секретной информацией покупателя является секретный ключ, а соответствующей информацией подтверждения является соответствующий открытый ключ.
В других вариантах осуществления регистрация 202 покупателя выполняется другими способами. Например, служба 130 аутентификации может не хранить информацию подтверждения. Вместо этого, информация подтверждения может храниться в другом месте и при необходимости восстанавливается службой 130 аутентификации. В другом варианте вместо того, чтобы хранить информацию подтверждения, которая отличается от секретной информации, служба 130 аутентификации может просто хранить непосредственно секретную информацию (например, при хранении паролей или хеш-паролей). Как другой возможный вариант регистрация 202 покупателя может осуществляться автономно. Например, покупатель 110 может заполнить заявку и передать ее в банк. Банк осуществляет проверку информации, имеющейся в заявке, выпускает для покупателя 110 кредитную карточку и передает информацию учетной записи в службу 130 аутентификации. Служба 130 аутентификации создает интеллектуальную карточку с внедренной секретной информацией, и интеллектуальная карточка посылается покупателю 110, например, через почтовую службу. Следует отметить, что в последнем возможном варианте регистрация 202 покупателя использует преимущество процесса регистрации кредитных карточек. Регистрация покупателя может использовать также преимущества других процессов.
Предпочтительно, секретная информация формируется покупателем 110, чтобы минимизировать раскрытие секретной информации другим сторонам. Однако в других вариантах осуществления она может формироваться и/или совместно использоваться другими сторонами, например службой аутентификации, особенно, когда предполагается, что риск, вносимый этими сторонами, является небольшим.
На стадии 204 аутентификации покупателя покупатель 110 предпочитает использовать средство платежа как часть интерактивной коммерческой транзакции с продавцом 120. Служба 130 аутентификации как часть транзакции определяет в режиме реального времени, имеет ли покупатель 110 на это полномочия. В конкретном возможном варианте, согласно фиг.2, это осуществляется следующим образом. Покупатель 110 предлагает (220) использовать средство платежа. Например, покупатель 110 может предложить заплатить за покупку, используя кредитную карточку.
Продавцу 120 требуется знать, имеет ли покупатель 110 полномочия использовать средство платежа, поэтому он передает (230) в службу 130 аутентификации запрос на подтверждение полномочий покупателя. В зависимости от средства платежа идентификация службы 130 аутентификации может быть не очевидной сразу. Может существовать несколько служб аутентификации. Например, каждая компания, выпускающая кредитные карточки, может обеспечивать собственную службу аутентификации. Одним способом решения этой проблемы является использование каталога 140, определяющего соответствие средств платежа и служб аутентификации. В этом случае продавец 120 осуществляет доступ к каталогу 140 для определения того, какая служба аутентификации подходит для средства платежа, предъявляемого покупателем 110.
Служба 130 аутентификации определяет, имеет ли покупатель 110 доступ к секретной информации, на этапах 240-246. Служба 130 аутентификации передает (240) покупателю 110 «запрос на запрос». Этот "запрос на запрос" запрашивает доказательство того, что покупатель имеет доступ к секретной информации. Например, если секретной информацией является пароль, то в "запросе на запрос" может запрашиваться пароль. Если секретной информацией является секретный ключ, то в "запросе на запрос" может запрашиваться, чтобы покупатель 110 подписал что-либо цифровой подписью, используя секретный ключ. В одном варианте осуществления "запрос на запрос" также содержит описание интерактивной коммерческой транзакции и обеспечивает покупателю возможность отклонить транзакцию, например, если описание не соответствует представлениям покупателя. Также, в "запросе на запрос" вместо этого может запрашиваться согласие покупателя на осуществление транзакции. Если покупатель 110 предпочитает продолжить, то он передает (242) свой "ответ на запрос" обратно, в службу 130 аутентификации.
Служба 130 аутентификации извлекает (244) сохраненную ранее информацию подтверждения для средства платежа и использует информацию подтверждения и ответ на запрос для определения, имеет ли покупатель 110 доступ к секретной информации. Например, в варианте осуществления с использованием пароля служба 130 аутентификации хеширует пароль из ответа на запрос и сравнивает его с котированным значением, которое хранится в качестве информации подтверждения. В варианте осуществления с использованием секретного ключа служба 130 аутентификации использует открытый ключ, который хранится в качестве информации подтверждения, для определения, было ли подписанное цифровой подписью сообщение в ответе на запрос действительно подписано цифровой подписью с использованием соответствующего секретного ключа.
Затем служба 130 аутентификации передает (250) продавцу 120 ответ на исходный запрос продавца. Ответ содержит информацию о том, имеет ли покупатель 110 полномочия использовать средство платежа. Также он может содержать дополнительную информацию, как описано ниже со ссылками на этапы 260 и 270. Следует отметить, что во время аутентификации покупателя 204 секретная информация продавцу 120 не передается.
Перед тем как перейти к описанию этапов 260 и 270, следует отметить, что этапы 240-250 аутентификации, иллюстрируемые фиг.2, являются только одним вариантом реализации стадии 204 аутентификации покупателя. Другие реализации будут очевидны. Например, служба 130 аутентификации может раньше принять (230) запрос на аутентификацию от покупателя 110, чем от продавца 120. Как другой возможный вариант, служба 130 аутентификации может не использовать запрос 240 и ответ 242 на запрос. Доказательство доступа к секретной информации, например, может быть включено, как часть исходного запроса 230. Дополнительно, как упомянуто на стадии 202 регистрации покупателя, служба 130 аутентификации может использовать способы помимо информации подтверждения (этапы 244 и 246) для определения, имеет ли покупатель доступ к секретной информации.
Согласно фиг.2 в некоторых вариантах осуществления служба 130 аутентификации может внести (260) в транзакцию дополнительную информацию профиля покупателя. Например, продавец 120 может запросить, чтобы к транзакции был добавлен адрес отгрузки для покупателя. Служба 130 аутентификации должна восстановить эту информацию из базы 150 данных и добавить ее к текущей транзакции. Такая дополнительная информация может быть добавлена в разных местах в ходе транзакции и может включать в себя связь с покупателем 110 или продавцом 120. В возможном варианте с использованием адреса отгрузки у покупателя 110 могут запросить подтвердить адрес, и/или продавец 120 может использовать адрес для вычисления расходов на транспорт, которые, в свою очередь, изменят сумму транзакции в долларах.
Аналогично, служба 130 аутентификации может также обрабатывать (270) транзакцию платежа, например, через шлюз 160, через который осуществляется платеж. В одном крайнем случае служба 130 аутентификации может просто уведомлять (250) продавца 120 о том, что покупатель 110 имеет полномочия использовать средство платежа, но продавец 120 выполняет все остальные этапы, требуемые для обработки средства платежа. В другом крайнем случае служба 130 аутентификации может выполнять этапы для обработки транзакции платежа. В промежуточном случае служба 130 аутентификации выполняет некоторые этапы, а покупатель завершает остальные этапы.
Применение информации профилей покупателей (260) и обработка платежей (270) предпочтительны, поскольку служба 130 аутентификации является, собственно, централизованным пунктом для осуществления таких действий. Как в случае действительных этапов 240-246 аутентификации, может быть реализовано снижение расходов на масштабирование за счет службы 130 аутентификации, выполняющей эти функции, вместо их выполнения каждым индивидуальным продавцом 120.
На стадии 206 регистрации транзакций служба 130 аутентификации сохраняет (280) запись транзакции в архиве 170 транзакций. Достоверность записи будет зависеть от конкретного приложения. Как один возможный вариант, служба 130 аутентификации может просто хранить описания открытого текста транзакции. Как другой возможный вариант, более подходящими могут быть записи с временным маркером, подписанные цифровой подписью. Рассматривая возможный вариант с использованием пароля, упомянутый выше, запись, подписанная цифровой подписью, может быть создана при подписании службой аутентификации записи цифровой подписью с использованием собственного секретного ключа. В возможном варианте с использованием секретного ключа непосредственно покупатель 110 создает запись транзакции, подписанную цифровой подписью, используя свой собственный секретный ключ. В каждом из двух последних примеров результатом является устойчивая (к взлому) запись транзакции, подписанная цифровой подписью, которая может использоваться покупателем НО, продавцом 120 или другими сторонами для разрешения спорных вопросов относительно транзакции.
Фиг. 3-7 иллюстрируют предпочтительный вариант осуществления системы 100 и способа 200. В варианте осуществления с использованием Интернета интерактивная коммерческая транзакция осуществляется через систему, основанную на протоколе передачи гипертекста HTTP, конкретно Интернет. Покупатель 110 получает доступ в Интернет, используя стандартный Web-браузер. Продавцом 120 является электронный продавец, использующий электронную витрину Web-сайта (сайта) в Интернете, в данном случае это фиктивный торговый футбольный центр Пита. Электронная витрина работает на стандартном Web сервере. Служба 130 аутентификации также взаимодействует с Интернетом через Web сервер. Покупатель 110 хочет приобрести в торговом футбольном центре Пита кубок Adidas Eqt. Predator Accelerator, используя в качестве средства платежа свою кредитную карточку. Секретной информацией, используемой для защиты транзакции, является секретный ключ, соответствующий средству платежа. Для удобства этот вариант осуществления будет определен как вариант осуществления на базе Интернет, но это не подразумевает, что данный вариант осуществления является единственно возможным для Интернета.
На фиг. 3 изображена запись событий, иллюстрирующая функционирование варианта осуществления на базе Интернет.
Способ 300, как и способ 200, в общем, может быть разбит на три основных части: регистрация 302 покупателя, аутентификация 304 покупателя и регистрация 306 транзакции. Однако этапы, выполняемые для аутентификации 304 покупателя, и этапы, выполняемые для регистрации 306 транзакции, взаимосвязаны друг с другом.
На стадии регистрации 302 покупателя покупатель 110 устанавливает со службой 130 аутентификации свою "учетную запись". В данном случае это означает, что проводится любая автономная проверка (например, прием подтверждения от компании кредитной карточки, что покупатель 110 имеет полномочия использовать кредитную карточку). Дополнительно для учетной записи формируется пара секретный ключ - открытый ключ, и открытый ключ хранится 312 в базе 150 данных службы аутентификации. В предпочтительном варианте осуществления открытый ключ хранится в форме цифрового сертификата, показывающего, что открытый ключ соответствует учетной записи покупателя.
В этом варианте осуществления учетная запись и пара ключей соответствуют нескольким средствам платежа, включая конкретную кредитную карточку, которая будет использована. Другими словами, цифровой сертификат и пара ключей скорее соответствуют "бумажнику" покупателя, который содержит много средств платежа, чем одному конкретному средству платежа. Однако другие варианты осуществления могут использовать другие схемы, например использование разных учетных записей и пар ключей для каждого средства платежа. Дополнительно покупатель 110 может иметь несколько учетных записей и пар ключей. В этом варианте осуществления секретные ключи покупателя и соответствующие службы инфраструктуры открытого ключа (ИОК) организуются для покупателя 110 агентом программного обеспечения, конкретно Персональным Доверенным Агентом (ПДА) VeriSign. ПДА обеспечивает универсальный ключ и функциональные возможности управления сертификатом и разработан с возможностью простого включения в Web приложения.
ПДА VeriSign управляет удостоверениями личности ИОК покупателя. Например, если покупатель 110 не имеет цифрового сертификата или пары ключей, то ПДА сопровождает покупателя 110 к странице регистрации сертификата. Если цифровой сертификат покупателя скоро истечет, то ПДА предлагает покупателю 110 восстановить сертификат перед продолжением (процесса) и переводит покупателя 110 к странице возобновления сертификата. Также если сертификат покупателя уже истек, то ПДА предлагает вариант перехода на страницу возобновления сертификата для восстановления истекшего сертификата. Все это реализуется посредством диалогов, согласующихся с разными браузерами. Дополнительно, хотя данный конкретный вариант осуществления использует браузеры, ПДА также поддерживает другие устройства, например радиотелефоны и карманные ПДА.
ПДА и секретные ключи могут быть размещены в нескольких местах. В этом возможном варианте на отдельном сервере (не показан) размещено программное обеспечение, реализующее ПДА, и хранятся соответствующие секретные ключи. Одним преимуществом такого подхода является то, что поскольку ПДА и секретные ключи реализуются как нулевой клиент (клиент с нулевым номером), размещенный в службе, то нет необходимости изменять браузер покупателя. Другим преимуществом является то, что, поскольку браузер покупателя не требует никакого специального программного обеспечения, то покупатель 110 потенциально может получить доступ к ПДА и к своим секретным ключам из любого стандартного браузера. Возможный вариант реализации такого доступа описан в находящейся в процессе одновременного рассмотрения патентной заявке США № 09/574.687, "Обеспечиваемое сервером восстановление стойкой секретности из нестойкой секретности", поданной 17 мая 2000 года на имя Warwick Ford. Если ПДА и служба 130 аутентификации размещены на одном сервере, то две функции могут быть до некоторой степени объединены. В другом возможном варианте осуществления ПДА и/или соответствующие секретные ключи реализуются в клиенте покупателя (в программе-клиенте покупателя). Например, ПДА может быть реализован как интегрируемый программный модуль (например, элемент управления ActiveX) в браузере покупателя, а секретные ключи могут храниться локально в программе-клиенте покупателя или в выделенном аппаратном обеспечении (например, устройстве идентификации).
Для рассмотренного выше примера, относящегося к футболу, после регистрации 302 покупатель 110 делает покупки в торговом центре Пита и принимает решение купить некоторые изделия. На фиг. 4 изображен экран браузера покупателя, когда он начинает процесс проверки. Форма заказа 400 в формате гипертекстового языка описания документов (HTML) содержит область 410 заказа, а также кнопку 420 для осуществления срочного аутентифицированного платежа. В области заказа указано, что для этого заказа общая сумма вместе со сбором составляет 59.95$. Покупатель 110 может закончить проверку без аутентификации, используя остальную часть формы, заполняя информацию кредитной карточки, адрес расчета (биллинга) и т.д. Однако покупатель 110 предпочитает использовать аутентифицированный платеж и щелкает кнопку 420 "AuthPay" для осуществления аутентифицированного платежа.
В результате щелчка кнопки 420 аутентифицированного платежа из браузера покупателя передается (330) запрос на аутентификацию в службу 130 аутентификации. Запрос содержит описание транзакции платежа и также идентифицирует продавца 120. Служба 130 аутентификации на этапах 340-346 определяет, имеет ли покупатель 110 доступ к секретной информации (в этом случае секретному ключу для выбранной учетной записи). Более конкретно, служба 130 аутентификации передает (340) покупателю 110 запрос на запрос. В запросе на запрос у покупателя 110 запрашивается подписать некоторые данные цифровой подписью, используя секретный ключ для выбранной учетной записи. Покупатель 110 передает 342 свой ответ на запрос обратно службе 130 аутентификации. Служба 130 аутентификации извлекает открытый ключ, который был сохранен ранее, и использует его для определения (346), имеет ли покупатель 110 доступ к соответствующему секретному ключу. Процесс аутентификации обычно выполняется между компьютерами, без активного участия реального покупателя 110.
В этом варианте осуществления используется также ПДА для обеспечения покупателю 110 возможности выбрать из своих учетных записей учетную запись, которую он предпочитает использовать, и для выбора затем конкретного средства платежа из средств платежа, соответствующих этой учетной записи. Более конкретно, щелчок кнопки 420 вызывает взаимодействие Web-браузера покупателя с ПДА, осуществляемое посредством диалоговых окон, изображенных на фиг. 5А и 5В. Согласно фиг. 5А покупатель 110 определяет учетную запись, которую он предпочитает использовать, заполняя поле 510 Имя Пользователя и затем вводя правильный пароль 520, аутентифицирует себя для ПДА. ПДА отображает диалоговое окно, которое содержит визуальное представление 530 выбранной учетной записи, согласно фиг. 5В. Покупатель 110 подтверждает, что предпочитает использовать эту учетную запись, щелкая кнопку 540 Вход в систему (Регистрация). Тогда становится доступным секретный ключ, соответствующий учетной записи, для аутентификации и цифровой подписи.
Если покупатель 110 безуспешно выполнил этап аутентификации, то служба 130 аутентификации предпринимает соответствующие действия. Например, служба может уведомить продавца 120, что покупатель не был аутентифицирован. В другом варианте служба может отказаться продолжить обработку транзакции и вернуть покупателя 110 к более раннему экрану (например, экрану 400 проверки).
Если покупатель 110 аутентифицирован, то служба 130 аутентификации вносит (360) в транзакцию дополнительную информацию профиля покупателя. В этом случае служба 130 аутентификации извлекает информацию профиля покупателя и передает эту информацию к браузеру в форме, изображенной на фиг.6. Информация содержит разные средства 610 платежа для этой учетной записи, а также разные адреса 620 отгрузки. Информация профиля покупателя может иметь конфиденциальный характер, поэтому предпочтительно, чтобы служба 130 аутентификации аутентифицировала покупателя 110 перед передачей ему этой информации. В форме также повторяется информация 630, касающаяся транзакции. Покупатель 110 выбирает средство 610 платежа и адрес 620 отгрузки и пересылает форму щелчком кнопки Продолжить.
Покупатель 110 и служба 130 аутентификации создают (380) запись транзакции, подписанную цифровой подписью, используя форму и диалоговое окно, которые изображены на фиг. 7А и фиг. 7В. В ответ на представление формы 600 служба 130 аутентификации возвращает форму, изображенную на фиг. 7А, которая содержит краткое описание 710 транзакции и запрос на санкционирование транзакции покупателем 110. Покупатель 110 санкционирует транзакцию, щелкая кнопку 720 Санкционировать Транзакцию. При этом вызывается диалоговое окно ПДА, которое изображено на фиг. 7В. Щелкая кнопку 730 Подписать, покупатель обеспечивает посредством ПДА подписывание краткого описания транзакции цифровой подписью, создавая при этом запись транзакции, подписанную цифровой подписью. Затем служба 130 аутентификации уведомляет 350 продавца 120 о том, что покупатель имеет полномочия использовать средство платежа и предпочтительно также уведомляет покупателя о том, что транзакция была подтверждена.
В этом варианте осуществления служба 130 аутентификации также осуществляет обработку (370) средства платежа для продавца 120 через шлюз платежа 160, например обслуживание потока платежей Payflow, являющегося доступным для VeriSign.
Передача информации между покупателем 110, продавцом 120 и службой 130 аутентификации, согласно способу 300, выполняется с использованием стандартных Web способов. Например, следует отметить, что форма 400 обслуживается продавцом 120, но щелчок кнопки 420 Аутентифицированного Платежа автоматически передает управление браузером покупателя от продавца 120 к службе 130 аутентификации. Также если процесс аутентификации завершен, то браузер покупателя возвращается от службы 130 аутентификации к продавцу 120.
Обе эти передачи выполняются с использованием стандартных способов, например способов Принять (Get), Отправить (Post) и/или Переадресовать. Например, пересылка может быть выполнена методом HTTP POST (Отправить), в форме, содержащей данные, которые будут переданы. Это надежно, но иногда приводит к возникновению нежелательных, промежуточных Web страниц. Однако, чтобы устранить необходимость щелкать по промежуточным страницам, может использоваться автоматически инициируемый командный файл (скрипт) программы-клиента. Другой опцией является HTTP переадресация на унифицированный указатель ресурса URL, содержащий данные, которые будут переданы. Эта опция может устранить промежуточные страницы, но в текущее время ограничена в количестве передаваемых данных (поскольку могут быть переадресованы только передачи HTTP Отправить). Другой опцией является HTTP Переадресация на URL, который имеет ссылки на местоположение данных, которые будут переданы, с фактической передачей данных посредством некоторого другого механизма. Этот способ является более сложным, чем другие два способа, но может устранить промежуточные страницы, не ограничивая количество данных, которые могут быть переданы. Данные передаются с помощью некоторого другого механизма, и в адресате им присваивается идентификатор, и они кэшируются. Затем покупатель 110 переадресуется на URL, содержащий назначенный идентификатор.
В качестве упрощенного примера допустим, что при щелчке кнопки 420 аутентифицированного платежа осуществляется передача службе 130 аутентификации запроса на аутентификацию. В одном варианте осуществления это достигается путем использования формы 400, имеющей следующую структуру:
<form method=post action="https://authpay.verisign.com/ authenticate.dll">
<input type="hidden" name="returnURL" value="https://
www.seller.com/process">
<input type="hidden" name="msg" value="PayerAuth Request goes
here">
<input type=submit value="Auth Pay"> </form>.
При этом https://authpay.verisign.corn/authenticate.dll представляет URL службы 130 аутентификации. Поле returnURL определяет местоположение Web-сайта продавца 120, к которому покупатель 110 возвращается после завершения аутентификации. Поле msg содержит запрос на аутентификацию. Для поддержки дополнительных функций могут использоваться другие поля, например, для внесения информации профиля или для обработки платежа.
После завершения процесса санкционирования платежа управление покупателем 110 передается от службы аутентификации 130 обратно продавцу 120 через HTTP Отправить к returnURL, определенному в запросе. HTML форма, которая передается обратно продавцу 120, имеет следующую структуру:
<form method=post action="https://www.seller.com/process"> <input type="hidden" name="transID" value="123456789"> <input type="hidden" name="msg" value="PayerAuth Response goes here">
<input type=submit value="Continue"> </form>.
Поле transID содержит идентификатор транзакции, который может использоваться покупателем 110 или продавцом 120 для определения транзакции в архиве 170 транзакций. Поле msg содержит ответ продавцу 120 из службы аутентификации 130.
Хотя изобретение подробно описано на примере некоторых предпочтительных вариантов осуществления, возможны другие варианты осуществления. Например, в беспроводных вариантах осуществления (например, основанных на протоколе беспроводных приложений (ПБП) WAP) связь между покупателем 110, продавцом 120 и службой 130 аутентификации, частично или полностью, осуществляется через беспроводные соединения или через шлюзы, соединяющие беспроводную инфраструктуру с проводной инфраструктурой. Например, покупатель 110 может осуществлять связь с помощью карманного устройства, поддерживающего ПБП. Следовательно, изобретение не ограничивается приведенным здесь описанием предпочтительных вариантов осуществления.

Claims (14)

1. Способ аутентификации платежной транзакции в сети, содержащий сохранение открытого ключа, ассоциированного с парой ключей инфраструктуры открытого ключа (ИОК), в базе данных профилей, в ответ на прием запроса аутентификации от покупателя по сети, причем запрос аутентификации включает в себя описание платежной транзакции и идентификацию продавца, передачу покупателю по сети «запроса на запрос», причем «запрос на запрос» включает в себя сводку платежной транзакции для отображения покупателю и подписания покупателем цифровой подписью с использованием секретного ключа, ассоциированного с парой ключей ИОК,
в ответ на прием «ответа на запрос» от покупателя по сети, причем «ответ на запрос» включает в себя подписанную цифровой подписью сводку платежной транзакции, определение, имеет ли покупатель доступ к секретному ключу, с использованием открытого ключа для дешифрования подписанной цифровой подписью сводки платежной транзакции, при определении этого, сохранение подписанной цифровой подписью записи платежной транзакции в архиве транзакций и передачу ответа аутентификации продавцу по сети.
2. Способ по п.1, дополнительно содержащий создание пары ключей ИОК и передачу секретного ключа покупателю по сети.
3. Способ по п.1, в котором запись платежной транзакции подписывается цифровой подписью с использованием секретного ключа.
4. Способ по п.1, в котором запись интерактивной транзакции подписывается цифровой подписью с использованием локального секретного ключа.
5. Способ по п.1, в котором открытый ключ сохранен в форме цифрового сертификата, представляющего, что открытый ключ связан с покупателем.
6. Способ по п.1, дополнительно содержащий
извлечение профиля покупателя из базы данных, причем профиль покупателя содержит множество инструментов платежа и множество адресов отгрузки, передачу профиля покупателя по сети покупателю и
прием варианта выбора одного из множества инструментов платежа и одного из множества адресов отгрузки от покупателя по сети.
7. Способ по п.1, дополнительно содержащий обработку платежной транзакции посредством шлюза платежа.
8. Система для аутентификации платежной транзакции по сети, содержащая web-сервер службы аутентификации, связанный с базой данных профилей покупателей, архивом транзакций и сетью, причем web-сервер службы аутентификации адаптивно конфигурирован для сохранения открытого ключа, ассоциированного с парой ключей инфраструктуры открытого ключа (ИОК) транзакции покупателя, в базе данных профилей покупателей, средство покупателя выполнено в виде средства просмотра Web-браузера и предназначено для доступа покупателя в сеть Интернет и запроса аутентификации платежной операции от средства покупателя, включающего в себя описание платежной транзакции покупателя и идентификацию продавца, при этом web-сервер службы аутентификации предназначен для приема по сети запроса аутентификации от средства покупателя, передачи по сети на указанное средство покупателя «запроса на запрос», включающего сводку платежной транзакции для отображения ее покупателю и для подписания покупателем цифровой подписью с использованием секретного ключа, ассоциированного с парой ключей ИОК, сохраняемых в базе данных профилей покупателя, а также приема «ответа на запрос» от средства покупателя, включающего подписанную цифровой подписью сводку платежной транзакции, добавления к данным транзакции информации профиля покупателя из базы данных профиля покупателей, а также определения, имеет ли покупатель доступ к секретному ключу, с использованием открытого ключа для дешифрования подписанной цифровой подписью сводки платежной транзакции,
причем web-сервер службы аутентификации при определении доступа покупателя предназначен также для регистрации записи платежной транзакции, подписанной цифровой подписью, в архиве транзакций и передачи ответа аутентификации по сети на адрес продавца.
9. Система по п.8, в которой web-сервер службы аутентификации дополнительно предназначен для создания пары ключей ИОК и передачи секретного ключа покупателю по сети.
10. Система по п.8, в которой запись платежной транзакции подписывается цифровой подписью с использованием секретного ключа.
11. Система по п.8, в которой запись интерактивной транзакции подписывается цифровой подписью с использованием локального секретного ключа.
12. Система по п.8, в которой открытый ключ сохранен в форме цифрового сертификата, представляющего, что открытый ключ связан с покупателем.
13. Система по п.8, в которой web-сервер службы аутентификации дополнительно предназначен для
извлечения профиля покупателя из базы данных, причем профиль покупателя содержит множество инструментов платежа и множество адресов отгрузки, передачи профиля покупателя по сети покупателю и
приема варианта выбора одного из множества инструментов платежа и одного из множества адресов отгрузки от покупателя по сети.
14. Система по п.8, в которой web-сервер службы аутентификации дополнительно предназначен для обработки платежной транзакции посредством шлюза платежа.
RU2002130717/09A 2000-04-17 2001-04-17 Аутентифицированный платеж RU2292589C2 (ru)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US19811000P 2000-04-17 2000-04-17
US60/198,110 2000-04-17
US09/818,084 US7778934B2 (en) 2000-04-17 2001-03-26 Authenticated payment
US09/818,084 2001-03-26

Publications (2)

Publication Number Publication Date
RU2002130717A RU2002130717A (ru) 2004-03-10
RU2292589C2 true RU2292589C2 (ru) 2007-01-27

Family

ID=26893486

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2002130717/09A RU2292589C2 (ru) 2000-04-17 2001-04-17 Аутентифицированный платеж

Country Status (15)

Country Link
US (3) US7778934B2 (ru)
EP (1) EP1275091A2 (ru)
JP (1) JP4880171B2 (ru)
KR (1) KR100844046B1 (ru)
CN (1) CN1437741A (ru)
AU (2) AU2001259080B2 (ru)
BR (1) BR0110140A (ru)
CA (1) CA2406138C (ru)
IL (1) IL152324A (ru)
MX (1) MXPA02010220A (ru)
NO (1) NO325783B1 (ru)
NZ (1) NZ522162A (ru)
RU (1) RU2292589C2 (ru)
WO (1) WO2001078493A2 (ru)
ZA (1) ZA200208366B (ru)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2563163C2 (ru) * 2010-01-19 2015-09-20 Виза Интернэшнл Сервис Ассосиэйшн Обработка аутентификации удаленной переменной
RU2644514C2 (ru) * 2013-09-18 2018-02-12 Мастеркард Интернэшнл Инкорпорейтед Способы и системы для проверки транзакций перевода электронных денежных средств
RU2669081C2 (ru) * 2013-07-24 2018-10-08 Виза Интернэшнл Сервис Ассосиэйшн Системы и способы для функционально совместимой обработки сетевых маркеров
RU2693635C1 (ru) * 2018-06-01 2019-07-03 Общество с ограниченной ответственностью "МКС Адвертайзинг" (ООО "МКС Адвертайзинг") Способ и система выполнения онлайн транзакций с помощью механизма генерации скидочных кодов
US11710119B2 (en) 2013-10-11 2023-07-25 Visa International Service Association Network token system

Families Citing this family (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7778934B2 (en) * 2000-04-17 2010-08-17 Verisign, Inc. Authenticated payment
WO2001082246A2 (en) 2000-04-24 2001-11-01 Visa International Service Association Online payer authentication service
CA2878813C (en) * 2000-07-10 2017-10-24 Paypal, Inc. System and method for verifying a financial instrument
US8799463B1 (en) * 2000-10-19 2014-08-05 Ariba, Inc. Method and apparatus for processing information related to interactive web sites
US20070288394A1 (en) * 2000-12-01 2007-12-13 Carrott Richard F Transactional security over a network
GB2376312B (en) * 2001-06-04 2004-12-29 Hewlett Packard Co Digital certificate expiry notification
CA2463891C (en) 2001-10-17 2012-07-17 Npx Technologies Ltd. Verification of a person identifier received online
US7725404B2 (en) * 2002-02-27 2010-05-25 Imagineer Software, Inc. Secure electronic commerce using mutating identifiers
US7899753B1 (en) 2002-03-25 2011-03-01 Jpmorgan Chase Bank, N.A Systems and methods for time variable financial authentication
US20030187778A1 (en) * 2002-03-27 2003-10-02 First Data Corporation Merchant application and underwriting systems and methods
US7707120B2 (en) * 2002-04-17 2010-04-27 Visa International Service Association Mobile account authentication service
US7693783B2 (en) 2002-06-12 2010-04-06 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US8645266B2 (en) 2002-06-12 2014-02-04 Cardinalcommerce Corporation Universal merchant platform for payment authentication
WO2004025413A2 (en) * 2002-09-10 2004-03-25 Visa International Service Association Data authentication and provisioning method and system
US7703128B2 (en) * 2003-02-13 2010-04-20 Microsoft Corporation Digital identity management
US8219801B2 (en) 2003-03-10 2012-07-10 International Business Machines Corporation Method of authenticating digitally encoded products without private key sharing
US7320073B2 (en) 2003-04-07 2008-01-15 Aol Llc Secure method for roaming keys and certificates
US7653602B2 (en) 2003-11-06 2010-01-26 Visa U.S.A. Inc. Centralized electronic commerce card transactions
US8762283B2 (en) * 2004-05-03 2014-06-24 Visa International Service Association Multiple party benefit from an online authentication service
KR100930457B1 (ko) 2004-08-25 2009-12-08 에스케이 텔레콤주식회사 이동통신단말을 이용한 인증 및 결제 시스템과 방법
EP1908215A1 (fr) * 2005-07-26 2008-04-09 France Télécom Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
KR100654039B1 (ko) * 2005-11-14 2006-12-05 에스케이 텔레콤주식회사 무선 인터넷에서 서비스 서버의 인증방법 및 이를 이용한결제방법
EP1843288A1 (fr) * 2006-04-05 2007-10-10 Elca Informatique S.A. Sécurisation de transactions électroniques sur un réseau ouvert
US20080027982A1 (en) * 2006-07-27 2008-01-31 Ebay Inc. Indefinite caching expiration techniques
US20080162362A1 (en) * 2006-12-28 2008-07-03 Microsoft Corporation Increasing transaction authenticity with product license keys
US9418501B2 (en) * 2007-02-05 2016-08-16 First Data Corporation Method for digital signature authentication of pin-less debit card account transactions
US8666841B1 (en) 2007-10-09 2014-03-04 Convergys Information Management Group, Inc. Fraud detection engine and method of using the same
GB2459529A (en) * 2008-04-28 2009-11-04 Ice Organisation Online transaction authentication using two servers
US10157375B2 (en) 2008-06-03 2018-12-18 Cardinalcommerce Corporation Alternative payment implementation for electronic retailers
US8762210B2 (en) 2008-06-03 2014-06-24 Cardinalcommerce Corporation Alternative payment implementation for electronic retailers
US20090307140A1 (en) * 2008-06-06 2009-12-10 Upendra Mardikar Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
US8412625B2 (en) * 2008-08-25 2013-04-02 Bruno Pilo' & Associates, Llc System and methods for a multi-channel payment platform
US8566235B2 (en) * 2008-12-23 2013-10-22 Verifi, Inc. System and method for providing dispute resolution for electronic payment transactions
US8595098B2 (en) 2009-03-18 2013-11-26 Network Merchants, Inc. Transmission of sensitive customer information during electronic-based transactions
US9665868B2 (en) * 2010-05-10 2017-05-30 Ca, Inc. One-time use password systems and methods
US20120036048A1 (en) 2010-08-06 2012-02-09 Diy Media, Inc. System and method for distributing multimedia content
FR2963975A1 (fr) * 2010-08-20 2012-02-24 In Webo Tech Systeme de paiement en ligne
US8739260B1 (en) 2011-02-10 2014-05-27 Secsign Technologies Inc. Systems and methods for authentication via mobile communication device
US20120215658A1 (en) * 2011-02-23 2012-08-23 dBay Inc. Pin-based payment confirmation
US20120226611A1 (en) * 2011-03-01 2012-09-06 Nimish Radia Method and system for conducting a monetary transaction using a mobile communication device
US8719952B1 (en) 2011-03-25 2014-05-06 Secsign Technologies Inc. Systems and methods using passwords for secure storage of private keys on mobile devices
DE102011110898A1 (de) * 2011-08-17 2013-02-21 Advanced Information Processing Systems Sp. z o.o. Verfahren zur Authentifizierung eines Benutzers zum Gewähren eines Zugangs zu Diensten eines Computersystems, sowie zugehöriges Computersystem, Authentifizierungsserver und Kommunikationsgerät mit Authentifizierungsapplikation
US8862767B2 (en) 2011-09-02 2014-10-14 Ebay Inc. Secure elements broker (SEB) for application communication channel selector optimization
US20130085944A1 (en) * 2011-09-29 2013-04-04 Pacid Technologies, Llc System and method for application security
EP2579199A1 (fr) * 2011-10-06 2013-04-10 Gemalto SA Procédé de paiement d'un produit ou d'un service sur un site marchand par l'intermédiaire d'une connexion Internet et terminal correspondant
US20130124415A1 (en) * 2011-11-11 2013-05-16 Ebay Inc. Systems and methods for secure authentication using a watermark
US20130132281A1 (en) * 2011-11-22 2013-05-23 Xerox Corporation Computer-implemented method for capturing data using provided instructions
US8595808B2 (en) * 2011-12-16 2013-11-26 Daon Holdings Limited Methods and systems for increasing the security of network-based transactions
GB2501229A (en) * 2012-02-17 2013-10-23 Elendra Raja A method verifying the authenticity of a data source
US10275764B2 (en) 2012-05-04 2019-04-30 Mastercard International Incorporated Transaction data tokenization
US9654466B1 (en) * 2012-05-29 2017-05-16 Citigroup Technology, Inc. Methods and systems for electronic transactions using dynamic password authentication
RU2509359C1 (ru) * 2012-09-26 2014-03-10 Пэйче Лтд. Способ подтверждения платежа
US10217108B1 (en) 2013-03-29 2019-02-26 Wells Fargo Bank, N.A. Systems and methods for assisted transactions using an information wallet
US10055732B1 (en) 2013-03-29 2018-08-21 Wells Fargo Bank, N.A. User and entity authentication through an information storage and communication system
US10037561B1 (en) 2013-03-29 2018-07-31 Wells Fargo Bank, N.A. Systems and methods for managing lists using an information storage and communication system
US10530646B1 (en) 2013-03-29 2020-01-07 Wells Fargo Bank, N.A. Systems and methods for providing user preferences for a connected device
US10387928B1 (en) 2013-03-29 2019-08-20 Wells Fargo Bank, N.A. Systems and methods for transferring a gift using an information storage and communication system
CN105474244A (zh) * 2013-08-20 2016-04-06 惠普发展公司，有限责任合伙企业 支付联合服务
FR3011964B1 (fr) * 2013-10-14 2017-02-10 Keydentify Procede automatise d'authentification forte multifacteur
US10990974B1 (en) * 2015-01-15 2021-04-27 Wells Fargo Bank, N.A. Identity verification services and user information provision via application programming interface
US10997654B1 (en) 2015-01-15 2021-05-04 Wells Fargo Bank, N.A. Identity verification services through external entities via application programming interface
US10937025B1 (en) 2015-01-15 2021-03-02 Wells Fargo Bank, N.A. Payment services via application programming interface
US10621658B1 (en) 2015-01-15 2020-04-14 Wells Fargo Bank, N.A. Identity verification services with identity score through external entities via application programming interface
CN107230155A (zh) * 2016-06-08 2017-10-03 北京知果科技有限公司 一种商标撤三保险理赔系统、方法
CN109644131B (zh) 2016-07-15 2022-04-26 卡迪纳尔贸易公司 使用富化消息对授权桥接进行认证
USD844658S1 (en) 2017-01-20 2019-04-02 Verisign, Inc. Display screen or portion thereof with a sequential graphical user interface
US10904211B2 (en) 2017-01-21 2021-01-26 Verisign, Inc. Systems, devices, and methods for generating a domain name using a user interface
USD844649S1 (en) 2017-07-28 2019-04-02 Verisign, Inc. Display screen or portion thereof with a sequential graphical user interface
USD882602S1 (en) 2017-07-28 2020-04-28 Verisign, Inc. Display screen or portion thereof with a sequential graphical user interface of a mobile device
US10462150B2 (en) * 2017-10-13 2019-10-29 Bank Of America Corporation Multicomputer processing of user data with centralized event control
US11106515B1 (en) 2017-12-28 2021-08-31 Wells Fargo Bank, N.A. Systems and methods for multi-platform product integration
US11676126B1 (en) 2017-12-28 2023-06-13 Wells Fargo Bank, N.A. Account open interfaces
US11995619B1 (en) 2017-12-28 2024-05-28 Wells Fargo Bank, N.A. Account open interfaces
US10942959B1 (en) 2018-02-06 2021-03-09 Wells Fargo Bank, N.A. Authenticated form completion using data from a networked data repository
US11093912B1 (en) 2018-12-10 2021-08-17 Wells Fargo Bank, N.A. Third-party payment interfaces
WO2020222143A1 (en) * 2019-04-29 2020-11-05 Mobeewave Systems Ulc System and method of operating a secure contactless transaction
US20200372496A1 (en) * 2019-05-23 2020-11-26 Clear Labs Israel Ltd. System and method for validation of business transactions
US11044246B1 (en) 2019-06-21 2021-06-22 Wells Fargo Bank, N.A. Secure communications via third-party systems through frames
US11328274B2 (en) 2020-07-28 2022-05-10 Bank Of America Corporation Data processing system and method for managing electronic split transactions using user profiles
CN117575613B (zh) * 2024-01-15 2024-08-13 山东鼎信数字科技有限公司 一种动态访问环境的鉴权支付方法及系统
CN117742843B (zh) * 2024-02-20 2024-06-04 张家港保税数据科技有限公司 一种交割服务业务表单生成方法和系统

Family Cites Families (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5905248A (en) * 1990-09-11 1999-05-18 Metrologic Instruments, Inc. System and method for carrying out information-related transactions using web documents embodying transaction enabling applets automatically launched and executed in response to reading URL-encoded symbols pointing thereto
US5794207A (en) 1996-09-04 1998-08-11 Walker Asset Management Limited Partnership Method and apparatus for a cryptographically assisted commercial network system designed to facilitate buyer-driven conditional purchase offers
EP0734556B1 (en) * 1993-12-16 2002-09-04 Open Market, Inc. Network based payment system and method for using such system
US5420926A (en) 1994-01-05 1995-05-30 At&T Corp. Anonymous credit card transactions
JPH0896034A (ja) * 1994-09-27 1996-04-12 Shosaku Kawai 通信ネットワークにおけるオンライン決済方法
US5633930A (en) 1994-09-30 1997-05-27 Electronic Payment Services, Inc. Common cryptographic key verification in a transaction network
US5715314A (en) 1994-10-24 1998-02-03 Open Market, Inc. Network sales system
US5748737A (en) * 1994-11-14 1998-05-05 Daggar; Robert N. Multimedia electronic wallet with generic card
CN1912885B (zh) * 1995-02-13 2010-12-22 英特特拉斯特技术公司 用于安全交易管理和电子权利保护的系统和方法
US5878141A (en) 1995-08-25 1999-03-02 Microsoft Corporation Computerized purchasing system and method for mediating purchase transactions over an interactive network
US5710887A (en) 1995-08-29 1998-01-20 Broadvision Computer system and method for electronic commerce
JP3365599B2 (ja) * 1996-02-08 2003-01-14 株式会社エヌ・ティ・ティ・データ 電子小切手システム
US6178409B1 (en) 1996-06-17 2001-01-23 Verifone, Inc. System, method and article of manufacture for multiple-entry point virtual point of sale architecture
WO1997049052A2 (en) 1996-06-17 1997-12-24 Verifone, Inc. A system, method and article of manufacture for a gateway payment architecture utilizing a multichannel, extensible, flexible architecture
US6324525B1 (en) 1996-06-17 2001-11-27 Hewlett-Packard Company Settlement of aggregated electronic transactions over a network
US5850446A (en) 1996-06-17 1998-12-15 Verifone, Inc. System, method and article of manufacture for virtual point of sale processing utilizing an extensible, flexible architecture
FR2750274B1 (fr) 1996-06-21 1998-07-24 Arditti David Procede de prise en compte d'une demande d'utilisation d'une carte prepayee virtuelle permettant la reutilisation de son numero de serie
US5793028A (en) 1996-06-24 1998-08-11 Fred N. Gratzon Electronic transaction security system
US6029150A (en) 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
US6212634B1 (en) 1996-11-15 2001-04-03 Open Market, Inc. Certifying authorization in computer networks
US5996076A (en) 1997-02-19 1999-11-30 Verifone, Inc. System, method and article of manufacture for secure digital certification of electronic commerce
US5903721A (en) * 1997-03-13 1999-05-11 cha|Technologies Services, Inc. Method and system for secure online transaction processing
US6125185A (en) 1997-05-27 2000-09-26 Cybercash, Inc. System and method for encryption key generation
JPH10334164A (ja) * 1997-06-04 1998-12-18 Nippon Telegr & Teleph Corp <Ntt> 電子小切手方法、その装置およびその実行プログラム記録媒体
US6018724A (en) 1997-06-30 2000-01-25 Sun Micorsystems, Inc. Method and apparatus for authenticating on-line transaction data
US5899980A (en) 1997-08-11 1999-05-04 Trivnet Ltd. Retail method over a wide area network
US6000832A (en) 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions
US6047268A (en) * 1997-11-04 2000-04-04 A.T.&T. Corporation Method and apparatus for billing for transactions conducted over the internet
US6073237A (en) 1997-11-06 2000-06-06 Cybercash, Inc. Tamper resistant method and apparatus
US6098053A (en) * 1998-01-28 2000-08-01 Citibank, N.A. System and method for performing an electronic financial transaction
NL1008372C2 (nl) 1998-02-20 1999-08-24 Snoek Holding Zoetermeer B V Werkwijze voor betalen via Internet.
AU3108199A (en) * 1998-03-24 1999-10-18 Telcordia Technologies, Inc. A method for using a telephone calling card for business transactions
JPH11296603A (ja) * 1998-04-09 1999-10-29 Nippon Telegr & Teleph Corp <Ntt> 電子小切手方法
US20030140007A1 (en) 1998-07-22 2003-07-24 Kramer Glenn A. Third party value acquisition for electronic transaction settlement over a network
KR100358426B1 (ko) 1998-08-18 2003-01-29 한국전자통신연구원 전자현금거래방법
US6607136B1 (en) 1998-09-16 2003-08-19 Beepcard Inc. Physical presence digital authentication system
US6327662B1 (en) * 1998-09-30 2001-12-04 3Com Corporation Security through the use of tokens and automatically downloaded applets
US6154543A (en) * 1998-11-25 2000-11-28 Hush Communications Anguilla, Inc. Public key cryptosystem with roaming user capability
US6473740B2 (en) 1998-11-29 2002-10-29 Qpass, Inc. Electronic commerce using a transaction network
CA2291920A1 (en) 1998-12-11 2000-06-11 Karuna Ganesan Technique for conducting secure transactions over a network
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US6697824B1 (en) 1999-08-31 2004-02-24 Accenture Llp Relationship management in an E-commerce application framework
US7343351B1 (en) * 1999-08-31 2008-03-11 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions
US7742967B1 (en) 1999-10-01 2010-06-22 Cardinalcommerce Corporation Secure and efficient payment processing system
CA2392229C (en) 1999-11-30 2016-08-30 Transforming Technologies, Inc. Methods, systems, and apparatuses for secure interactions
US6738901B1 (en) * 1999-12-15 2004-05-18 3M Innovative Properties Company Smart card controlled internet access
US6516056B1 (en) 2000-01-07 2003-02-04 Vesta Corporation Fraud prevention system and method
US20010044787A1 (en) * 2000-01-13 2001-11-22 Gil Shwartz Secure private agent for electronic transactions
US7140036B2 (en) 2000-03-06 2006-11-21 Cardinalcommerce Corporation Centralized identity authentication for electronic communication networks
EP1132797A3 (en) 2000-03-08 2005-11-23 Aurora Wireless Technologies, Ltd. Method for securing user identification in on-line transaction systems
CN1365475A (zh) * 2000-03-17 2002-08-21 索尼公司 投资系统和数据发送/接收方法
US7778934B2 (en) * 2000-04-17 2010-08-17 Verisign, Inc. Authenticated payment
WO2001082246A2 (en) 2000-04-24 2001-11-01 Visa International Service Association Online payer authentication service
US10185936B2 (en) 2000-06-22 2019-01-22 Jpmorgan Chase Bank, N.A. Method and system for processing internet payments
US7552333B2 (en) * 2000-08-04 2009-06-23 First Data Corporation Trusted authentication digital signature (tads) system
JP4581200B2 (ja) * 2000-08-31 2010-11-17 ソニー株式会社 個人認証システム、個人認証方法、および情報処理装置、並びにプログラム提供媒体
US20020129256A1 (en) * 2001-03-07 2002-09-12 Diebold, Incorporated Automated transaction machine digital signature system and method
US6915279B2 (en) 2001-03-09 2005-07-05 Mastercard International Incorporated System and method for conducting secure payment transactions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Норенков В.А. и др. Телекоммуникационные технологии и сети, Москва, МГТУ имени Н.Э.Баумана, 1998, стр.153. *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2563163C2 (ru) * 2010-01-19 2015-09-20 Виза Интернэшнл Сервис Ассосиэйшн Обработка аутентификации удаленной переменной
RU2669081C2 (ru) * 2013-07-24 2018-10-08 Виза Интернэшнл Сервис Ассосиэйшн Системы и способы для функционально совместимой обработки сетевых маркеров
US11093936B2 (en) 2013-07-24 2021-08-17 Visa International Service Association Systems and methods for communicating token attributes associated with a token vault
US11915235B2 (en) 2013-07-24 2024-02-27 Visa International Service Association Systems and methods for communicating token attributes associated with a token vault
RU2644514C2 (ru) * 2013-09-18 2018-02-12 Мастеркард Интернэшнл Инкорпорейтед Способы и системы для проверки транзакций перевода электронных денежных средств
US11710119B2 (en) 2013-10-11 2023-07-25 Visa International Service Association Network token system
RU2693635C1 (ru) * 2018-06-01 2019-07-03 Общество с ограниченной ответственностью "МКС Адвертайзинг" (ООО "МКС Адвертайзинг") Способ и система выполнения онлайн транзакций с помощью механизма генерации скидочных кодов

Also Published As

Publication number Publication date
CA2406138C (en) 2014-09-30
ZA200208366B (en) 2003-07-17
NO20024982D0 (no) 2002-10-16
KR100844046B1 (ko) 2008-07-04
JP4880171B2 (ja) 2012-02-22
US7983993B2 (en) 2011-07-19
NO20024982L (no) 2002-12-17
RU2002130717A (ru) 2004-03-10
US20100293100A1 (en) 2010-11-18
AU2001259080B2 (en) 2006-12-07
JP2003530655A (ja) 2003-10-14
KR20020086955A (ko) 2002-11-20
WO2001078493A3 (en) 2002-04-04
CA2406138A1 (en) 2001-10-25
MXPA02010220A (es) 2004-08-12
US20110276492A1 (en) 2011-11-10
NZ522162A (en) 2005-05-27
IL152324A (en) 2010-12-30
AU5908001A (en) 2001-10-30
IL152324A0 (en) 2003-05-29
CN1437741A (zh) 2003-08-20
US20040177047A1 (en) 2004-09-09
BR0110140A (pt) 2003-06-03
WO2001078493A2 (en) 2001-10-25
NO325783B1 (no) 2008-07-14
US7778934B2 (en) 2010-08-17
EP1275091A2 (en) 2003-01-15

Similar Documents

Publication Publication Date Title
RU2292589C2 (ru) Аутентифицированный платеж
AU777762B2 (en) Electronic transactions and payments system
RU2438172C2 (ru) Способ и система для осуществления двухфакторной аутентификации при транзакциях, связанных с заказами по почте и телефону
USRE40444E1 (en) Four-party credit/debit payment protocol
US8898762B2 (en) Payment transaction processing using out of band authentication
US5671279A (en) Electronic commerce using a secure courier system
US6675153B1 (en) Transaction authorization system
US6205437B1 (en) Open network payment system for providing for real-time authorization of payment and purchase transactions
AU2001259080A1 (en) Authenticated payment
RU2301449C2 (ru) Способ осуществления многофакторной строгой аутентификации держателя банковской карты с использованием мобильного телефона в среде мобильной связи при осуществлении межбанковских финансовых транзакций в международной платежной системе по протоколу спецификации 3-d secure (варианты) и реализующая его система
US20030069792A1 (en) System and method for effecting secure online payment using a client payment card
JP2003531447A (ja) バーチャル安全のための方法およびシステム
KR20030019466A (ko) 정보의 안전한 수집, 기억, 전송 방법 및 장치
AU2001248198A1 (en) A method and system for a virtual safe
AU3285599A (en) Computer-based method and system for aiding transactions
US6742125B1 (en) Distributed protocol for secure communication of commercial transactions and decentralized network employing the protocol
JPH10171887A (ja) オンラインショッピングシステム
KR100822985B1 (ko) 닉네임을 이용한 지불결제 처리 시스템
WO2002003214A1 (en) Certification system

Legal Events

Date Code Title Description
MM4A The patent is invalid due to non-payment of fees

Effective date: 20170418