Адаптируемый обмен сообщениями
Изобретение относится к способу и мобильному устройству для передачи данных транзакции платежа. Технический результат заключается в автоматизации проведения платежных транзакций. В способе принимают посредством мобильного устройства запрос пользователя на инициирование транзакции с продавцом; передают посредством мобильного устройства сообщение инициирования транзакции платежа на сервер продавца, ассоциированный с упомянутым продавцом; принимают посредством мобильного устройства сообщение-запрос от упомянутого сервера продавца для данных удаленного платежа, причем упомянутое сообщение-запрос идентифицирует выбранный формат данных, поддерживаемый сервером продавца, причем выбранный формат данных идентифицирует по меньшей мере один из первого формата данных и альтернативного формата данных; генерируют посредством мобильного устройства данные удаленного платежа на основе выбранного формата данных; и передают посредством мобильного устройства упомянутые данные удаленного платежа упомянутому серверу продавца в упомянутом выбранном формате данных для инициирования обработки авторизации упомянутой транзакции. 2 н. и 16 з.п. ф-лы, 4 ил., 4 табл.
ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ
По этой заявка испрашивается приоритет и преимущество по дате подачи заявки США номер 14/881,249, поданной 13 октября 2015 года, которая в полном объеме включена в настоящий документ посредством ссылки.
УРОВЕНЬ ТЕХНИКИ
Потребителям все чаще приходится совершать покупки с использованием таких устройств, как мобильные телефоны или подобное. Эти удаленные транзакции покупок создают проблемы для финансовых учреждений и других объектов. Например, эти транзакции представляют проблемы, связанные с аутентификацией пользователя и другими вопросами, связанными с мошенничеством. Было предложено некоторое количество подходов для улучшения аутентификации пользователя и уменьшения мошенничества в удаленных транзакциях. Например, одним из желаемых подходов является использование функциональных возможностей безопасности и аутентификации, обеспечиваемых стандартами EMV (на www.emvco.com) в удаленных транзакциях. Однако не все онлайн-системы или удаленные системы продавцов поддерживают эти стандарты. Было бы желательно обеспечить системы и способы, которые позволят удаленным транзакциям из браузера, на мобильных устройствах, в приложении или тому подобное, обеспечивать хороший пользовательский опыт при одновременном уменьшении мошенничества.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Признаки и преимущества некоторых вариантов осуществления настоящего изобретения и методика их выполнения без труда станут более очевидными после рассмотрения следующего подробного описания изобретения, рассмотренного в сочетании с прилагаемыми чертежами, которые иллюстрируют предпочтительные и примерные варианты осуществления и которые не обязательно нарисованы в масштабе, при этом:
Фиг. 1 представляет собой блок-схему, которая иллюстрирует систему, в которой может быть применено настоящее изобретение.
Фиг. 2 представляет собой блок-схему, которая иллюстрирует примерный вариант осуществления смартфона с поддержкой платежа, обеспеченного в соответствии с аспектами настоящего изобретения.
Фиг. 3 представляет собой информационную схему последовательности операций, показывающую функциональные программные блоки, обеспеченные в смартфоне с Фиг. 2, в соответствии с аспектами настоящего изобретения.
Фиг.4 представляет собой блок-схему последовательности операций, которая иллюстрирует процесс, который может быть выполнен в смартфоне с Фиг. 2 согласно аспектам настоящего изобретения.
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ
Варианты осуществления настоящего изобретения обеспечивают системы, способы, устройство и код компьютерного программирования, чтобы оперировать устройством для завершения транзакции. В этом документе описаны варианты осуществления, которые включают в себя прием запроса на инициирование транзакции с продавцом, передачу сообщения инициирования транзакции платежа на сервер продавца, ассоциированный с продавцом, прием сообщения-запроса от сервера продавца для данных удаленного платежа, причем сообщение-запрос включает в себя информацию, идентифицирующую, поддерживает ли сервер продавца выбранный один из первого формата данных и альтернативного формата данных, и обеспечение данных удаленного платежа серверу продавца в выбранном формате данных для использования сервером продавца, чтобы инициировать обработку авторизации транзакции.
Фиг. 1 представляет собой блок-схему, которая иллюстрирует систему 100, в которой может быть применено настоящее изобретение. Для иллюстративных целей признаки настоящего изобретения будут описаны в контексте использования мобильного устройства 102 с поддержкой платежа, однако специалистам в данной области техники будет понятно, что признаки настоящего изобретения могут быть использованы с желаемыми результатами в транзакциях с привлечением также других устройств (таких как планшет или другие вычислительные устройства). Как показано, система 100 включает в себя мобильное устройство 102 с поддержкой платежа. Мобильное устройство 102 может работать как мобильный телефон и в то же время может выполнять функции бесконтактной платежной карты, как обеспечено в соответствии с аспектами настоящего изобретения и как описано ниже по тексту. Дополнительные подробности о мобильном устройстве 102 описаны ниже по тексту в связи с Фиг. 2-3.
Как показано, система 100 дополнительно включает в себя сервер 106 продавца, поддерживающий связь с мобильным устройством 102. Хотя изображено только одно мобильное устройство 102 и сервер 106 продавца, система 100, вероятно, заключает в себе множество обоих устройств. Например, некоторое количество потребителей, оперирующих некоторым количеством мобильных устройств 102, могут взаимодействовать с множеством различных продавцов, оперирующих серверами 106 продавцов, для упрощения транзакций в соответствии с настоящим изобретением. Взаимодействие между мобильным устройством 102 и сервером 106 продавца может быть, например, беспроводным взаимодействием по сетевому интерфейсу. Например, мобильное устройство 102 может взаимодействовать с сервером 106 продавца для проведения транзакции покупки по сети связи мобильного телефона с использованием протокола, такого как HTTP (протокол передачи гипертекста) или подобного. В некоторых вариантах осуществления связь между мобильным устройством 102 и сервером 106 продавца может быть упрощена или может управляться посредством мобильного приложения, установленного на мобильном устройстве 102 (например, такого как приложение продавца на мобильном устройстве).
В соответствии с некоторыми вариантами осуществления мобильное устройство 102 может проводить транзакции с сервером 106 продавца из браузера на мобильном устройстве 102 или из приложения на мобильном устройстве 102, которое взаимодействует с сервером 104 платежей (который также может упоминаться в этом документе как "сервер-бумажник"). Мобильное устройство 102 может хранить информацию, ассоциированную с одним или несколькими бумажниками платежей, которые соответствуют одному или нескольким бумажникам на сервере-бумажнике. В соответствии с некоторыми вариантами осуществления транзакции обрабатываются с использованием протокола защищенного платежа, который может упоминаться в этом документе как "цифровой защищенный удаленный платеж" (DSRP), который обеспечивает улучшенное предотвращение от мошенничества (что в некоторых вариантах осуществления может позволить уменьшить ответственность за мошенничество для продавца). Как будет описано, варианты осуществления обеспечивают некоторое количество преимуществ, включающих в себя, например, улучшенный пользовательский опыт для пользователей, проводящих транзакции с использованием мобильного устройства 102, множество мобильных специфических вариантов использования (таких как покупки в магазине самообслуживания или тому подобное), потенциальный сдвиг ответственности (с точки зрения продавца и пользователя) и улучшенная аутентификация пользователя.
Признаки транзакций в соответствии с некоторыми вариантами осуществления теперь будут описаны со ссылкой на компоненты с Фиг. 1. В общем, транзакция может быть инициирована пользователем, оперирующим мобильным устройством 102, например, посредством инициирования запроса на покупку товара или услуги у продавца (например, из приложения или браузера мобильного устройства 102 при осуществлении связи с продавцом). Сервер 106 продавца, ассоциированный с продавцом, осуществляет связь с мобильным устройством 102 для запроса, чтобы приложение продавца мобильного устройства 102 (как показано на Фиг. 3) выполнило транзакцию платежа. Включенная в запрос информация идентифицирует тип формата данных, поддерживаемого сервером 106 продавца. Например, как используется в этом документе, будут описаны варианты осуществления, в которых сервер продавца может поддерживать (или быть сконфигурирован с возможностью поддержки конкретных транзакций) "первый формат данных" или "альтернативный формат данных". В некоторых вариантах осуществления могут быть использованы несколько форматов данных. Например, в этом документе будут описаны некоторые варианты осуществления, которые используют "первый формат данных", "второй формат данных" и "третий формат данных". Используемый в этом документе термин "альтернативный формат данных" или "второй формат данных" обычно относится к формату, отличному от "первого формата данных", такому как "второй формат данных", "третий формат данных" или другие вариации.
В качестве конкретного примера первым форматом данных может быть формат данных, который поддерживает полную криптограмму данных в соответствии со стандартами EMV (доступно на http://www.emvco.com, содержание которых полностью включено посредством ссылки для всех целей). В некоторых вариантах осуществления, если сервер 106 продавца указывает, что он поддерживает первый формат данных, сервер 106 продавца способен принимать криптограмму запроса авторизации (ARQC) EMV, возвращаемую в элементе 55 данных ("DE 55") связанных с системой данных карточки с микросхемой (ICC) EMV и генерируемую с использованием полного набора вводов для генерирования ARQC в соответствии со стандартами EMV. Если сервер 106 продавца способен принимать сообщение в первом формате данных, криптограмма может быть проверена с использованием главной системы авторизации стандарта EMV.
Если сервер 106 продавца не поддерживает сообщения в первом формате данных, он будет поддерживать сообщения в альтернативном формате данных. Например, в некоторых вариантах осуществления другой формат данных (например, "альтернативный формат данных", "второй формат данных" или "третий формат данных") может быть использован для транзакций, где некоторая информация счетчика должна быть перенесена как часть транзакции авторизации. В этом случае ARQC генерируется с использованием частичного набора доступных вводов. То есть, некоторые поля устанавливаются на значения по умолчанию вместо значений, специфических для транзакции. ARQC и ассоциированные данные EMV сжимаются (например, статические значения на основе значений по умолчанию удаляются и может быть использовано кодирование битового отображения) и упаковываются в стандартное поле сообщения, такое как поле "UCAF". Чтобы проверить криптограмму, значение в UCAF (или другом стандартном поле сообщения) должно быть преобразовано обратно в первый формат данных (например, формат DE 55) посредством добавления значения по умолчанию и статического значения. Это может быть выполнено в качестве этапа предварительной обработки запрашивающей стороной, осуществляющей авторизацию транзакции, или основанием в объекте обработки. Затем преобразованное значение может быть проверено стандартной хост-системой авторизации (например, такой как запрашивающая сторона или основание в объекте).
В некоторых вариантах осуществления, если сервер 106 продавца не поддерживает сообщения в первом формате данных, он может поддерживать сообщения в другом формате данных (например, "альтернативном формате данных", "втором формате данных" или "третьем формате данных"). Например, альтернативный формат данных может быть использован в транзакциях, которые требуют или извлекают пользу из включения дополнительной информации о согласии пользователя и аутентификации пользователя в систему авторизации.
Таким образом, варианты осуществления позволяют выполнять транзакции между мобильным устройством 102 и различными серверами 106 продавцов, включающими в себя серверы 106 продавцов, которые не способны или не сконфигурированы с возможностью приема сообщений формата полного EMV. В результате серверы 106 продавцов, которые способны или сконфигурированы только с возможностью обработки транзакций обычного платежа, могут пользоваться преимуществом повышенной защиты от мошенничества EMV в транзакциях удаленного платежа.
В зависимости от характера ответа от сервера 106 продавца (в отношении того, поддерживает ли он первый формат данных или альтернативный формат данных), мобильное устройство 102 генерирует данные удаленного платежа для передачи на сервер 106 продавца для обработки транзакции. Подробности генерирования данных удаленного платежа будут обеспечены ниже по тексту в сочетании с Фиг. 3. В общем, формат данных удаленного платежа будет зависеть от того, поддерживает ли сервер 106 продавца первый формат данных или альтернативный формат данных. Сервер 106 продавца упаковывает данные удаленного платежа в ответе авторизации для передачи на приобретающую сторону 110 (которые могут быть переданы через шлюз 108 платежа). Затем запрос авторизации, ответ и очистка будут обрабатываться между сервером 106 продавца (и/или шлюзом 108 платежа, если таковой привлечен), сервером 104 платежей и запрашивающей стороной платежного инструмента, используемого в транзакции. В некоторых вариантах осуществления обработка между этими объектами может быть различной в зависимости от того, поддерживал ли сервер 106 продавца первый формат данных или альтернативный формат данных.
Например, если сервер 106 продавца поддерживал первый формат данных, данные удаленного платежа, принятые от мобильного устройства 102, содержатся в стандартной ARQC EMV в элементе 55 данных сообщения удаленного платежа, и система будет обрабатывать транзакцию с использованием стандартной обработки EMV для проверки ARQC. Однако, если сервер 106 продавца не поддерживал (или не был сконфигурирован с возможностью поддержки) первый формат данных, сообщение удаленного платежа принимается в альтернативном формате данных, и ARQC генерируется из частичного набора доступных вводов, а ARQC и ассоциированные данные EMV сжимаются (например, статические значения на основе значений по умолчанию удаляются и может быть использовано кодирование битового отображения) и принимаются сервером 106 продавца в стандартном поле сообщения транзакции платежа, таком как поле "UCAF". В таких вариантах осуществления система восстанавливает или реконструирует поле DE 55 из принятых данных. Эта восстановление выполняется перед выполнением своей регулярной обработки отображения. Восстановление может состоять из процесса, такого как: (1) добавление длины тега к данным, принятым из поля UCAF, (2) добавление данных по умолчанию к реконструированному полю DE 55, и (3) извлечение номера платежного счета ("PAN") из сообщения транзакции платежа (например, посредством выборки его из стандартного поля сообщения транзакции, такого как DE2) и добавление его к реконструированному полю DE 55 в поле "5A" (поле "номера основного счета (PAN) приложения" EMV), а также в поле "5F34" (поле "порядкового номера от номера основного счета (PAN) приложения" EMV). Таким образом, серверы 106 продавца, которые не обрабатывают (или не сконфигурированы с возможностью обработки) стандартные сообщения EMV, могут быть адаптированы с возможностью обработки таких сообщений.
Компьютер 110, оперируемый приобретающей стороной (приобретающим финансовым учреждением), также показан как часть системы 100 на Фиг. 1. Компьютер 110 приобретающей стороны может оперировать традиционным образом, чтобы принять запрос авторизации для транзакции от сервера 106 продавца. Компьютер 110 приобретающей стороны может осуществлять маршрутизацию запроса авторизации через сеть платежей (не показана) на компьютер-сервер или другую систему, оперируемую посредством или от имени запрашивающей стороны счета платежной карты, который является доступным для доступа мобильным устройством 102, и который был выбран для использования в настоящей транзакции платежа. Также традиционным образом ответ авторизации, сгенерированный запрашивающей стороной платежной карты, может быть с помощью маршрутизации направлен обратно на сервер 106 продавца через сеть платежей и компьютер 110 приобретающей стороны.
Сеть платежей может быть полностью или по существу традиционной; одним из примеров подходящей сети платежей является хорошо известная система Banknet, оперируемая посредством MasterCard International Incorporated, которая является ее правопреемником.
Системы или компьютеры, оперируемые посредством или от имени запрашивающей стороны платежной карты, используемой в транзакции, могут быть традиционными и могут оперироваться посредством или от имени финансового учреждения ("FI"; отдельно не показано), которое выдает счета платежных карт индивидуальным пользователям. Например, системы или компьютеры, оперируемые посредством или от имени запрашивающей стороны платежной карты, могут выполнять традиционные функции, такие как (a) прием и ответ на запросы об авторизации транзакций счетов платежных карт, которые должны быть оплачены по счетам платежных карт, выданным FI; и (b) отслеживание и хранение транзакций и ведение записей счетов.
Компоненты системы 100, изображенные на Фиг. 1, представляют собой только те компоненты, которые необходимы для обработки одной транзакции. Типичный практический вариант осуществления системы 100 может обрабатывать много транзакций покупок (в том числе одновременные транзакции) и может включать в себя значительное количество запрашивающих сторон платежных карт и их компьютеров, значительное количество приобретающих сторон и их компьютеров, а также многочисленных продавцов и их серверы продавцов и ассоциированные компоненты. Система также может включать в себя очень большое количество держателей счетов платежных карт, которые имеют мобильные устройства 102 с поддержкой платежа и/или платежные карты (в том числе бесконтактные платежные карты и/или карты с магнитной полосой).
Следует также понимать, что мобильное устройство 102 работает как традиционный мобильный телефон для связи - как голосовой, так и данных - по традиционной мобильной телекоммуникационной сети, которая не изображена на чертеже. Таким образом, мобильное устройство 102 может время от времени сообщаться традиционным образом с оператором мобильной сети ("MNO" - также не показан). Канал беспроводной связи (не показан на Фиг. 1) между мобильным устройством 102 и компьютером-сервером запрашивающей стороны платежной карты (или связанным компьютером, также не показанным на Фиг. 1) может время от времени быть установлен для целей, таких как персонализация, настройка и так далее в отношении мобильного устройства 102.
Фиг. 2 представляет собой блок-схему, которая иллюстрирует примерный вариант осуществления мобильного устройства 102 с поддержкой платежа, показанного на Фиг. 1 и обеспеченного в соответствии с аспектами настоящего изобретения. Мобильное устройство 102 может быть традиционным в своих аппаратных аспектах. Например, мобильное устройство 102 может походить в большинстве своих аппаратных аспектов и многих своих функциях на традиционный "iPhone", продаваемый корпорацией Apple, или на один из многочисленных моделей смартфонов, которые работают под управлением операционной системы "Android".
Мобильное устройство 102 может включать в себя традиционный корпус (указанный пунктирной линией 202 на Фиг.2), который содержит и/или поддерживает другие компоненты мобильного устройства 102. Корпус 202 может иметь форму и размер, чтобы удерживаться в руке пользователя, и может, например, демонстрировать тип форм-фактора, который является общим для нынешнего поколения мобильных устройств.
Мобильное устройство 102 дополнительно включает в себя традиционную схему 204 управления для управления всей работой мобильного устройства 102. Например, схема 204 управления может включать в себя традиционный процессор типа, разработанного для "мозгового центра" мобильного устройства.
Другие компоненты мобильного устройства 102, которые находятся в связи с и/или контролируются схемой 204 управления, включают в себя: (a) одно или несколько устройств 206 памяти (например, программную и рабочую память и так далее); (b) традиционную SIM-карту 208 (модуль идентификации абонента); (c) традиционный воспринимающий касание экран 212, который служит в качестве основного устройства ввода/вывода для мобильного устройства 102 и который, таким образом, принимает входную информацию от пользователя и отображает выходную информацию пользователю. Как и в случае со многими моделями мобильного устройства, в некоторых вариантах осуществления мобильное устройство 102 также может включать в себя несколько физически активируемых переключателей/элементов управления (не показаны), таких как переключатель включения/выключения/сброса, кнопка меню, кнопка "назад", переключатель регулировки громкости и так далее. Также может быть случай, когда смартфон включает в себя традиционную цифровую камеру, которая не показана.
Мобильное устройство 102 также включает в себя традиционную схему 216 приема/передачи, которая также поддерживает связь с и/или управляется схемой 204 управления. Схема 216 приема/передачи присоединена к антенне 218 и обеспечивает канал(ы) связи, посредством которого мобильное устройство 102 осуществляет связь через сеть мобильной телефонной связи (не показана). Схема 216 приема/передачи может работать как для приема, так и для передачи голосовых сигналов в дополнение к выполнению функций обмена данными.
Мобильное устройство 102 дополнительно включает в себя традиционный микрофон 220, присоединенный к схеме 216 приема/передачи. Разумеется, микрофон 220 предназначен для приема голосового ввода от пользователя. В дополнение, громкоговоритель 222 включен для обеспечения звукового вывода пользователю и присоединен к схеме 216 приема/передачи.
Схема 216 приема/передачи может работать в традиционной форме для передачи через антенну 218 голосовых сигналов, генерируемых микрофоном 220, и для воспроизведения через громкоговоритель 222 голосовых сигналов, принимаемых через антенну 218. Схема 216 приема/передачи также может обрабатывать передачу и прием текстовых сообщений и другой обмен данными через антенну 218.
Мобильное устройство 102 также может включать в себя схему 224, которая частично или целиком предназначена для реализации функциональных возможностей схемы связи NFC мобильного устройства 102. Мобильное устройство 102 дополнительно может включать в себя рамочную антенну 226, присоединенную к схеме 224 NFC. В некоторых вариантах осуществления схема 224 NFC может частично перекрываться с схемой 204 управления для мобильного устройства 102. Более того, схема платежа ассоциируется с и также может перекрываться с защищенным элементом 228, который является частью мобильного устройства 102 и содержится в корпусе 202, или схема NFC может быть пропущена в вариантах осуществления, которые не используют NFC. Термин "защищенный элемент" хорошо известен специалистам в данной области техники и обычно относится к устройству, которое может включать в себя небольшой процессор и энергозависимую и энергонезависимую память (отдельно не показаны), которые защищены от злонамеренного вмешательства и/или перепрограммирования посредством подходящих мер.
Дополнительные подробности, относящиеся к защищенному элементу 228 и, в частности, относящиеся к его программированию, будут описаны ниже по тексту со ссылкой на Фиг. 3 и 4. В некоторых вариантах осуществления защищенный элемент 228 может быть обеспечен как часть SIM-карты 208. В других вариантах осуществления защищенный элемент 228 может быть образован карточкой с микросхемой, отдельной от SIM-карты 208, но возможно имеющей тот же форм-фактор, что и SIM-карта 208. В некоторых вариантах осуществления мобильного устройства 102 защищенный элемент 228 может быть традиционным в его аппаратных аспектах, но может быть запрограммирован в соответствии с аспектами настоящего изобретения методикой, которая будет описана ниже по тексту. В некоторых вариантах осуществления термин "защищенный элемент" не должен ограничиваться устройствами, которые основаны на IC, но скорее также может включать в себя какую-либо защищенную среду исполнения в мобильном устройстве и может включать в себя программное обеспечение на основе защищенной среды исполнения, работающее на основном процессоре мобильного устройства.
Фиг. 3 представляет собой информационную схему последовательности операций, показывающую функциональные программные блоки, обеспеченные в мобильном устройстве 102 в соответствии с аспектами настоящего изобретения. Блок 302 с пунктирной линией на Фиг. 3 схематически представляет корпус 202 смартфона 102 в том смысле, что программные и аппаратные компоненты, представленные в блоке 302, являются признаками мобильного устройства 102. Блок 304 представляет собой защищенный элемент 228, упомянутый выше по тексту на Фиг. 2, и обозначается соответствующим образом.
В соответствии с аспектами настоящего изобретения защищенный элемент 228 хранит в себе множество мобильных платежных кардлетов 306 (приложений платежной карты). Хотя на Фиг. 3 явно показан только один мобильный платежный кардлет 306, число фактически присутствующее в защищенном элементе 228/смартфоне 102, может быть больше этого. Как обычно, каждый из мобильных платежных кардлетов 306 может представлять собой соответственный счет платежной карты, принадлежащий пользователю, и может хранить или иметь доступ к соответствующему номеру счета платежной карты для счета платежной карты, который он представляет. Во многих случаях мобильные платежные кардлеты 306 могут работать традиционным образом при доведении до конца транзакций платежей, однако, как описано в этом документе далее, способ, которым данные платежа обеспечиваются на сервер 316 продавца для использования при завершении транзакции, различается в зависимости от того, какой формат данных поддерживает сервер 316 продавца.
Как показано на Фиг. 3, защищенный элемент 304 также может хранить один или несколько апплетов 308 клиента, которые упрощают взаимодействие с и выборку данных из каждого платежного кардлета 304. Мобильное устройство 302 также хранит один или несколько апплетов 310 продавца и платежных апплетов 312. Например, каждый апплет 310 продавца может обеспечивать функциональные возможности, позволяющие взаимодействовать с сервером 316 продавца. Апплет 310 продавца может быть сконфигурирован с возможностью взаимодействия со специфическим продавцом (имеющим один или несколько серверов 316 продавца) или он может быть сконфигурирован с возможностью взаимодействия с несколькими продавцами. Например, апплет 310 продавца может быть частью или ассоциированным с приложением продавца, работающим на мобильном устройстве 102. Платежный апплет 312 может упрощать связь с сервером-бумажником (таким как, сервер 314 платежей). Например, платежный апплет 312 может быть приложением, позволяющим взаимодействовать с сервером-бумажником MasterPass, оперируемым посредством или от имени MasterCard International Incorporated, правопреемника настоящей заявки. Каждый из апплетов 306, 308, 310, 312 взаимодействует во время транзакции платежа настоящего изобретения для обеспечения данных удаленного платежа в формате, поддерживаемом сервером 316 продавца, что позволяет безопасно проводить транзакции методикой, поддерживаемой сервером 316 продавца. Снабжение данных удаленного платежа теперь будет описано со ссылкой на Фиг. 4. Следует принимать во внимание, что платежные кардлеты 306 и апплеты 308, 310 и 312 являются программными приложениями или апплетами и таким образом могут упоминаться как объекты программного обеспечения. В некоторых вариантах осуществления кардлеты и апплеты могут быть созданы в соответствии со спецификациями JavaCard (например, такими как спецификации, доступные на http://www.globalplatform.org, содержание которых полностью включено посредством ссылки для всех целей).
В соответствии с некоторыми вариантами осуществления кардлеты могут быть персонализированы таким образом, что дополнительные данные могут быть возвращены в ответ на транзакцию продавца. Например, PAN приложения и порядковый номер PAN приложения могут быть персонализированы так, что они могут быть возвращены в ответном сообщении на команду.
Фиг.4 представляет собой блок-схему последовательности операций, которая иллюстрирует процесс, который может быть выполнен в мобильном устройстве 102 согласно аспектам настоящего изобретения. Процесс с Фиг. 4 начинается инициирующим событием, указанным блоком 402 на Фиг. 4. Например, инициирующее событие может произойти, если пользователь мобильного устройства 102 взаимодействует с мобильным устройством 102, чтобы инициировать транзакцию платежа. Например, пользователь может инициировать транзакцию платежа посредством взаимодействия с приложением продавца на мобильном устройстве 102 для выбора одного или нескольких товаров или услуг для покупки и запроса инициирования транзакции. В качестве другого примера, пользователь может инициировать транзакцию платежа посредством взаимодействия с веб-броузером на мобильном устройстве 102 для выбора одного или нескольких товаров или услуг для покупки и запроса инициирования транзакции. Транзакции также могут быть инициированы и в ряде других способов.
После инициирования транзакции обработка продолжается на этапе 404, когда мобильное устройство 102 (например, под управлением апплета 310 продавца, платежного апплета 312 и/или апплета 308 клиента) передает сообщение с запросом об инициирование транзакции платежа на сервер 106 продавца, ассоциированный с продавцом, с которым должна быть проведена транзакция. Сообщение с запросом об инициирование транзакции платежа может быть передано по сетевому соединению между мобильным устройством 102 и сервером 106 продавца.
Обработка продолжается на этапе 406, где мобильное устройство 102 принимает информацию, идентифицирующую формат данных, поддерживаемый сервером 106 продавца. Например, сервер 106 продавца может указывать мобильному устройству 102, поддерживает ли он первый формат данных или альтернативной формат для транзакции. В некоторых вариантах осуществления серверы 106 продавцов могут поддерживать транзакции в стиле полного EMV (например, как используется в этом документе, "первый формат данных", в котором мобильное устройство должно передавать криптограмму на сервер 106 продавца в формате полного EMV). В некоторых вариантах осуществления серверы 106 продавцов могут не поддерживать транзакции в стиле полного EMV (например, как используется в этом документе, "альтернативный формат данных", в котором мобильное устройство должно обеспечивать информацию, позволяющую объекту сгенерировать криптограмму с использованием частичного набора вводов, и сообщение не обеспечивается в формате полного EMV). В некоторых вариантах осуществления альтернативный формат данных также может быть использован для обеспечения результатов верификации держателя карты. Например, как показано в таблице 2 ниже по тексту, альтернативный "Формат 1" может обеспечивать данные результата верификации держателя карты в объекте данных, обозначенном "Результаты верификации карты", вычисленные с использованием счетчика PIN или сценария.
Когда мобильное устройство 102 принимает информацию, указывающую, какой формат данных поддерживается сервером 106 продавца, обработка продолжается на этапе 408, где мобильное устройство 102 работает для обеспечения данных удаленного платежа серверу 106 продавца в поддерживаемом формате данных.
Если сервер 106 продавца поддерживает первый формат данных, программное обеспечение мобильного устройства 102 будет работать для обеспечения данных удаленного платежа на сервер 106 продавца с использованием криптограммы (такой как криптограмма запроса аутентификации ("ARQC") EMV) в формате данных полного EMV в элементе 55 данных (как точно определено в спецификациях EMV). Затем криптограмма может быть использована сервером 106 продавца (и/или шлюзом 108 платежа, приобретающей стороной 110 или системами запрашивающей стороны) для проверки с использованием главной системы авторизации стандарта EMV.
Если сервер 106 продавца не поддерживает первый формат данных (а вместо этого поддерживает альтернативный формат данных), криптограмма будет сгенерирована с использованием частичного набора данных ввода из выбранного платежного кардлета 306. В одном специфическом иллюстративном примере в приведенной ниже по тексту таблице проиллюстрированы данные, которые платежный кардлет 306 обеспечивает в качестве ввода криптограмме удаленного платежа в зависимости от того, поддерживает ли сервер продавца первый формат данных или альтернативный формат данных.
| Элемент данных | Первый формат данных | Альтернативный формат данных |
| Сумма, авторизовано | Взять значение из команды ввода | По умолчанию 0 |
| Сумма, другое | ||
| Валютный код транзакции | ||
| Дата транзакции | ||
| Код страны терминала | Взять значение, персонализированное в кардлете | |
| Тип транзакции | ||
| Результаты верификации терминала | По умолчанию 0 |
Таблица 1
| Элемент данных | Альтернативный формат 0 | Альтернативный формат 1 | Альтернативный формат 2 |
| Сумма, авторизовано | По умолчанию 0 | По умолчанию 0 | По умолчанию 0 |
| Сумма, другое | По умолчанию 0 | По умолчанию 0 | По умолчанию 0 |
| Код страны терминала | По умолчанию 0 | По умолчанию 0 | По умолчанию 0 |
| Результаты верификации терминала | По умолчанию 0 | По умолчанию 0 | По умолчанию 0 |
| Валютный код транзакции | По умолчанию 0 | По умолчанию 0 | По умолчанию 0 |
| Дата транзакции | По умолчанию 0 | По умолчанию 0 | По умолчанию 0 |
| Тип транзакции | По умолчанию 0 | По умолчанию 0 | По умолчанию 0 |
| Непредсказуемый номер | Как обеспечено в вводе | Как обеспечено в вводе | Как обеспечено в вводе |
| Протокол обмена приложений | AIP | AIP | AIP |
| Счетчик транзакций приложения | Текущее значение | Текущее значение | Текущее значение |
| Результаты верификации карты | Маска | Как вычислено | Как вычислено |
Таблица 2
Как показано в таблице 1, когда сервер 106 продавца поддерживает второй формат данных, некоторые данные, используемые для генерирования криптограммы удаленного платежа, по умолчанию равны нулю, в то время как данные, используемые для генерирования криптограммы удаленного платежа для первого формата данных, берут значение из данных ввода (например, из кардлета или платежного апплета) или используют значение, персонализированное в защищенном элементе.
Как показано в таблице 2 и таблице 4 (ниже по тексту), может быть обеспечено некоторое количество различных альтернативных форматов данных. Например, "Альтернативный формат 0" может быть использован для транзакций с привлечением мобильных устройств с защищенным элементом или для транзакций MCBP. "Альтернативный формат 1" может быть использован для транзакций с привлечением мобильных устройств с защищенным элементом, где информация счетчика должна переноситься как часть транзакции авторизации. "Альтернативный формат 2" может быть использован для транзакций с привлечением транзакций MCBP, которые также извлекают пользу из или требуют информацию о согласии пользователя или аутентификации пользователя (упоминаемую как данные "CDCVM") запрашивающей стороне или сети платежей.
В некоторых вариантах осуществления, когда сервер 106 продавца поддерживает данные в первом формате данных, данные удаленного платежа возвращаются на сервер 106 продавца в ответе "формата 2" ISO, а объект данных, возвращенный в ответном сообщении, представляет собой сконструированный объект данных с тегом, равным "ABC". Поле значений содержит несколько кодированных по базовым правилам кодирования объектов данных значения, длины, тега ("BER-TLV"). Например, содержимое части "ABC" ввода в транзакцию для транзакции первого элемента данных показано ниже по тексту в таблице 2.
| Тег | Объект данных |
| '9F09' | Номер версии приложения (считыватель) |
| '9F33' | Возможности терминала |
| '9F53' | Код категории транзакции |
| '6F' | Имя DF |
| '5A' | PAN приложения |
| '5F34' | Порядковый номер приложения |
| '57' | Эквивалентные данные следа 2 |
| '5F24' | Дата истечения срока приложения |
| '9C' | Тип терминала |
| '9F1A' | Код страны терминала |
| '9C' | Тип транзакции |
| '9A' | Дата транзакции |
| '95' | Результаты верификации терминала |
| '9F27' | Информационные данные криптограммы (CID) |
| '9F34' | Результаты CVM |
| '82' | Профиль обмена приложений (AIP) |
| '9F36' | Счетчик транзакций приложения (ATC) |
| '9F26' | Криптограмма приложения |
| '9F10' | Данные приложения запрашивающей стороны |
| '9F37' | Непредсказуемый номер |
| '9F02' | Сумма, авторизовано (в числах) |
| '9F03' | Сумма, другое (в числах) |
| '5F2A' | Валютный код транзакции |
Таблица 3
В некоторых вариантах осуществления, когда сервер 106 продавца поддерживает данные в альтернативном формате данных, данные удаленного платежа возвращаются на сервер 106 продавца в эквиваленте ответа "формата 1" ISO, а объект данных, возвращенный в ответном сообщении, представляет собой простейший объект данных с тегом, равным "DEF". Поле значений состоит из конкатенации без разделителей (тега и длины) полей значений объектов данных, как показано ниже по тексту в таблице 3. В соответствии с некоторыми вариантами осуществления поле криптограммы приложения таблицы 3 может быть использовано для хранения одной или двух криптограмм. Например, в некоторых вариантах осуществления может поддерживаться реализация, ассоциированная с защищенным элементом, которая требует одну криптограмму, а также реализации, которые используют одну или две криптограммы (например, реализации без защищенных элементов, такие как система платежей на основе облачных вычислений).
| Значение | |||
| Объект данных | Альтернативный формат 0 | Альтернативный формат 1 | Альтернативный формат 2 |
| Последовательность # PAN UCAF/Версия | Как вычислено | Как вычислено | Как вычислено |
| Криптограмма приложения | ARQC, которая вычислена | ARQC, которая вычислена | ARQC, которая вычислена |
| Счетчик транзакций приложения | Текущее значение | Текущее значение | Текущее значение |
| Непредсказуемый номер | Как обеспечено в вводе | Как обеспечено в вводе | Как обеспечено в вводе |
| Протокол обмена приложений | Как персонализировано | Как персонализировано | Как персонализировано |
| Индекс формирования ключа (KDI) | Как персонализировано | Как персонализировано | Как персонализировано |
| Номер версии криптограммы (CVN) | Как вычислено | Как вычислено | Как вычислено |
| Счетчик попыток PIN/счетчик сценария | --- | Текущие значения, вычисленные для транзакции | --- |
| Превышенные ограничения | --- | Текущие значения, вычисленные для транзакции | --- |
| Данные CDCVM | --- | --- | Как вычислено |
Таблица 4
В соответствии с некоторыми вариантами осуществления в случае, когда сервер 106 продавца поддерживает альтернативный формат данных, ARQC генерируется с использованием частичного набора доступных вводов (как показано в таблице 1 выше по тексту). ARQC и ассоциированные данные EMV сжимаются и упаковываются в поле стандартного сообщения-запроса авторизации платежа ISO (например, в поле UCAF). Данные обеспечиваются серверу 106 продавца для обработки. В некоторых вариантах осуществления сервер 106 продавца генерирует запрос авторизации для передачи сети платежей следующим образом. Запрос авторизации выдается с "режимом ввода точки обслуживания" (DE 22 SF1), установленным на "81" (указывающим режим ввода "электронной коммерции, включающей в себя микросхему"). Указатели электронной коммерции устанавливаются так: (1) подполе 1 (указатель уровня безопасности электронной коммерции и указатель сбора UCAF) устанавливается на значение "212" со следующими значениями (i) позиция 1 (протокол безопасности) устанавливается на "2" ("канал"), (ii) позиция 2 (аутентификация держателя карты) устанавливается на "1" (сертификат держателя карты не используется), (iii) позиция 3 (указатель сбора UCAF) устанавливается на "2" (сбор данных UCAF поддерживается продавцом, и должны присутствовать данные UCAF), (2) криптограмма содержится в поле DE 48 SE 43 (также известном как поле UCAF).
Продолжая описание обработки транзакции альтернативного формата данных, как только данные удаленного платежа генерируются кардлетами и апплетами мобильного устройства 102, данные передаются апплету 310 продавца для передачи на сервер 106 продавца. Сервер 106 продавца (возможно, через шлюз платежа продавца) упаковывает данные удаленного платежа в запросе авторизации для передачи приобретающей стороне 110. Запрос авторизации, ответ и очистка будут обрабатываться между сервером 106 продавца (или шлюзом 108), сервером 104 платежей и запрашивающей стороной. Эти транзакции отображаются сервером платежей. Для транзакции альтернативного формата данных сервер платежей (или другой объект) восстанавливает сообщение альтернативного формата данных в сообщение первого формата данных. Восстановление может состоять из добавления длины тега к данным, принятым в поле UCAF, добавления данных по умолчанию (из таблицы 1) для воссоздания сообщения первого формата данных, и извлечения PAN из сообщения и добавления его к первому формату данных (как элемент "5А" и элемент "5F34" в таблице 2). Таким образом, продавец, который поддерживает только альтернативный формат данных, может пользоваться преимуществами транзакций, проводимых с использованием первого формата данных.
Аспекты изобретения были описаны выше по тексту в контексте мобильного устройства, такого как мобильный телефон. Однако принципы настоящего изобретения в равной степени применимы к другим типам устройств, включающих в себя планшетные компьютеры или другие вычислительные устройства.
В контексте настоящего описания и прилагаемой формулы изобретения термин "компьютер" следует понимать как охватывающий один компьютер или два или более компьютеров, сообщающихся друг с другом.
В контексте настоящего описания и прилагаемой формулы изобретения термин "процессор" следует понимать как охватывающий один процессор или два или более процессоров, сообщающихся друг с другом.
В контексте настоящего описания и прилагаемой формулы изобретения термин "память" следует понимать как охватывающий одну память или устройство хранения или две или более памяти или устройств хранения.
Блок-схемы последовательности операций и их описания в этом документе не следует понимать как то, что они предписывают фиксированный порядок выполнения этапов способа, описанных в них. Скорее этапы способа могут быть выполнены в любом порядке, который практически осуществим.
В контексте настоящего описания и прилагаемой формулы изобретения термин "счет платежной карты" или "платежное устройство" включает в себя счет кредитной карты или депозитный счет, к которому владелец счета может получать доступ с использованием дебетовой карты. Термин "номер счета платежной карты" включает в себя номер, который идентифицирует счет системы платежной карты или номер, переносимый платежной картой, или номер, который используется для маршрутизации транзакции в платежной системе, которая обрабатывает транзакции дебетовой карты и/или кредитной карты. Термин "платежная карта" включает в себя кредитную карту или дебетовую карту или другое платежное устройство.
В контексте настоящего описания и прилагаемой формулы изобретения термин "система платежной карты" относится к системе для обработки транзакций покупки и связанных транзакций. Примером такой системы является система, оперируемая MasterCard International Incorporated, правопреемником настоящего раскрытия. В некоторых вариантах осуществления термин "система платежной карты" может быть ограничен системами, в которых членские финансовые учреждения выдают счета платежных карт отдельным лицам, предприятиям и/или другим организациям.
Хотя настоящее изобретение было описано в связи с конкретными примерными вариантами осуществления, следует понимать, что различные изменения, замены и модификации, очевидные для специалистов в данной области техники, могут быть сделаны в раскрытых вариантах осуществления без отклонения от сущности и объема изобретения как изложено в прилагаемой формуле изобретения.
1. Способ функционирования мобильного устройства для передачи данных транзакции платежа, содержащий этапы, на которых:
принимают посредством мобильного устройства запрос пользователя на инициирование транзакции с продавцом;
передают посредством мобильного устройства сообщение инициирования транзакции платежа на сервер продавца, ассоциированный с упомянутым продавцом;
принимают посредством мобильного устройства сообщение-запрос от упомянутого сервера продавца для данных удаленного платежа, причем упомянутое сообщение-запрос идентифицирует выбранный формат данных, поддерживаемый сервером продавца, причем выбранный формат данных идентифицирует по меньшей мере один из первого формата данных и альтернативного формата данных;
генерируют посредством мобильного устройства данные удаленного платежа на основе выбранного формата данных; и
передают посредством мобильного устройства упомянутые данные удаленного платежа упомянутому серверу продавца в упомянутом выбранном формате данных для инициирования обработки авторизации упомянутой транзакции.
2. Способ по п. 1, в котором первый формат данных представляет собой формат данных, который позволяет получить завершенную криптограмму запроса авторизации ("ARQC").
3. Способ по п. 2, в котором альтернативный формат данных представляет собой формат данных, который позволяет получить посредством упомянутого сервера продавца модифицированную криптограмму запроса авторизации ("ARQC") с упомянутого устройства.
4. Способ по п. 3, в котором модифицированная ARQC генерируется с использованием частичного набора вводов данных.
5. Способ по п. 4, в котором частичный набор вводов данных включает в себя по меньшей мере первое поле данных, которое устанавливается на значение по умолчанию вместо значения, конкретного для упомянутой транзакции.
6. Способ по п. 1, в котором выбранный формат данных является альтернативным форматом данных, причем способ дополнительно содержит этап, на котором:
преобразуют упомянутые данные удаленного платежа и упомянутый альтернативный формат данных в сообщение-запрос авторизации с использованием упомянутого первого формата данных.
7. Способ по п. 6, в котором преобразование выполняется объектом после того, как упомянутое устройство обеспечивает упомянутые данные удаленного платежа упомянутому серверу продавца в упомянутом выбранном формате данных.
8. Способ по п. 1, в котором устройство представляет собой мобильное устройство, имеющее по меньшей мере первый платежный кардлет, хранящийся в защищенном элементе.
9. Способ по п. 8, в котором по меньшей мере первый платежный кардлет персонализирован таким образом, что по меньшей мере следующие элементы данных могут быть возвращены в ответ на команду: (i) PAN приложения и (ii) порядковый номер PAN приложения.
10. Мобильное устройство для передачи данных транзакции платежа, содержащее:
устройство связи для связи с сервером продавца, ассоциированным с продавцом;
блок хранения компьютера для приема, хранения и обеспечения данных, ассоциированных с транзакцией;
процессор, сообщающийся с устройством связи и блоком хранения компьютера, при этом процессор сконфигурирован с возможностью:
приема запроса пользователя на инициирование транзакции с продавцом;
передачи сообщения инициирования транзакции платежа на упомянутый сервер продавца, ассоциированный с упомянутым продавцом;
приема сообщения-запроса от упомянутого сервера продавца для данных удаленного платежа, причем упомянутое сообщение-запрос идентифицирует выбранный формат данных, поддерживаемый сервером продавца, причем выбранный формат данных идентифицирует по меньшей мере один из первого формата данных и альтернативного формата данных;
генерации данных удаленного платежа на основе выбранного формата данных; и
передачи упомянутых данных удаленного платежа упомянутому серверу продавца в упомянутом выбранном формате данных для инициирования обработки авторизации упомянутой транзакции.
11. Устройство по п. 10, в котором первый формат данных представляет собой формат данных, который позволяет получить завершенную криптограмму запроса авторизации ("ARQC").
12. Устройство по п. 11, в котором альтернативный формат данных представляет собой формат данных, который позволяет получить посредством упомянутого сервера продавца модифицированную криптограмму запроса авторизации ("ARQC") с упомянутого устройства.
13. Устройство по п. 12, в котором модифицированная ARQC генерируется с использованием частичного набора вводов данных.
14. Устройство по п. 13, в котором частичный набор вводов данных включает в себя по меньшей мере первое поле данных, которое устанавливается на значение по умолчанию вместо значения, конкретного для упомянутой транзакции.
15. Устройство по п. 10, в котором выбранный формат данных является альтернативным форматом данных, при этом процессор дополнительно сконфигурирован с возможностью:
преобразования упомянутых данных удаленного платежа и упомянутого альтернативного формата данных в сообщение-запрос авторизации с использованием упомянутого первого формата данных.
16. Устройство по п. 15, в котором преобразование выполняется объектом после того, как упомянутое устройство обеспечивает упомянутые данные удаленного платежа упомянутому серверу продавца в упомянутом выбранном формате данных.
17. Устройство по п. 10, в котором устройство представляет собой мобильное устройство, имеющее по меньшей мере первый платежный кардлет, хранящийся в защищенном элементе.
18. Устройство по п. 17, в котором по меньшей мере первый платежный кардлет персонализирован таким образом, что по меньшей мере следующие элементы данных могут быть возвращены в ответ на команду: (i) PAN приложения и (ii) порядковый номер PAN приложения.
