Способы и системы облачных транзакций

Изобретение относится к области вычислительной техники. Технический результат заключается в улучшении защиты устройства связи при проведении транзакции. Способ содержит этапы, на которых: принимают от удаленного компьютера ключ ограниченного использования (LUK); генерируют посредством устройства связи криптограмму транзакции с использованием LUK; отправляют на устройство доступа обозначение вместо реального идентификатора счета и криптограммы транзакции для проведения транзакции; отправляют на удаленный компьютер запрос пополнения для нового LUK; и принимают от удаленного компьютера новый LUK, когда информация журнала транзакций в запросе пополнения совпадает с информацией журнала транзакций на удаленном компьютере. 2 н. и 21 з.п. ф-лы, 16 ил., 2 табл.

 

ПЕРЕКРЕСТНЫЕ ССЫЛКИ НА РОДСТВЕННЫЕ ЗАЯВКИ

[0001] По данной заявке испрашивается приоритет предварительной патентной заявки США № 61/918,643, поданной 19 декабря 2013 г., предварительной патентной заявки США № 61/941,227, поданной 18 февраля 2014 г., предварительной патентной заявки США № 61/982,169, поданной 21 апреля 2014 г., и предварительной патентной заявки США № 61/983,635, поданной 24 апреля 2014 г., которые все включены сюда посредством ссылки в полном объеме для всех целей.

УРОВЕНЬ ТЕХНИКИ

[0002] Развитие возможностей портативных устройств связи позволяет использовать портативные устройства связи, например, смартфоны, в качестве платежных инструментов для проведения бесконтактных транзакций. Например, портативное устройство связи можно размещать вблизи устройства доступа, например, терминала торговой точкам (POS) для переноса информации счета от портативного устройства связи на устройство доступа для проведения транзакции. Для обеспечения защищенной операционной среды для безопасного хранения информации счета на портативном устройстве связи, используется защитный элемент, например, карта модуля идентификации абонента (SIM), специализированная интегральная микросхема, внедренная в портативное устройство связи, или специализированный компонент, обеспеченный как решение вторичного рынка. Во время транзакции, защитный элемент осуществляет связь напрямую с бесконтактным интерфейсом (например, приемопередатчиком ближней бесконтактной связи (NFC)) портативного устройства связи для передачи платежных данных на бесконтактное устройство чтения устройства доступа. Защитный элемент считается защищенным, поскольку информация счета сохраняется в оборудовании, защищенном от постороннего вмешательства, которое защищает информацию счета от вредоносных программ или вирусов, которые могут заражать операционную систему или приложение, выполняющееся на портативном устройстве связи.

[0003] Однако защитный элемент, используемый в портативном устройстве связи, обычно не находится под управлением финансового учреждения, но находится под управлением оператора мобильной сети (MNO). В результате, эмитент и/или платежный оператор может не иметь прямого доступа к защитному элементу для обеспечения его реквизитами счета и платежными функциями. Для получения доступа к защитному элементу, эмитенту и/или платежному оператору может понадобиться устанавливать коммерческие соглашения и техническую возможность осуществления связи со стороной, управляющей защитным элементом, для осуществления беспроводной (OTA) персонализации защитного элемента. Это трудоемкий и сложный процесс. Кроме того, включение защитного элемента увеличивает стоимость производства портативного устройства связи и повышает стоимость законченного портативного устройства связи.

[0004] Таким образом, в ряде случаев, желательно использовать портативное устройство связи, которое не имеет защитного элемента для совершения платежей. Если же портативное устройство связи имеет защитный элемент, желательно не опираться на использование защитного элемента. Однако, поскольку защитный элемент не используется, защита транзакции составляет проблему.

[0005] Варианты осуществления настоящего изобретения решают эти и другие проблемы по отдельности и совместно. В частности, варианты осуществления изобретения решают проблему защиты при проведении платежных транзакций с помощью мобильного устройства связи, которое не имеет защитного элемента или не опирается на него.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0006] Варианты осуществления настоящего изобретения предусматривают способы улучшения защиты устройства связи (например, портативного устройства связи) при проведении транзакции с использованием устройства связи. Описанные здесь способы можно использовать с устройством связи, которое может иметь защитный элемент или не иметь его, поскольку способы не требуют использования защитного элемента для защиты реквизитов счета. Варианты осуществления изобретения вместо этого используют параметры счета ограниченного использования, которые могут иметь ограниченный срок действия, и, по его истечении, больше не могут использоваться для проведения транзакции, пока параметры счета ограниченного использования не будут пополнены из облака (например, удаленного компьютера). Поэтому транзакции, проведенные с использованием описанных здесь способов, могут именоваться “облачными транзакциями”.

[0007] Согласно некоторым вариантам осуществления, способ улучшения защиты устройства связи при проведении транзакции с использованием устройства связи может включать в себя прием, от удаленного компьютера, ключа ограниченного использования (LUK), который связан с набором из одного или более порогов ограниченного использования, который ограничивает использование LUK. Способ также может включать в себя генерацию, посредством устройства связи, криптограммы транзакции с использованием LUK, и отправку, посредством устройства связи на устройство доступа, обозначение вместо реального идентификатора счета и криптограммы транзакции для проведения транзакции. Транзакция может авторизоваться на основании, по меньшей мере, того, превысило ли использование LUK набор из одного или более порогов ограниченного использования.

[0008] Согласно некоторым вариантам осуществления, устройство связи может включать в себя процессор; и память, подключенную к процессору, где хранится мобильное приложение, которое осуществляет операции для улучшения защиты устройства связи при проведении транзакций с использованием устройства связи. Операции могут включать в себя прием ключа ограниченного использования (LUK), который связан с набором из одного или более порогов ограниченного использования, который ограничивает использование LUK, генерацию криптограммы транзакции с использованием LUK, и отправку обозначения вместо реального идентификатора счета и криптограммы транзакции для проведения транзакции. Транзакция может авторизоваться на основании, по меньшей мере, того, превысило ли использование LUK набор из одного или более порогов ограниченного использования.

[0009] Согласно некоторым вариантам осуществления, способ улучшения защиты устройства связи при проведении транзакции с использованием устройства связи может включать в себя шифрование, компьютером, информации счета первым ключом шифрования для генерации второго ключа шифрования, и шифрование информации индекса ключа с использованием второго ключа для генерации ключа ограниченного использования (LUK), где информация индекса ключа включает в себя индекс ключа, имеющий информацию, относящуюся к генерации LUK. Способ также может включать в себя обеспечение LUK и индекса ключа устройству связи для облегчения генерации криптограммы транзакции для транзакции, проведенной с использованием устройства связи. Транзакция может авторизоваться на основании LUK и криптограммы транзакции.

[0010] Согласно некоторым вариантам осуществления, компьютер для улучшения защиты устройства связи при проведении транзакции с использованием устройства связи может включать в себя процессор, и память, где хранится компьютерно-считываемый код, который, при выполнении процессором, предписывает компьютеру шифровать информацию счета первым ключом шифрования для генерации второго ключа шифрования, шифровать информацию индекса ключа с использованием второго ключа для генерации ключа ограниченного использования (LUK), и обеспечивать LUK и индекс ключа устройству связи для облегчения генерации криптограммы транзакции для транзакции, проведенной с использованием устройства связи. Информация индекса ключа может включать в себя индекс ключа, имеющий информацию, относящуюся к генерации LUK. Транзакция может авторизоваться на основании LUK и криптограммы транзакции.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0011] Фиг. 1 демонстрирует блок-схему примера системы облачной транзакции, согласно некоторым вариантам осуществления.

[0012] Фиг. 2 демонстрирует схему обмена информацией в иллюстративном процессе регистрации и предоставления, согласно некоторым вариантам осуществления.

[0013] Фиг. 3 демонстрирует схему обмена информацией примера выполнения транзакции на основе интегральной микросхемы, согласно некоторым вариантам осуществления.

[0014] Фиг. 4 демонстрирует схему обмена информацией примера выполнения транзакции на основе магнитной полоски, согласно некоторым вариантам осуществления.

[0015] Фиг. 5 демонстрирует пример журнала проверки транзакции, согласно некоторым вариантам осуществления.

[0016] Фиг. 6 демонстрирует схему обмена информацией в иллюстративном процессе постплатежной проверки, согласно некоторым вариантам осуществления.

[0017] Фиг. 7 демонстрирует схему обмена информацией в иллюстративном процессе пополнения параметров счета, согласно некоторым вариантам осуществления.

[0018] Фиг. 8 демонстрирует пример процесса для генерации криптограммы транзакции, согласно некоторым вариантам осуществления.

[0019] Фиг. 9 демонстрирует пример функции шифрования, согласно некоторым вариантам осуществления.

[0020] Фиг. 10 демонстрирует блок-схему операций иллюстративного способа улучшения защиты портативного устройства связи, согласно некоторым вариантам осуществления.

[0021] Фиг. 11 демонстрирует блок-схему операций другого иллюстративного способа улучшения защиты портативного устройства связи, согласно некоторым вариантам осуществления.

[0022] Фиг. 12 демонстрирует блок-схему иллюстративного портативного устройства связи, согласно некоторым вариантам осуществления.

[0023] Фиг. 13 демонстрирует диаграмму состояний иллюстративного мобильного приложения в ручном режиме, согласно некоторым вариантам осуществления.

[0024] Фиг. 14 демонстрирует диаграмму состояний иллюстративного мобильного приложения в режиме постоянной активности, согласно некоторым вариантам осуществления.

[0025] Фиг. 15 демонстрирует диаграмму состояний иллюстративного мобильного приложения в режиме постоянной активности с проверкой на устройстве, согласно некоторым вариантам осуществления.

[0026] Фиг. 16 демонстрирует блок-схему иллюстративной компьютерной системы, согласно некоторым вариантам осуществления.

ПОДРОБНОЕ ОПИСАНИЕ

[0027] Варианты осуществления настоящего изобретения предусматривают способы, устройства и системы для облачных транзакций которые могут осуществляться устройствами связи с защитным элементом или без него. Описанные здесь способы могут использовать технологию эмуляции карты (например, host card emulation (HCE), и т.д.) для эмуляции смарткарты на устройстве связи (например, портативном устройстве связи), чтобы мобильное приложение, выполняющееся на портативном устройстве связи, могло проводить бесконтактные транзакции. В среде эмуляции карты, мобильное приложение может осуществлять доступ к бесконтактному интерфейсу (например, приемопередатчику ближней бесконтактной связи (NFC)) портативного устройства связи через операционную систему (OS) портативного устройства связи без участия защитного элемента. По сравнению с реализациями защитного элемента, подход эмуляции карты снижает технические и коммерческие сложности для эмитентов и/или платежных операторов, поскольку эмитенты и/или платежные операторы могут обеспечивать реквизиты счета и платежные функции мобильному приложению на портативном устройстве связи без необходимости в получении доступа к защитному элементу через оператора мобильной сети.

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

[0029] Для улучшения защиты портативного устройства связи при проведении транзакций без использования защитного элемента, вместо использования неизменных реквизитов счета, хранящихся на портативном устройстве связи, которые могут быть действительными в течение срока действия счета, описанные здесь облачные способы обеспечивают портативное устройство связи параметрами счета ограниченного использования, которые имеют ограниченное использование или срок действия. Когда ограниченное использование или срок действия параметров счета ограниченного использования истощается, тот же набор параметров счета ограниченного использования больше не может использоваться для проведения дальнейших транзакций. Для проведения дальнейших транзакций с использованием портативного устройства связи, новые параметры счета ограниченного использования пополняются в портативное устройство связи. Параметры счета ограниченного использования, обеспеченные портативному устройству связи, могут неоднократно обновляться или пополняться из сети (также именуемой “облаком”) в течение срока действия счета. Благодаря управлению доставкой и жизненным циклом параметров счета ограниченного использования между набором сетевых возможностей и портативным устройством связи, компрометация мобильного приложения и/или реквизитов счета, хранящихся на портативном устройстве связи, становится лишь ограниченным риском нарушения безопасности, поскольку похищенные параметры счета ограниченного использования можно в основном использовать лишь для небольшого числа транзакций или ограниченной денежной суммы.

[0030] Прежде чем перейти к подробному рассмотрению некоторых вариантов осуществления настоящего изобретения, опишем некоторые термины, что может быть полезно для понимания различных вариантов осуществления.

[0031] “Устройством связи” может быть устройство, которое включает в себя один или более электронных компонентов (например, интегральную микросхему), которые могут осуществлять связь с другим устройством. “Портативным устройством связи” может быть устройство связи, которое пользователь может переносить и эксплуатировать. Портативное устройство связи может обеспечивать сети возможности удаленной связи. Портативное устройство связи может быть выполнено с возможностью передачи и приема данных или передач на и от других устройств. Портативное устройство связи может принимать форму мобильного устройства, например, мобильного телефона (например, смартфона, сотового телефона и т.д.), планшетов, портативного медиапроигрывателя, устройств карманного персонального компьютера (PDA), носимого вычислительного устройства (например, часов), электронного устройства чтения и т.д., или в форме карты (например, смарт-карты) или брелока, и т.д. Примеры портативных устройств связи также могут включать в себя портативные вычислительные устройства (например, портативные компьютеры, нетбуки, ультрабуки и т.д.).

[0032] “Компьютер-сервер” может включать в себя мощный компьютер или кластер компьютеров. Например, компьютер-сервер может представлять собой большой компьютер, кластер миникомпьютеров или группу серверов, функционирующих как единое целое. В одном примере, компьютер-сервер может представлять собой сервер базы данных, подключенный к веб-серверу. Компьютер-сервер может быть подключен к базе данных и может включать в себя любое оборудование, программное обеспечение, другую логику, или комбинацию предшествующих для обслуживания запросов от одного или более компьютеров-клиентов. Компьютер-сервер может содержать одно или более вычислительных устройств и может использовать любую из различных вычислительных структур, конфигураций и объединений для обслуживания запросов от одного или более компьютеров-клиентов.

[0033] “Эмитентом” обычно называется коммерческая организация (например, банк), которая поддерживает счет для пользователя, который связан с портативным устройством связи, например, счет, зарегистрированный в мобильном приложении, установленном на портативном устройстве связи. Эмитент также может выдавать параметры счета, связанные со счетом, на портативное устройство связи. Эмитент может быть связан с базовой системой, которая осуществляет некоторые или все из функций эмитента от имени эмитента.

[0034] “Торговцем” обычно называется субъект, который участвует в транзакциях и может продавать товары или услуги, или обеспечивать доступ к товарам или услугам.

[0035] "Приобретателем" обычно называется коммерческая организация (например, коммерческий банк), имеющая деловые отношения с конкретным торговцем или другим субъектом. Некоторые субъекты могут одновременно осуществлять функции эмитента и приобретателя. Некоторые варианты осуществления могут охватывать таких объединенных эмитентов-приобретателей.

[0036] “Устройством доступа” может быть любое пригодное устройство для осуществления связи с компьютером торговца или сетью обработки платежей и для взаимодействия с платежным устройством, компьютерным устройством пользователя и/или мобильным устройством пользователя. Устройство доступа, в общем случае, может располагаться в любом пригодном месте, например, в месте расположения торговца. Устройство доступа может принимать любую пригодную форму. Некоторые примеры устройств доступа включают в себя устройства POS, сотовые телефоны, PDA, персональные компьютеры (PC), планшетные PC, ручные специализированные устройства чтения, телевизионные приставки, электронные кассовые аппараты (ECR), торговые автоматы (ATM), виртуальные кассовые аппараты (VCR), киоски, защитные системы, системы доступа, веб-сайты и пр. Устройство доступа может использовать любой пригодный контактный или бесконтактный режим работы для отправки или приема данных от портативного устройства связи или связанного с ним. В некоторых вариантах осуществления, где устройство доступа может содержать терминал POS, любой пригодный терминал POS может использоваться и может включать в себя устройство чтения, процессор и компьютерно-считываемый носитель. Устройство чтения может включать в себя любой пригодный контактный или бесконтактный режим работы. Например, иллюстративные устройства чтения карт могут включать в себя радиочастотные (RF) антенны, оптические сканеры, устройства чтения штрих-кодов или устройства чтения магнитных полосок для взаимодействия с портативным устройством связи.

[0037] “Сообщением запроса авторизации” называется электронное сообщение, отправляемое для запрашивания авторизации для транзакции. Сообщение запроса авторизации можно отправлять в сеть обработки платежей и/или эмитенту платежной карты. Согласно некоторым вариантам осуществления, сообщение запроса авторизации может отвечать ISO 8583, который является стандартом для систем, которые обмениваются информацией об электронной транзакции, связанной с платежом, производимым пользователем с использованием платежного устройства или платежного счета. Сообщение запроса авторизации может включать в себя информацию, которую можно использовать для идентификации счета. Сообщение запроса авторизации также может содержать дополнительные элементы данных, например, один или более из кода услуги, даты истечения срока действия, и т.д. Сообщение запроса авторизации также может содержать информацию о транзакции, например, любую информацию, связанную с текущей транзакцией, например, сумму транзакции, идентификатор торговца, местоположение торговца, и т.д., а также любую другую информацию, которую можно использовать при определении, идентифицировать ли и/или авторизовать ли транзакцию. Сообщение запроса авторизации также может включать в себя другую информацию, например, информацию, которая идентифицирует устройство доступа, сгенерировавшее сообщение запроса авторизации, информацию о местоположении устройства доступа, и т.д.

[0038] “Сообщением ответа авторизации” называется электронное сообщение, передаваемое в ответ на сообщение запроса авторизации. Сообщение ответа авторизации может генерироваться эмитирующим финансовым учреждением или сетью обработки платежей. Сообщение ответа авторизации может включать в себя, исключительно в порядке примера, один или более из следующих указателей статуса: одобрить -- транзакция одобрена; отклонить -- транзакция не одобрена; или центр обработки вызовов -- ответ, ожидающий дополнительной информации, торговец должен позвонить по бесплатному телефонному номеру авторизации. Сообщение ответа авторизации также может включать в себя код авторизации, который может представлять собой код, который банк, выпустивший кредитную карту, возвращает в ответ на сообщение запроса авторизации в электронном сообщении (либо напрямую, либо через сеть обработки платежей) на компьютер торговца, который указывает одобрение транзакции. Код может служить подтверждением авторизации. Как упомянуто выше, в некоторых вариантах осуществления, сеть обработки платежей может генерировать или пересылать сообщение ответа авторизации торговцу.

[0039] Термин "аутентификация" и его производные может означать процесс, позволяющий проверять сертификат конечной точки (в том числе, но без ограничения, приложений, людей, устройств, процессов и систем), чтобы гарантировать, что конечная точка является тем, чем она себя объявляет.

[0040] Термин "проверка" и его производные может означать процесс, который использует информацию для определения, действителен ли базовый предмет в данном наборе обстоятельств. Проверка может включать в себя любое сравнение информации, чтобы гарантировать правильность, действительность, точность, допустимость и/или нормальное состояние некоторых данных или информации.

[0041] "Обозначение" может включать в себя идентификатор-заместитель для некоторой информации. Например, обозначение платежа может включать в себя идентификатор для платежного счета, который является заместителем для идентификатора счета, например, первичный номер счета (PAN). Например, обозначение может включать в себя последовательность буквенно-числовых символов, которые можно использовать как заместитель для первоначального идентификатора счета. Например, обозначение "4900 0000 0000 0001" можно использовать вместо PAN "4147 0900 0000 1234". В некоторых вариантах осуществления, обозначение может быть "сохраняющим формат" и может иметь числовой формат, который согласуется с идентификаторами счетов, используемыми в существующих сетях обработки платежей (например, формат сообщения о финансовой транзакции ISO 8583). В некоторых вариантах осуществления, обозначение можно использовать вместо PAN для инициирования, авторизации, урегулирования или разрешения платежной транзакции. Обозначение также можно использовать для представления первоначального сертификата в других системах, где обычно обеспечивается первоначальный сертификат. В некоторых вариантах осуществления, значение обозначения можно генерировать таким образом, что для восстановления первоначального PAN или другого идентификатора счета из значения обозначения не требуется вычислений. Дополнительно, в некоторых вариантах осуществления, формат обозначения может быть сконфигурирован таким образом, чтобы субъект мог принимать обозначение для идентификации его как обозначение и распознавать субъект, выпустивший обозначение.

[0042] "Реальный идентификатор счета" может включать в себя первоначальный идентификатор счета, связанный с платежным счетом. Например, реальным идентификатором счета может быть первичный номер счета (PAN), выданный эмитентом для карточного счета (например, кредитная карта, дебетовая карта, и т.д.). Например, в некоторых вариантах осуществления, реальный идентификатор счета может включать в себя шестнадцатицифровое численное значение, например, "4147 0900 0000 1234". Первые шесть цифр реального идентификатора счета (например, "414709"), могут представлять реальный идентификатор эмитента (BIN), который может идентифицировать эмитента, связанного с реальным идентификатором счета.

[0043] Под “параметрами счета” можно понимать информацию, относящуюся к счету, которую можно использовать для проведения транзакции по счету. Примеры параметров счета могут включать в себя информацию, которую можно использовать для идентификации счета пользователя (например, реальный идентификатор счета, альтернативный идентификатор счета, обозначение и т.д.), данные или информация, относящаяся к статусу счета, один или более ключей, которые используются для генерации криптографической информации, данные или информацию, относящуюся к одному или более ключам, и т.д. Параметр счета может быть полустатическим или динамическим. Динамический параметр счета может быть параметром счета, который имеет ограниченный срок действия, и который, по его истечении, больше нельзя использовать для проведения транзакции, пока параметр счета не будет пополнен или обновлен. Динамический параметр счета может часто пополняться в течение срока действия счета. Полустатический параметр счета может быть параметром счета, который имеет продленный срок действия, который дольше, чем динамический параметр счета, и может пополняться менее часто, чем динамический параметр счета или вовсе не пополняться в течение срока действия счета.

[0044] “Ключ” может означать фрагмент информации, который используется в криптографическом алгоритме для преобразования входных данных в другое представление. Криптографический алгоритм может быть алгоритмом шифрования, который преобразует первоначальные данные в альтернативное представление, или алгоритм дешифрования, который преобразует зашифрованную информацию обратно в первоначальные данные. Примеры криптографических алгоритмов могут включать в себя стандарт тройного шифрования данных (TDES), стандарт шифрования данных (DES), стандарт усовершенствованного шифрования (AES) и т.д.

[0045] “Криптограмма” может означать зашифрованное представление некоторой информации. Получатель может использовать криптограмму для определения, пользуется ли генератор криптограммы правильным ключом, например, путем шифрования базовой информации с действительным ключом и сравнения результата с принятой криптограммой.

[0046] “Порог ограниченного использования” может означать условие, которое ограничивает использование фрагмента информации. Порог ограниченного использования может быть превышен или истощен при выполнении базового условия. Например, порог ограниченного использования может включать в себя время существования, которое указывает продолжительность времени, в течение которого фрагмент информации действителен, и по истечении этой продолжительности времени, порог ограниченного использования превышается или истощается, и фрагмент информации может становиться недействительным и больше не может использоваться. В порядке другого примера, порог ограниченного использования может включать в себя, сколько раз можно использовать фрагмент информации, и после того, как фрагмент информации использовался это число раз, порог ограниченного использования превышается или истощается, и фрагмент информации может становиться недействительным и больше не может использоваться.

[0047] Ниже будут описаны детали некоторых вариантов осуществления настоящего изобретения.

[0048] I. Параметры счета

[0049] Система облачных транзакций согласно некоторым вариантам осуществления обеспечивает набор функций для управления развертыванием и использованием параметров счета для транзакций, проведенных с использованием портативного устройства связи. Параметры счета (также можно именоваться “реквизиты счета”) представляют собой информацию, относящуюся к счету (например, финансовый счет, банковский счет, платежный счет и т.д.), связанную с пользователем, которую можно использовать для проведения транзакций по счету пользователя. Параметры счета могут обеспечиваться или предоставляться портативному устройству связи, чтобы портативное устройство связи могло проводить транзакции по счету пользователя (например, путем размещения портативного устройства связи вблизи бесконтактного устройства чтения устройства доступа, например, терминала торговой точкам (POS)).

[0050] Параметры счета могут включать в себя полустатический набор данных и динамический набор данных, и некоторые или все из параметров счета могут быть параметрами счета ограниченного использования. Полустатический набор данных может включать в себя идентификатор, который можно использовать для идентификации счета, связанного с пользователем (например, идентификатор счета, например, первичный номер счета (PAN), альтернативный идентификатор счета, например, альтернативный PAN, или обозначение, которое является заместителем для идентификатора счета, и т.д.), дату истечения срока действия и/или другие детали счета или данные, которые не всегда изменяются в течение продленного периода времени, или, в некоторых вариантах осуществления, в течение срока действия счета. Динамический набор данных может включать в себя один или более ключей, информацию, связанную с одним или более ключами, и/или другие динамические данные, которые имеет ограниченный срок действия, и неоднократно обновляются или пополняются в течение срока действия счета. Динамический набор данных может использоваться для или относиться к генерации на устройстве динамических криптограмм транзакций, или представлять динамические данные транзакции в ходе платежных транзакций.

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

[0052] Набор из одного или более порогов ограниченного использования может включать в себя, по меньшей мере, одно из времени существования, указывающего промежуток времени, в течение которого LUK действителен, заранее определенного числа транзакций, для которого LUK действителен, и/или совокупной суммы транзакции, указывающей итоговую сумму транзакции, вычисленную по одной или более транзакций, для которых LUK действителен, или любую их комбинацию. Например, LUK может быть действительным в течение времени существования пяти дней, и транзакция, проведенная с использованием LUK по истечении пяти дней после генерации LUK, может быть отклонена. В порядке другого примера, LUK может быть действительным в течение заранее определенного количества пяти транзакций, и шестая транзакция (и любая последующая транзакция), проведенная с использованием LUK, может быть отклонена. В порядке дополнительного примера, LUK может быть действительным для совокупной суммы транзакции пятьсот долларов, и транзакция, проведенная с использованием LUK после того как LUK уже был использован для транзакций общей суммой более пятисот долларов, может быть отклонена.

[0053] Следует понимать, что вышеописанные значения ограниченного использования являются лишь примерами, и что можно использовать другие лимиты использования. Например, число ограничения использования транзакций можно задать равным числу в пределах от 2 до 10 транзакций или числу в пределах от 5 до 50 транзакций, и т.д., и совокупную сумму транзакции можно задать равной значению в пределах от $100 до $5,000 или значению в пределах от $10 до $1000, и т.д.

[0054] Следует также заметить, что в некоторых вариантах осуществления, число порога ограниченного использования транзакций можно задать равным одной транзакции, так что каждый LUK действителен только для одной транзакции. Однако, в некоторых вариантах осуществления, полоса сети, доступная портативному устройству связи, может быть ограничена, или портативное устройство связи не всегда может иметь возможность осуществления непрерывной связи по сети. Таким образом, число порога ограниченного использования транзакций можно задать равным более одной транзакции (например, пяти транзакциям) в некоторых вариантах осуществления, например, для снижения частоты и количества пополнений LUK в течение времени и, таким образом, снижения объема сетевого трафика, используемого портативным устройством связи в течение времени.

[0055] В некоторых вариантах осуществления, набор из одного или более порогов ограниченного использования также может включать в себя порог международного использования и порог внутреннего использования, указывающие отдельные пределы для международных транзакций и внутренних транзакций. Например, число транзакций, для которых LUK может быть действительным, может быть выше для внутренних транзакций, чем для международных транзакций, если международные транзакции считаются более рискованными. Набор из одного или более порогов ограниченного использования также может включать в себя порог транзакции низкого значения и порог транзакции высокого значения, указывающие отдельные пределы для транзакций низкого значения и транзакций высокого значения. Например, число транзакций, для которых LUK может быть действительным, может быть выше для транзакций низкого значения (например, LUK действителен для десяти транзакций менее $20), чем для транзакций высокого значения (например, LUK действителен для пяти транзакций свыше $20), таким образом, что транзакции низкого значения будут запускать пополнение LUK менее часто, чем транзакции высокого значения.

[0056] В некоторых вариантах осуществления, набор из одного или более порогов ограниченного использования, связанный со счетом, может изменяться при пополнении LUK, таким образом, что новый LUK, замещающий предыдущий LUK, может иметь другие один или более лимитов использования, чем предыдущий LUK. Это может происходить, например, на основании изменений в привычных тратах покупателя, местоположения портативного устройства связи или времени года и т.д. Например, новый LUK может иметь более высокий лимит использования, если пользователь в последнее время проводил большое количество транзакций высокого значения, или когда он находится в отпуске, когда предполагается увеличения транзакционной активности. В порядке другого примера, новый LUK может иметь более низкий лимит использования, если местоположение портативного устройства связи указывает, что пользователь мог переехать в страну высоких рисков, где распространено мошенничество.

[0057] Согласно вариантам осуществления, в которых LUK связан с более чем одним порогом ограниченного использования, использование LUK может истощаться в случае превышения любого из порогов ограниченного использования, или в случае превышения некоторой комбинации порогов ограниченного использования. Поэтому пополнение LUK может запускаться в случае превышения любого из порогов ограниченного использования или в случае близости превышения, или в случае превышения некоторой комбинации порогов ограниченного использования или в случае близости превышения.

[0058] В некоторых вариантах осуществления, порог ограниченного использования, связанный с LUK счета, может иметь разные лимиты использования, сконфигурированные в разных компонентах или субъектах системы облачной транзакции. Другими словами, разные компоненты или субъекты могут иметь разные лимиты использования для конкретного порога ограниченного использования для запуска пополнения LUK. Компоненты или субъекты, которые могут быть сконфигурированы с разными лимитами использования, могут включать в себя, например, портативное устройство связи пользователя, поставщика облачных услуг и/или эмитента/базовую систему. Согласно некоторым вариантам осуществления, лимит использования на портативном устройстве связи можно задавать более низким, чем лимит использования на стороне поставщика облачных услуг, и лимит использования на стороне поставщика облачных услуг можно задавать более низким, чем лимит использования на стороне эмитента. Например, LUK может иметь порог время существования ограниченного использования, и лимит использования на устройстве для запуска пополнения LUK на портативном устройстве связи можно задавать равным 2 дням, лимит использования поставщик услуг на стороне поставщика облачных услуг можно задавать равным 4 дням, и лимит использования эмитента на стороне эмитента можно задавать равным 5 дням. В этом примере, портативное устройство связи обычно будет инициировать пополнение LUK спустя 2 дня. Однако, если портативное устройство связи отключается или теряет возможность осуществления связи по сети, поставщик облачных услуг может инициировать пополнение LUK спустя 4 дня, или эмитент может инициировать пополнение спустя 5 дней, если LUK не был обновлен в течение этого периода, чтобы гарантировать, что LUK не остается просроченным.

[0059] В некоторых вариантах осуществления, разные компоненты или субъекты системы облачной транзакции могут быть сконфигурированы с разными порогами ограниченного использования, которые могут запускать пополнение LUK. Например, набор из одного или более порогов ограниченного использования на устройстве, сконфигурированный на портативном устройстве связи, может включать в себя время существования и число транзакций, которые будут запускать пополнение LUK, инициированное портативным устройством связи, тогда как поставщик облачных услуг и/или эмитент/базовая система, дополнительно или альтернативно, могут быть сконфигурированы с совокупной суммой транзакции для запуска пополнения LUK, инициированного поставщиком облачных услуг и/или эмитентом /базовой системой. Другими словами, разные компоненты или субъекты могут отслеживать различные типы условий или порогов ограниченного использования для запуска пополнения LUK.

[0060] В некоторых вариантах осуществления, набор из одного или более порогов ограниченного использования может зависеть от конкретного счета (например, где разные счета могут иметь разные лимиты использования), зависеть от конкретного портативного устройства связи (например, где разные портативные устройства связи пользователя могут иметь разные лимиты использования, даже если базовый счет один и тот же), и/или зависеть от конкретного мобильного приложения (например, где разные мобильные приложения могут иметь разные лимиты использования, даже если мобильные приложения установлены на одном и том же портативном устройстве связи и/или если базовый счет один и тот же). В некоторых вариантах осуществления, LUK также может иметь другие ограничения использования, например, тип торговца, конкретный торговец, или географическое положение, где можно использовать LUK. Конкретные правила или параметры рисков для запуска пополнения LUK и/или для установления порогов ограниченного использования может определяться эмитентом или поставщиком облачных транзакций.

[0061] Динамический набор данных также может включать в себя индекс ключа, который связан с LUK. Индекс ключа может включать в себя информацию, относящуюся к генерации LUK. Например, индекс ключа можно использовать в качестве начального значения для генерации соответствующего LUK. Индекс ключа может включать в себя информацию времени (например, метку времени) указывающую, когда сгенерирован LUK, и/или может включать в себя значение счетчика пополнения, указывающее, сколько раз LUK был обновлен или пополнен для конкретного счета, мобильного приложения или портативного устройства связи. В некоторых вариантах осуществления, значение счетчика пополнения может указывать, сколько раз был пополнен LUK в течение заранее определенного периода времени, и значение счетчика пополнения может сбрасываться по истечении каждого заранее определенного периода времени. Этот заранее определенный период времени может соответствовать, например, наименьшей единице времени, определимой из информации времени, хотя можно использовать другие заранее определенные периоды времени. В порядке примера, если информация времени, включенная в индекс ключа, указывает, до какого часа генерируется текущий LUK, значение счетчика может указывать, сколько раз был пополнен LUK в течение часа. В некоторых вариантах осуществления, LUK может включать в себя значение счетчика транзакций с помощью приложения, указывающее число транзакций, ранее проведенных мобильным приложением портативного устройства связи на момент генерации LUK, или может включать в себя псевдослучайное число, генерируемое поставщиком услуг облачной транзакции или подходящим субъектом, например, эмитентом, участвующим в обработке транзакции. Следует понимать, что индекс ключа может включать в себя один или более фрагментов информации, относящихся к генерации LUK, и что один или более или все фрагменты информации, включенные в индекс ключа, можно использовать в качестве начального значения для генерации LUK.

[0062] В некоторых вариантах осуществления, полустатический набор данных также может включать в себя параметры счета ограниченного использования, которые имеют свой собственный набор порогов ограниченного использования и/или собственный набор ограничений использования. Хотя в некоторых вариантах осуществления, идентификатор счета, например PAN может использоваться и храниться на портативном устройстве связи, PAN может быть действительным в течение срока действия счета и может использоваться для широкого диапазона разных типов транзакций (например, транзакций по предъявлении карты, онлайновых транзакций, и т.д.). Таким образом, для дополнительного улучшения защиты портативного устройства связи и для снижения влияния в случае компрометации параметров счета, в некоторых вариантах осуществления, вместо использования и сохранения PAN на портативном устройстве связи, можно использовать альтернативный идентификатор счета (например, альтернативный PAN) или обозначение, которое является заместителем для идентификатора счета.

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

[0064] Альтернативный идентификатор счета или обозначение также может иметь свой собственный набор порогов ограниченного использования (например, время существования, число транзакций, и/или совокупная сумма транзакции и т.д.). В некоторых вариантах осуществления, пороги ограниченного использования альтернативного идентификатора счета или обозначения могут иметь более высокие лимиты использования, чем лимиты динамического набора данных (например, LUK) таким образом, что пополнение альтернативного идентификатора счета или обозначения происходит менее часто. Например, альтернативный идентификатор счета или обозначение может иметь время существования год, тогда как время существования LUK может составлять пять дней. В порядке другого примера, альтернативный идентификатор счета или обозначение может быть действительным для до двух тысяч транзакции, тогда как LUK может быть действительным для до пятен транзакций. Следует понимать, что в некоторых вариантах осуществления, лимиты использования альтернативного идентификатора счета или обозначения также могут быть установлены такими же, как для динамического набора данных (например, LUK), таким образом, что пополнение альтернативного идентификатора счета или обозначения происходит одновременно с динамическим набором данных.

[0065] II. Обзор системы облачной транзакции

[0066] В системе облачной транзакции, эмитенты счетов могут конфигурировать характеристики портфеля услуг для задания параметров рисков и, таким образом, порогов ограниченного использования параметров счета для счетов, принадлежащих конкретному портфелю. Пороги ограниченного использования можно использовать для управления триггерами для обновления или пополнения параметров счета на предоставленном портативном устройстве связи. Чтобы гарантировать, что облачные транзакции обрабатываются согласно параметрам рисков, указанным в профиле обслуживания для счета, несколько базовых функций реализуются в системе для управления развертыванием и использованием параметров счета. Эти функции могут включать в себя предоставление, управление активным счетом, проверку платежа, обработку транзакции, управление жизненным циклом и постплатежную обработку.

[0067] Предоставление может приводить к взятию зарегистрированного счета, созданию параметров счета, например, идентификатора для идентификации зарегистрированного счета для облачных транзакций (например, альтернативного идентификатора счета, например, альтернативного PAN или обозначения) и начального динамического набора данных, чтобы гарантировать, что параметры счета имеют только ограниченное использование после доставки на портативное устройство связи, и наследованию профиля обслуживания (например, порогов ограниченного использования), который был установлен для портфеля, к которому принадлежит зарегистрированный счет. В зависимости от поддерживаемого типа транзакций, динамический набор данных может включать в себя LUK и/или другие динамические данные, например, индекс ключа. LUK, например, может использоваться портативным устройством связи в ходе транзакции для вычисления криптограммы транзакции или динамических данных ограниченного использования, например, значения проверки для поддержки традиционных транзакций, которые используют значения проверки (например, динамическое значение проверки карты (dCVV)).

[0068] После предоставления счета портативному устройству связи, соответствующие детали профиля обслуживания (например, пороги ограниченного использования) можно совместно использовать с программным обеспечением обработки транзакции и субъектами в системе, чтобы гарантировать надлежащую обработку решений авторизации транзакции. Дополнительно, детали профиля обслуживания (например, пороги ограниченного использования) могут обеспечиваться программному обеспечению облачной транзакции на устройстве мобильного приложения, установленного на портативном устройстве связи, чтобы гарантировать надлежащее управление параметрами счета на портативном устройстве связи. Как рассмотрено выше, разные лимиты использования для запуска пополнения параметров счета можно задавать на разных субъектах в системе облачной транзакции, и, таким образом, профиль обслуживания может задавать разные лимиты использования каждого порога ограниченного использования для задания на разных субъектах, которые могут инициировать пополнение параметров счета (например, портативном устройстве связи, поставщике облачных услуг, эмитенте и т.д.).

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

[0070] Для обеспечения проверки платежей, система облачной транзакции также имеет возможность обеспечения функций проверки на устройстве сети обработки платежей до или в ходе транзакции для обеспечения некоторого уровня проверки, что транзакция была инициирована и назначена надлежащим пользователем портативного устройства связи. Проверка на устройстве может включать в себя методы проверки держателя карты (CVM), которые можно использовать в качестве проверки платежа для предоставленных счетов. Как часть профиля обслуживания для портфеля, конкретные правила для которого можно использовать в качестве CVM (например, блокировка экрана, код-пропуск приложения, и т.д.) можно устанавливать и совместно используемый с возможностями предоставления, управления активным счетом и обработки транзакции.

[0071] После предоставления счета, возможность обработки транзакции системы может обеспечивать информацию о том, что проводимая транзакция осуществляется с использованием облачного счета. Когда облачный счет идентифицирован, возможность обработки транзакции системы облачной транзакции может гарантировать, что параметры профиля обслуживания (например, пороги ограниченного использования) проверяются, применяются и передаются эмитенту в сообщениях обработки транзакции. Эта возможность также гарантирует инициирование любых необходимых действий управления активным счетом. Например, информацию идентификации счета, обеспеченную в ходе транзакции, можно использовать для идентификации счета как облачного счета, если информация идентификации счета соответствует диапазону идентификатора счета (например, диапазону PAN), предназначенному для облачных транзакций, или если информация идентификации счета соответствует альтернативному PAN или обозначению, которое используется только для облачных транзакций.

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

[0073] Фиг. 1 демонстрирует систему 100 облачных транзакций, согласно некоторым вариантам осуществления. Базовые компоненты системы 100 могут включать в себя платформу 180 облачных платежей (CBPP) и платформу 170 мобильного приложения (MAP) для управления облачными транзакциями, проводимыми с использованием портативного устройства 101 связи. CBPP 180 может именоваться удаленным компьютером и может быть реализована с использованием одного или более вычислительных устройств или компьютеров, например, одного или более компьютеров-серверов, и может быть связана с поставщиком облачных услуг, например, эмитентом, платежным оператором и/или другими подходящими субъектами, или эксплуатироваться им. CBPP 180 может управлять облачными счетами, обеспечивать функции проверки для облачных транзакций, управлять сообщениями жизненного цикла от эмитента/базовой системы 172 или MAP 170, а также инициировать события управления жизненным циклом. CBPP 180 также может помогать эмитенту/базовой системе 172 с постплатежными функциями для снижения риска фальсификации параметров счета и ограничения раскрытия параметров счета, хранящихся на устройстве. Например, CBPP 180 можно использовать для помощи эмитенту/базовой системе 172 в запрашивании периодической постплатежной проверки платежных транзакций и/или подтверждения запросов пополнения параметров счета с использованием постплатежной информации.

[0074] CBPP 180 также может реализовывать набор функций управление ключами, который управляет главными ключами вывода (MDK) эмитента, из которых выводятся ключи ограниченного использования (LUK) для облачных транзакций. CBPP 180 может реализовывать набор функций предоставления, который управляет подготовкой и доставкой параметров облачного счета (например, альтернативного идентификатора счета или обозначения, начального LUK и соответствующего индекса ключа, и т.д.) на MAP 170 для начальной установки мобильного приложения 112 на портативном устройстве 101 связи. CBPP 180 также может управлять облачными счетами для обработки эмитентом/базовой системой 172 и может осуществлять функции управления активным счетом, например, функции для генерации параметров счета на основании запросов или профиля риска облачного счета согласно параметрам управления рисками CBPP 180. CBPP 180 также может поддерживать состояние счета для каждого облачного счета и управлять пополнением или обновлением параметров счета.

[0075] В некоторых вариантах осуществления, CBPP 180 также может реализовывать или обеспечиваться доступом к службе 182 обозначений и/или хранилищу 184 обозначений. Служба 182 обозначений может использоваться для генерации, обработки и поддержки обозначений, которые являются идентификаторами-заместителями для идентификаторов счетов. В ходе транзакции, вместо использования реального идентификатора счета (например, первичного номер счета (PAN)) для идентификации счета пользователя, альтернативно можно использовать обозначение для идентификации счета. За счет использования обозначения в качестве заместителя для идентификатора счета, можно снизить риск компрометации реальной информации счета. Как указано выше, обозначение может иметь свой собственный набор ограничений использования, и служба 182 обозначений может управлять развертыванием и использованием обозначений согласно их ограничениям использования. Служба 182 обозначений может осуществлять связь с хранилищем 184 обозначений, где хранятся сгенерированные обозначения. В частности, хранилище 184 обозначений может поддерживать отображение между обозначением и реальным идентификатором счета (например, PAN), представленным обозначением. В ходе обработки транзакции, к хранилищу 184 обозначений можно обращаться для извлечения реального идентификатора счета или PAN, связанного с обозначением.

[0076] MAP 170 используется для облегчения связи между мобильным приложением 112, выполняющимся на портативном устройстве 101 связи, и другими субъектами в системе 100 облачных транзакций, например, CBPP 180 и/или эмитентом/базовой системой 172, и т.д. MAP 170 может осуществлять связь с портативным устройством 101 связи через сеть 192 связи, например, интернет. В некоторых средах, портативное устройство 101 связи не всегда может иметь постоянную возможность осуществления связи по сети, и, таким образом, одной из основных ролей MAP 170 является ретрансляция запросов между мобильным приложением 112 и другими субъектами в системе 100 облачных транзакций, чтобы гарантировать, что запросы и ответы с участием мобильного приложения 112 удовлетворяются, как только устанавливается возможность осуществления связи по сети с портативным устройством 101 связи. MAP 170 может именоваться удаленным компьютером и может быть реализована с использованием одного или более вычислительных устройств или компьютеров, например, одного или более компьютеров-серверов, и может быть связана с поставщиком мобильного приложения 112 или эксплуатироваться им. Поставщиком мобильного приложения 112 может быть, например, эмитент, банк, сторонний поставщик мобильного кошелька, торговец или другие подходящие субъекты. В некоторых вариантах осуществления, MAP 170 может быть связана с тем же субъектом, что и CBPP 180, или другим субъектом или эксплуатироваться им. Хотя на фиг. 1 MAP 170 проиллюстрирована как отдельная логическая сущность, поскольку не предполагается, что CBPP 180 осуществляет связь напрямую с портативными устройствами связи, следует понимать, что в некоторых вариантах осуществления, некоторые или все из функций MAP 170 могут быть объединены как часть CBPP 180. Примеры MAP 170 могут включать в себя платформы мобильного банковского обслуживания и платформы мобильного кошелька.

[0077] В некоторых вариантах осуществления, MAP 170 может реализовывать функции аутентификации для аутентификации портативного устройства 101 связи, когда портативное устройство 101 связи осуществляет связь с другими субъектами в системе 100 облачных транзакций через MAP 170. Функции аутентификации могут гарантировать, что портативное устройство связи, осуществляющее связь с системой, является авторизованным портативным устройством связи и/или портативным устройством связи, которое не было взломано, заражено вредоносным программным кодом или вирусом или иначе скомпрометировано. Например, MAP 170 может осуществлять, запрашивать или облегчать характерный признак устройства портативного устройства 101 связи для захвата состояния портативного устройства 101 связи, когда портативное устройство 101 связи осуществляет связь с MAP 170. Характерным признаком устройства может быть, например, захват информации о портативном устройстве 101 связи, например, операционной системы и версии, приложений, установленных на портативном устройстве 101 связи, использования памяти, было ли портативное устройство 101 связи разлочено, идентификаторов устройств, например, идентификатора портативного устройства связи и/или других подходящих характеристик устройства.

[0078] MAP 170 может проверять характерный признак устройства портативного устройства 101 связи для каждого сеанса связи, установленного с портативным устройством 101 связи или периодически (например, через каждые пять сеансов связи, раз в месяц и т.д.). Если характерный признак устройства портативного устройства связи указывает, что портативное устройство связи не является авторизованным устройством для счета (например, портативное устройство связи, запрашивающее пополнение параметров счета, отличается от устройства, которое первоначально использовалось для регистрации счета), или если характерный признак устройства указывает, что портативное устройство связи потенциально может быть взломано, MAP 170 может препятствовать портативному устройству связи в осуществлении связи с системой и предупреждать эмитента о том, что портативное устройство связи может быть скомпрометировано.

[0079] MAP 170 может осуществлять функции регистрация для регистрации мобильного держателя карты в программе облачных транзакций и набор функций предоставления, который облегчает подготовку и доставку параметров счета, конфигурации и пороговых параметров устройства облачных платежей на мобильное приложение 112. MAP 170 может осуществлять функции пополнения параметров счета для облегчения процесса пополнения параметров счета для облачного счета, предоставленного на портативном устройстве 101 связи, и функции управления жизненным циклом, которые управляют сообщениями жизненного цикла от эмитента/базовой системы 172, CBPP 180 и/или мобильного приложения 112. MAP 170 также может осуществлять постплатежные функции для снижения риска фальсификации параметров счета и для ограничения раскрытия параметров счета, хранящихся на портативном устройстве 101 связи, например облегчения периодической постплатежной проверки платежных транзакций или использования постплатежной информации для подтверждения запросов пополнения параметров счета.

[0080] В системе 100 облачных транзакций, портативное устройство 101 связи можно использовать для проведения облачных транзакций с помощью CBPP 180 и/или MAP 170. Компоненты в портативном устройстве 101 связи могут включать в себя оборудование 104 устройства, мобильную операционную систему (OS) 114 и среду 110 приложений, в которой может располагаться мобильное приложение 112. Оборудование 104 устройства может включать в себя бесконтактный интерфейс 108, который может взаимодействовать с бесконтактным устройством 162 чтения устройства 160 доступа. Примеры бесконтактного интерфейса 108 могут включать в себя один или более радиочастотных (RF) приемопередатчиков, которые могут отправлять и принимать передачи с использованием ближней бесконтактной связи (NFC), или других протоколов радиочастотной или беспроводной связи, например, Bluetooth, Bluetooth low-energy (BLE), Wi-Fi, iBeacon, и т.д. В некоторых вариантах осуществления, бесконтактный интерфейс 108 может включать в себя оптический интерфейс (например, экран дисплея) для представления информации платежа в форме изображения, например, кода быстрого ответа (QR) или штрих-кода и т.д., бесконтактному устройству 162 чтения устройства 160 доступа, когда бесконтактное устройство 162 чтения включает в себя сканер или устройство чтения оптического кода.

[0081] Среда 110 приложений портативного устройства 101 связи может вмещать в себя мобильное приложение 112, обеспеченное поставщиком мобильного приложения. Например, если поставщиком мобильного приложения 112 является эмитент, мобильное приложение 112 может быть приложением мобильного банковского обслуживания или отдельным приложением мобильных платежей. Если поставщиком является поставщик мобильного кошелька, например, оператор мобильной сети или сторонний поставщик кошелька, который поддерживает множественных эмитентов, мобильное приложение 112 может быть приложением мобильного кошелька. Для торговцев, мобильным приложением 112 может быть собственное мобильное приложение торговца, из которого покупатели могут проводить транзакции электронной торговли или торговой точки с этим торговцем, или может быть приложением мобильного кошелька, которое поддерживает множественных торговцев.

[0082] Согласно некоторым вариантам осуществления, мобильное приложение 112 может включать в себя программное обеспечение 113 облачной транзакции на устройстве (например, может принимать форму пакета средств разработки (SDK)), встроенное в мобильное приложение 112 для поддержки функций облачной транзакции. Программное обеспечение 113 облачной транзакции на устройстве может осуществлять функции для облегчения облачных транзакций, например, брать параметры счета (например, LUK и соответствующий индекс ключа), генерировать криптограммы транзакций, и доставлять их в мобильную операционную систему 114 для передачи по бесконтактному интерфейсу 108. Программное обеспечение 113 облачной транзакции на устройстве также может управлять начальными параметрами профиля обслуживания (например, порогами ограниченного использования), которые обеспечиваются после предоставления счета, чтобы гарантировать инициирование запросов для пополнения параметров счета и других действий управления параметрами счета.

[0083] Мобильное приложение 112 может осуществлять функции для управления профилем риска облачного счета, поддержания состояния счета и пополнения параметров счета для каждого облачного счета на основании параметров управления порогами на устройстве. Мобильное приложение 112 также может управлять сообщениями жизненного цикла от эмитента/базовой системы 172 или сообщениями жизненного цикла от MAP 170. Мобильное приложение 112 может осуществлять набор функций для регистрации мобильного держателя карты в программе облачных транзакций и набор функций, который управляет приемом и конфигурированием параметров облачного счета и пороговых параметров устройства облачных платежей, принятых от MAP 170. Мобильное приложение 122 также может обеспечивать функции метода проверки держателя карты с покупательским устройством (CDCVM) для облачных транзакций, и осуществлять набор функций, который обрабатывает и отвечает на сообщения в поддержку постплатежной обработки для ограничения раскрытия параметров счета, хранящихся на портативном устройстве связи. Например, постплатежная обработка может включать в себя периодическую постплатежную проверку платежных транзакций или использование постплатежной информации для подтверждения запросов пополнения параметров счета.

[0084] В реализациях на основе защитных элементов, бесконтактное приложение (например, мобильный кошелек или платежное приложение для бесконтактных транзакций), использующее бесконтактный интерфейс для осуществления связи с бесконтактным устройством чтения устройства доступа требует кодирования и выполнения на защитном элементе для получения доступа к бесконтактному интерфейсу. В некоторых вариантах осуществления, портативное устройство 101 связи может включать в себя мобильную операционную систему (OS) 114, которая реализует набор интерфейсов прикладного программирования (API) 116 эмуляции карты, например, API host card emulation (HCE), чтобы мобильное приложение 112 могло получать доступ к бесконтактному интерфейсу 108 без необходимости в использовании защитного элемента. Например, API 116 эмуляции карты могут кодироваться для и выполняться из мобильной OS 114 портативного устройства 101 связи, и может включать в себя вызовы функции программирования, чтобы мобильное приложение 112 могло принимать, обрабатывать и отвечать на передачи транзакции, например, команды протокольного блока данных прикладного уровня (ADPU), отправленные из бесконтактного устройства 162 чтения. Таким образом, портативное устройство 101 связи способно проводить бесконтактные транзакции без необходимости доступа к защитному элементу на портативном устройстве 101 связи.

[0085] После того, как портативному устройству 101 связи и мобильному приложению 112 были предоставлены параметры счета, портативное устройство 101 связи может проводить облачные транзакции путем взаимодействия с бесконтактным устройством 162 чтения устройства 160 доступа (например, в местоположении торговой точки торговца (POS)). Бесконтактное устройство 162 чтения может включать в себя один или более RF приемопередатчиков, которые могут отправлять и принимать передачи с использованием NFC или других протоколов радиочастотной или беспроводной связи, например, Bluetooth, BLE, Wi-Fi, iBeacon, и т.д. В некоторых вариантах осуществления, бесконтактное устройство 162 чтения может включать в себя сканер или устройство чтения оптического кода для проведения транзакций с использованием QR-кодов, штрих-кодов, и т.д. Устройство 160 доступа также может включать в себя устройство 164 акцептования POS и/или электронный кассовый аппарат 166.

[0086] Для проведения облачной транзакции, пользователь портативного устройства 101 связи может размещать портативное устройство 101 связи вблизи бесконтактного устройства 162 чтения устройства 160 доступа, или отображать изображение, например, QR-код или штрих-код на экране портативного устройства 101 связи для сканирования бесконтактным устройством 162 чтения устройства 160 доступа. Портативное устройство 101 связи может обеспечивать устройство 160 доступа идентификатором (например, идентификатором счета, например PAN, альтернативным идентификатором счета, например, альтернативным PAN, или обозначением, и т.д.) для идентификации счета пользователя и дополнительной информации, например, параметров счета ограниченного использования, или информации, выведенной из параметров счета ограниченного использования (например, криптограмм транзакций, генерируемых из LUK). Например, в некоторых вариантах осуществления, идентификатор счета или обозначение, и дополнительная информация (например, криптограмма транзакции, параметры счета, и т.д.) могут передаваться на устройство 160 доступа в ответах APDU, которые отвечают на последовательность команд APDU, принятых от устройства 160 доступа. В некоторых вариантах осуществления, идентификатор счета или обозначение и дополнительная информация могут кодироваться в QR-коде или штрих-коде, который сканируется и обрабатывается устройством 160 доступа для извлечения кодированной информации. Затем устройство 160 доступа или компьютер торговца, подключенный к устройству 160 доступа, может генерировать сообщение запроса авторизации, включающее в себя идентификатор счета или обозначение, и дополнительную информацию, например, криптограмму транзакции и другие данные транзакции, и пересылать сообщение запроса авторизации приобретателю 174, связанному с торговцем. Затем сообщение запроса авторизации может отправляться приобретателем 174 в сеть 194 обработки платежей.

[0087] Сеть 194 обработки платежей может включать в себя подсистемы обработки данных, сети и операции, используемые для поддержки и доставки услуг авторизации, услуг исключения файлов, услуг оценивания транзакции, и услуг клиринга и урегулирования. Иллюстративная сеть обработки платежей может включать в себя VisaNet™. Сети обработки платежей, например VisaNet™, способны обрабатывать транзакции по кредитной карте, транзакции по дебетовой карте и другие типы коммерческих транзакций. VisaNet™, в частности, может включать в себя систему VIP (систему Visa Integrated Payments), которая обрабатывает запросы авторизации и систему Base II, которая осуществляет услуги клиринга и урегулирования.

[0088] Приняв сообщение запроса авторизации, сеть 194 обработки платежей может пересылать сообщение запроса авторизации, принятое от приобретателя 174, соответствующему эмитенту/базового системе 172 счета пользователя портативного устройства 101 связи. После того, как эмитент/базовая система 172 принимает сообщение запроса авторизации, сообщение запроса авторизации можно анализировать, и информацию в сообщении запроса авторизации можно проверять. Например, эмитент/базовая система 172 может проверять, что криптограмма транзакции была сгенерирована посредством действительного LUK, и что набор из одного или более порогов ограниченного использования, связанный с LUK, не был превышен. В некоторых вариантах осуществления, информация в сообщении запроса авторизации также может быть частично или полностью отправлена на CBPP 180 для проверки и обработки. Например, если эмитент/базовая система 172 не имеет возможности проверить криптограмму транзакции, сеть 194 обработки платежей или эмитент/базовая система 172 может пересылать криптограмму транзакции на CBPP 180 для проверки.

[0089] Затем сообщение ответа авторизации отправляется обратно в сеть 194 обработки платежей для указания, авторизована ли текущая транзакция (или не авторизована). Затем сеть 194 обработки платежей пересылает сообщение ответа авторизации обратно приобретателю 174. В некоторых вариантах осуществления, сеть 194 обработки платежей может отклонить транзакцию, даже если эмитент/базовая система 172 авторизовал/а транзакцию, например, в зависимости от значение оценки риска подделки или в зависимости от того, проверены ли параметры счета ограниченного использования на CBPP 180. Затем приобретатель 174 отправляет сообщение ответа авторизации на компьютер торговца и/или устройство 160 доступа. Результаты ответа авторизации, которые могут включать в себя данные транзакции для транзакции, могут отображаться устройством 160 доступа или распечатываться на физической квитанции.

[0090] В конце дня, процесс клиринга и урегулирования может проводиться сетью 194 обработки платежей. Процесс клиринга это процесс обмена финансовыми деталями между приобретателем и эмитентом для облегчения проводки на платежный счет пользователя и согласования позиции урегулирования пользователя. Следует понимать, что любой из приобретателя 174, сети 194 обработки платежей, эмитента/базовой системы 172, CBPP 180 и/или MAP 170 может именоваться удаленным компьютером и может включать в себя одно или более вычислительных устройств, например, один или более компьютеров или компьютеров-серверов, чтобы субъект мог осуществлять связь с другими субъектами в системе 100 и/или для осуществления одной или более из описанных здесь функций.

[0091] III. Регистрация и предоставление

[0092] Фиг. 2 демонстрирует схему обмена информацией иллюстративного процесса регистрации и предоставления, согласно некоторым вариантам осуществления. Процесс регистрации и предоставления может инициироваться с портативного устройства 201 связи, на котором установлено мобильное приложение, запрограммированное возможностями облачной транзакции. Мобильное приложение может быть заранее установлено на портативном устройстве 201 связи в ходе производства или розничным торговцем, или пользователем, загружающим мобильное приложение из магазина приложений или от эмитента или поставщика услуг облачной транзакции и устанавливающим мобильное приложение на портативном устройстве 201 связи. Пользователь может запускать мобильное приложение и инициировать запрос 222 регистрации из мобильного приложения для добавления счета к услуге облачной транзакции. Запрос 222 регистрации отправляется с портативного устройства 201 связи на MAP 270 и может включать в себя информацию, которую можно использовать для идентификации пользователя и счета пользователя, а также информацию устройства о портативном устройстве 201 связи.

[0093] Согласно некоторым вариантам осуществления, для облегчения связи с портативным устройством 201 связи, MAP 270 (или эмитент/базовая система 272, или CBPP 280) может генерировать идентификатор устройства из информации устройства или назначать идентификатор устройства портативному устройству 201 связи в процессе регистрации и предоставления. Идентификатор устройства обеспечивается мобильному приложению на портативном устройстве 201 связи, и может использоваться мобильным приложением для идентификации портативного устройства 201 связи другим субъектам в системе облачной транзакции при последующих взаимодействиях с системой.

[0094] Когда MAP 270 принимает запрос 222 регистрации, MAP 270 может обрабатывать запрос, захватывать информацию устройства о портативном устройстве 201 связи, и маршрутизировать запрос регистрации 224 с полезной информацией к эмитенту/базовой системе 272. Эмитент/базовая система 272 может осуществлять идентификацию и проверку (ID&V) пользователя и счета пользователя, и отправлять запрос 226 предоставления на CBPP 280. Запрос 226 предоставления может включать в себя информацию идентификации счета, например PAN, для идентификации счета пользователя. Согласно вариантам осуществления, в которых используется альтернативный идентификатор счета или обозначение, CBPP 280 или эмитент/базовая система 272 может генерировать альтернативный идентификатор счета, или вызывать службу обозначений для генерации обозначения, который используется в качестве заместителя для идентификатора счета. Приняв запрос 226 предоставления, CBPP 280 может использовать главный ключ вывода (MDK), связанный с эмитентом/базовой системой 272, для генерации начального набора параметров счета (например, LUK) для предоставления портативному устройству 201 связи. В некоторых вариантах осуществления, эмитент/базовая система 272 может обеспечивать MDK для CBPP 180, если MDK поддерживается или управляется эмитентом/базовой системой 272, или эмитент/базовая система может генерировать LUK и обеспечивать сгенерированный LUK для CBPP 180. В любом случае, генерируется ли LUK CBPP 180 или эмитентом/базовой системой 272, LUK может генерироваться на основании индекса ключа, который используется в качестве начального значения для генерации LUK, и индекс ключа может совместно использоваться между CBPP 180 и эмитентом/базовой системой 272 для облегчения обработки транзакций с использованием LUK.

[0095] Затем CBPP 280 упаковывает данные 228 предоставления, которые могут включать в себя альтернативный идентификатор счета или обозначение, начальный набор параметров счета, например, LUK и индекс ключа, и другую полезную информацию для выполнения и/или обработки транзакции (например, набор из одного или более порогов ограниченного использования, связанный с LUK), и отправляет данные 228 предоставления на MAP 270. Затем MAP 270 может пересылать информацию в качестве данных 230 предоставления на портативное устройство 201 связи. Затем мобильное приложение сохраняет параметры счета и полезную информацию на портативном устройстве 201 связи, чтобы портативное устройство 201 связи можно было использовать для проведения бесконтактных транзакций по счету пользователя.

[0096] Следует отметить, что в некоторых вариантах осуществления, разные субъекты в системе (например, портативное устройство 201 связи, CBPP 280 и эмитент/базовая система 272) может обеспечиваться с разными лимитами использования для набора из одного или более порогов ограниченного использования в процессе регистрации и предоставления, и соответствующие субъекты могут запускать последующее пополнение параметров счета с разными лимитами использования.

[0097] После успешного предоставления данных 230 предоставления портативному устройству 201 связи, портативное устройство 201 связи может отправлять квитирование или подтверждение 232 на MAP 270. MAP 270 также может отправлять подтверждение 234 на CBPP 280, которая, в свою очередь, пересылает подтверждение 236 эмитенту/базовой системе 272 для завершения процесса регистрации и предоставления.

[0098] Следует понимать, что вышеописанный процесс регистрации и предоставления является лишь примером, и что последовательность обмена сообщениями в некоторых вариантах осуществления может иметь разные вариации. В некоторых вариантах осуществления, CBPP 280 и эмитент/базовая система 272 могут меняться ролями. Например, CBPP 280 может принимать запрос регистрации 324 от MAP 270 и отправлять запрос 226 предоставления эмитенту/базовой системе 372. В порядке другого примера, MAP 270 может отправлять подтверждение 234 эмитенту/базовой системе 272, и эмитент/базовая система может отправлять подтверждение 236 на CBPP 280.

[0099] IV. Выполнение транзакции

[0100] Когда портативному устройству связи предоставлены надлежащие параметры счета, портативное устройство связи можно использовать для выполнения бесконтактной транзакции, например, путем размещения портативного устройства связи вблизи бесконтактного устройства чтения устройства доступа. В зависимости от возможностей устройства доступа, бесконтактная транзакция, проведенная с использованием описанных здесь способов может обрабатываться, как если бы транзакция осуществлялась с помощью карты с интегральной микросхемой (так называемая “транзакция на основе интегральной микросхемы”) или если бы транзакция осуществлялась с помощью карты с магнитной полоской (так называемая “транзакция на основе магнитной полоски”). В некоторых вариантах осуществления, времена бесконтактной транзакции с использованием описанных здесь методов эмуляции карты могут быть аналогичны временам реализации на основе защитных элементов. Например, согласно некоторым вариантам осуществления, для завершения бесконтактной транзакции с использованием эмуляции карты может потребоваться менее 500 миллисекунд.

[0101] В некоторых вариантах осуществления, выполнение бесконтактной транзакции с использованием портативного устройства связи может осуществляться путем обеспечения или обмена сообщениями (например, сообщениями протокольного блока данных прикладного уровня (APDU)) между мобильным приложением, выполняющимся на портативном устройстве связи, и бесконтактным устройством чтения устройства доступа по бесконтактной среде, например, радиоволнам. Сообщения могут принимать форму команд APDU, отправляемых с бесконтактного устройства чтения на портативное устройство связи, и ответов APDU, отправляемых из мобильного приложения на бесконтактное устройство чтения в ответ на команды APDU. Для обеспечения дополнительной защиты, мобильное приложение может быть сконфигурировано только отвечать на команды APDU, принятые от бесконтактного интерфейса или бесконтактного контроллера портативного устройства связи. Другими словами, мобильное приложение можно сконфигурировать так, чтобы оно игнорировало или отклоняло команды APDU, принятые от других приложений или компонентов, и/или команды ADPU, которые мобильное приложение не распознает. В некоторых вариантах осуществления, если мобильное приложение принимает нераспознанную команду APDU от бесконтактного интерфейса или бесконтактного контроллера портативного устройства связи, мобильное приложение может отвечать на команду словом статуса по умолчанию.

[0102] В некоторых вариантах осуществления, когда мобильное приложение взаимодействует с внешним субъектом (например, MAP, CBPP или эмитентом/базовой системой через MAP или бесконтактное устройство чтения устройства доступа), для которого мобильное приложение может изменять свое состояние или свою сохраненную информацию, мобильное приложение обрабатывает взаимодействие атомическим образом. Другими словами, мобильное приложение может обрабатывать либо все функции, необходимые для взаимодействия, либо ни одну из них. Таким образом, мобильное приложение может по-прежнему распознавать состояние, как воспринимаемое от внешних субъектов.

[0103] В ходе установки мобильного приложения, мобильное приложение может регистрировать имя своей среды системы ближнего бесконтактного платежа (PPSE), а также все идентификаторы приложений (AID), покрытые мобильным приложением, чтобы гарантировать, что транзакции с использованием этих AID маршрутизируются на мобильное приложение (например, этого можно добиться через декларацию в манифесте мобильного приложения мобильной операционной системе). Например, в некоторых вариантах осуществления, мобильное приложение может быть зарегистрировано для приема команд APDU для одного или более AID PPSE с именем, например, “2PAY.SYS.DDF01.”

[0104] В некоторых вариантах осуществления, мобильное приложение может быть зарегистрировано для приема и обработки команд APDU для множественных AID (например, AID, заданных для конкретного эмитента, платежного оператора или сети обработки, поставщика услуг, и т.д.), и в некоторых сценариях, множественные AID могут быть связаны с единым счетом. С единым счетом могут быть связаны множественные AID, например, если транзакция, проведенная по этому счету, может обрабатываться разными сетями обработки платежей и/или если счет может иметь разные услуги, признаки, типы продукта и возможности платежа, связанные со счетом. Например, единый счет может иметь общий дебетовый AID и AID, зависящий от сети обработки платежей (например, Visa AID), связанный с единым счетом. В порядке другого примера, единый счет может поддерживать разные платежные продукты, и каждый платежный продукт может иметь свой собственный AID. Множественные AID могут передаваться на устройство доступа, чтобы устройство доступа могло выбирать предпочтительный AID для выбора метода обработки транзакции (например, сети обработки платежей) и/или какие услуги или признаки связывать с транзакцией или обеспечивать для нее. С этой целью множественные AID можно вносить в запись каталога для PPSE и передавать на устройство доступа.

[0105] Мобильное приложение на портативном устройстве связи может принимать, сохранять и/или поддерживать генерацию информации, связанной со счетом, чтобы мобильное приложение могло в ответ сообщать необходимую информацию бесконтактному устройству чтения, а также обеспечивать держателей карты информацией о счете через пользовательский интерфейс портативного устройства связи. Эта информация, полностью или частично, может обеспечиваться мобильному приложению в процессе регистрации и предоставления. Информация, связанная со счетом, может включать в себя дизайн карты или другие визуальные особенности, которые идентифицирует счет покупателю, информация идентификации счета, которая может идентифицировать счет пользователю (например псевдоним или последние 4 цифры счета), состояние счета (например активный, приостановленный и т.д.), информацию конфигурации счета, параметры потока транзакции (например, информация, которая обеспечивается бесконтактному устройству чтения в ходе транзакции), текущий набор параметров счета (например, LUK и индекс ключа) и соответствующий набор из одного или более порогов ограниченного использования и соответствующие лимиты использования, и журнал проверки транзакции, и т.д. Информация конфигурации счета может включать в себя AID счета, метод(ы) проверки покупателя (CVM) (например, онлайновый PIN, CVM покупательского устройства, подпись, и т.д.) поддерживаемые счетом (или соответствующим AID, если присутствуют множественные AID) и их приоритет, поддерживает ли счет транзакции на основе магнитной полоски, и индекс ключа вывода (DKI), связанный с главным ключом эмитента, используемым при проверке криптограмм транзакций. Для мобильных приложений, поддерживающих множественные счета для одного и того же или разных AID счета, мобильное приложение также может поддерживать понятие, какой счет в данный момент является активным счетом, и способно заполнять ответы бесконтактному устройству чтения данными согласно активному в данный момент счету.

[0106] Мобильное приложение также может реализовывать один или более счетчиков для отслеживания транзакционной активности мобильного приложения. Например, мобильное приложение может реализовывать счетчик последовательности (SC) для определения, сколько раз мобильное приложение успешно запросило новые параметры счета для конкретного счета. Мобильное приложение также может реализовывать счетчик транзакций с помощью приложения (ATC) для определения, сколько раз мобильное приложение использовался для инициирования транзакции.

[0107] В ходе транзакции, мобильное приложение может принимать, сохранять и/или динамически строить информацию, например, параметры потока транзакции, связанные с бесконтактной транзакцией, для возврата необходимой информации на бесконтактное устройство чтения для успешного выполнения транзакции. Некоторые из параметров потока транзакции могут приниматься, сохраняться и/или строиться до инициирования бесконтактной транзакции, тогда как некоторые параметры потока транзакции (например, криптограмма транзакции) могут динамически строиться во время транзакции. Для мобильных приложений, поддерживающих множественные AID, разные параметры потока транзакции могут сохраняться и/или генерироваться для каждого AID. Иллюстративные детали параметров потока транзакции (например, включающие в себя информацию обработки транзакции и/или данные счета, упомянутые ниже), и иллюстративные детали информационных обменов между мобильным приложением и бесконтактным устройством чтения будут описаны со ссылкой на фиг. 3 для транзакции на основе интегральной микросхемы, и со ссылкой на фиг. 4 для транзакции на основе магнитной полоски.

[0108] Транзакция на основе интегральной микросхемы

[0109] Фиг. 3 демонстрирует пример обмена информации между портативным устройством 301 связи и устройством 360 доступа при осуществлении транзакции на основе интегральной микросхемы, согласно некоторым вариантам осуществления. В некоторых вариантах осуществления, передачи могут принимать форму команд и ответов ADPU. Однако следует понимать, что для обмена полезной информацией для проведения транзакции можно использовать другие сообщения, протоколы обмена сообщениями или форматы. Передачи могут осуществляться между мобильным приложением, выполняющимся на портативном устройстве 301 связи, и бесконтактным устройством чтения устройства 360 доступа. В некоторых вариантах осуществления, мобильное приложение может осуществлять связь с бесконтактным устройством чтения с использованием API эмуляции карты мобильной операционной системы портативного устройства 301 связи, и, таким образом, транзакция может осуществляться без необходимости в использовании защитного элемента (хотя можно использовать защитный элемент).

[0110] Когда устройство 360 доступа обнаруживает присутствие портативного устройства 301 связи вблизи бесконтактного устройства чтения устройства 360 доступа, устройство 360 доступа может инициировать транзакцию путем отправки запроса 302 доступных приложений на портативное устройство 301 связи для запрашивания информации о том, какое(ие) платежное(ые) приложение(я) (например, список AID) могут быть доступны на мобильном приложении портативного устройства 301 связи. В некоторых вариантах осуществления, запрос 302 доступного(ых) приложения(ий) может принимать форму команды выбора PPSE. Запрос 302 доступных приложений может включать в себя идентификатор платежной среды (например, имя PPSE, например “2PAY.SYS.DDF01”) для идентификации платежной среды, поддерживаемой устройством 360 доступа и мобильным приложением.

[0111] Приняв запрос 302 доступных приложений, мобильное приложение портативного устройства 301 связи может идентифицировать и обрабатывать запрос путем распознавания идентификатора платежной среды (например, имени PPSE), включенного в запрос, и отвечать путем отправки ответа 304 доступных приложений обратно на устройство 360 доступа. Ответ 304 доступных приложений может включать в себя список доступных AID и может включать в себя идентификатор платежной среды (например, имя PPSE) в качестве особого имени файла. В некоторых вариантах осуществления, ответ 304 доступных приложений может принимать форму ответа выбора PPSE и может включать в себя информацию управления файлами (FCI) PPSE. Например, ответ 304 доступных приложений может включать в себя запись каталога для каждого доступного AID. Если мобильное приложение поддерживает только один AID (независимо от количества счетов, связанных с этим AID), мобильное приложение может отвечать единственной записью каталога для поддерживаемого AID. Если мобильное приложение поддерживает счет с множественными AID, мобильное приложение может отвечать записью каталога для каждого из поддерживаемых AID. Каждая запись каталога может включать в себя информацию, например AID, метку приложения, связанную с AID (например, мнемонику, связанную с AID), указатель приоритета применения, указывающий приоритет AID, идентификатор ядра, указывающий предпочтение ядра приложения и/или дополнительную информацию, относящуюся к конкретному AID. Ответ 304 доступного(ых) приложения(й) также может включать в себя другие данные, например, дискреционные данные эмитента FCI.

[0112] Когда устройство 360 доступа принимает ответ 304 доступных приложений, устройство доступа 304 может выбирать подходящее приложение из списка приложений, принятого в ответе 304 доступных приложений (например, путем выбора AID из доступных AID, принятых в ответе 304 доступного(ых) приложения(й)). В некоторых вариантах осуществления, выбранный AID может быть наиболее приоритетным AID, доступным на мобильном приложении, которое поддерживается устройством 360 доступа. Устройство 360 доступа может отправлять выбор 306 приложения с выбранным AID на мобильное приложение портативного устройства 301 связи для продолжения транзакции. В некоторых вариантах осуществления, выбор 306 приложения может принимать форму команды выбора AID.

[0113] Приняв выбор 306 приложения, мобильное приложение портативного устройства 301 связи может отправлять запрос 308 данных транзакции с помощью терминала для запрашивания данных транзакции от устройства 360 доступа, которые могут потребоваться для выполнения транзакции с использованием выбранного приложения/AID. В некоторых вариантах осуществления, запрос 308 данных транзакции с помощью терминала может принимать форму ответа выбора AID и может включать в себя информацию управления файлами (FCI) AID с выбранным AID в качестве особого имени файла. Запрос 308 данных транзакции с помощью терминала может включать в себя список идентификаторов данных транзакции для запрашивания надлежащих данных от устройства 360 доступа, и список идентификаторов данных транзакции может принимать форму списка объектов данных вариантов обработки (PDOL). Данные транзакции, запрашиваемые мобильным приложением для транзакции, могут включать в себя квалификаторы транзакции с помощью терминала (TTQ), санкционированную сумму, другую сумму, код страны терминала, результаты проверки терминала, код валюты транзакции, дату транзакции, тип транзакции, и/или непредсказуемое число. Запрос 308 данных транзакции с помощью терминала также может включать в себя другие данные, например, дискреционные данные эмитента FCI, идентификатор прикладной программы и предпочтительный язык.

[0114] После приема запроса 308 данных транзакции с помощью терминала, устройство 360 доступа может отправлять, на мобильное приложение портативного устройства 301 связи, данные 310 транзакции с помощью терминала, запрашиваемые мобильным приложением. В некоторых вариантах осуществления, данные 310 транзакции с помощью терминала могут отправляться в форме команды получения вариантов обработки (GPO) и могут включать в себя запрашиваемые данные транзакции с помощью терминала в списке объектов данных вариантов обработки (PDOL). В некоторых вариантах осуществления, данные 310 транзакции с помощью терминала (например, квалификаторы транзакции с помощью терминала (TTQ)) могут включать в себя указатель типа транзакции, указывающий, поддерживает ли устройство 360 доступа транзакции на основе интегральной микросхемы или транзакции на основе магнитной полоски. Таким образом, в транзакции на основе интегральной микросхемы, представленной на фиг. 3, устройство 360 доступа может отправлять указатель типа транзакции в данных 310 транзакции с помощью терминала для указания, что устройство 360 доступа поддерживает транзакции на основе интегральной микросхемы. В некоторых вариантах осуществления, данные 310 транзакции с помощью терминала (например, квалификаторы транзакции с помощью терминала (TTQ)) также могут включать в себя указатель необходимости метода проверки покупателя (CVM) для указания, необходим ли CVM устройству 360 доступа для транзакции, и также один или более указателей типа CVM, указывающих типы CVM, поддерживаемые устройством 360 доступа. Примеры CVM, которые могут поддерживаться устройством 360 доступа, могут включать в себя онлайновый PIN, подпись и/или CVM покупательского устройства (CDCVM), например, код-пропуск, используемый на портативном устройстве 301 связи для разблокировки экрана или мобильного приложения.

[0115] После того, как мобильное приложение портативного устройства 301 связи принимает данные 310 транзакции с помощью терминала, мобильное приложение может увеличивать свой счетчик транзакций с помощью приложения (ATC), генерировать динамическую информацию обработки транзакции с использованием, по меньшей мере, некоторых из принятых данных 310 транзакции с помощью терминала, и отправлять набор информации 312 обработки транзакции, включающий в себя сгенерированную динамическую информацию обработки транзакции, на устройство 360 доступа. В некоторых вариантах осуществления, информацию 312 обработки транзакции можно отправлять в форме ответа GPO. В некоторых вариантах осуществления, информация 312 обработки транзакции может включать в себя один или более указателей файлов приложения (AFL), которые устройство 360 доступа может использовать в качестве адреса(ов) файла для считывания данных счета, хранящихся на портативном устройстве 301 связи, и профиль смены приложений (AIP), который можно использовать для указания возможностей мобильного приложения.

[0116] Для транзакции на основе интегральной микросхемы, информация 312 обработки транзакции может включать в себя криптограмму транзакции, динамически генерируемую с использованием LUK, эквивалентные данные дорожки-2 и данные добавления, например, данные приложения эмитента (IAD), указатель формфактора (FFI), квалификаторы карточной транзакции (CTQ), данные информации криптограммы (CID), обновленный ATC и/или порядковый номер PAN (PSN) приложения. В некоторых вариантах осуществления, данные приложения эмитента (IAD) могут включать в себя указатель длины, указывающий длину IAD, номер версии криптограммы (CVN), указывающий версию криптограммы транзакции, указатель выведенного ключа (DKI), который можно использовать для идентификации главного ключа (например главного ключа, связанного с эмитентом, используемого при генерации LUK), результаты проверки карты (CVR), ID поставщика кошелька и/или данные вывода, например, индекс ключа, который использовался при генерации LUK.

[0117] Результаты проверки карты (CVR) могут включать в себя информацию о субъекте проверки CVM и тип проверки CVM для транзакции. Субъект проверки CVM используется для указания, какой субъект осуществляет проверку CVM для транзакции. Субъектом проверки может быть устройство доступа (или терминал), совмещенное защищенное приложение, доверенное приложение среды выполнения, само мобильное приложение, удаленный сервер или компьютер (например, облако) или мобильная операционная система. Тип проверки CVM используется для указания способа CVM, используемого для транзакции. Способ CVM может предусматривать использование кода-пропуска, биометрической информации (например, отпечатка пальца), графического ключа (например, для блокировки экрана), подписи или онлайнового PIN. В некоторых вариантах осуществления, если данные 310 транзакции с помощью терминала, принятые от устройства 360 доступа, указывают, что CVM, поддерживаемый устройством 360 доступа, является онлайновым PIN или подписью, субъект проверки CVM в CVR можно указывать как устройство доступа (или терминал) для указания, что устройство 360 доступа является субъектом проверки, и соответственно можно задавать тип проверки CVM (например, онлайновый PIN или подпись).

[0118] Если данные 310 транзакции с помощью терминала, принятые от устройства 360 доступа, указывают, что CVM, поддерживаемый устройством 360 доступа, является CDCVM, субъект проверки CVM и тип проверки CVM можно указывать согласно параметрам конфигурации счета. Например, если счет поддерживает CVM с использованием кода-пропуска, который проверяется мобильной операционной системой портативного устройства 301 связи, субъект проверки CVM можно указывать как мобильную операционную систему, и тип проверки CVM можно задавать так, чтобы указывать, что CVM является кодом-пропуском. В некоторых вариантах осуществления, указатель осуществляемого CDCVM может быть включен в квалификаторы карточной транзакции (CTQ) для указания, успешно ли субъект проверки CVM проверил пользователя с использованием CDCVM, указанного типом проверки CVM.

[0119] Если данные 310 транзакции с помощью терминала, принятые от устройства 360 доступа, указывают, что CVM не требуется, субъект проверки CVM и тип проверки CVM можно задавать так, чтобы указывать, что не был проверен CVM. В некоторых вариантах осуществления, CVR может включать в себя дополнительные данные, например, указатель порога, который указывает, был ли превышен один или более порогов ограниченного использования, связанных с LUK.

[0120] Указатель формфактора (FFI) может включать в себя информацию о портативном устройстве 301 связи, например, номер версии указателя формфактора, указывающий версию используемого указателя формфактора, указатель формфактора платежного устройства покупателя, указывающий тип устройства портативного устройства 301 связи, и указатели признаков платежного устройства покупателя, указывающие, какие признаки платежа поддерживаются портативным устройством 301 связи. Формфактор платежное устройство покупателя может указывать, что портативное устройство 301 связи является стандартной картой (например, картой типа ID-1, как указано в ISO 7811), мини-картой, некарточным формфактором (например, брелоком для ключей, часами, браслетом, кольцом, наклейкой, и т.д.), или мобильным телефоном. Указатели признаков платежного устройства покупателя могут указывать, способно ли портативное устройство 301 связи использовать код-пропуск (может быть отдельным от PIN, который используется в ходе транзакций), имеет ли оно панель подписи, имеет ли оно голограмму, поддерживает ли оно значения проверки карты (например, CVV2), способно ли оно к двустороннему обмену сообщениями для обмена информацией идентификации между эмитентом и пользователем и/или поддерживает ли оно использование облачных реквизитов (например, LUK, обозначения, и т.д.). Указатель формфактора (FFI) также может включать в себя указатель технологии платежных транзакций, указывающий, что портативное устройство 301 связи поддерживает бесконтактные транзакции (например, NFC).

[0121] Следует понимать, что в некоторых вариантах осуществления, информация 312 обработки транзакции, отправляемая с портативного устройства 301 связи на устройство 360 доступа, может включать в себя, частично или полностью, вышеописанную информацию, и, в некоторых вариантах осуществления, может включать в себя дополнительную информацию, конкретно не описанную.

[0122] После того, как устройство 360 доступа принимает информацию 312 обработки транзакции, устройство 360 доступа может отправлять запрос 314 данных счета на мобильное приложение портативного устройства 301 связи для считывания дополнительных данных счета, которые могут храниться на портативном устройстве 301 связи. В некоторых вариантах осуществления, запрос 314 данных счета может принимать форму команды чтения записи, и может включать в себя указатель файла приложения (AFL), указывающий местоположение данных счета, которые устройство 360 доступа пытается считывать. AFL, включенный в запрос 314 данных счета, может соответствовать AFL в информации 312 обработки транзакции, которая была обеспечена устройству 360 доступа с портативного устройства 301 связи.

[0123] После того, как устройство 360 доступа принимает информацию 312 обработки транзакции, устройство 360 доступа может отправлять запрос 314 данных счета на мобильное приложение портативного устройства 301 связи для считывания дополнительных данных счета, которые могут храниться на портативном устройстве 301 связи. В некоторых вариантах осуществления, запрос 314 данных счета может принимать форму команды чтения записи, и может включать в себя указатель файла приложения (AFL), указывающий адрес или местоположение данных счета, которые устройство 360 доступа пытается считывать. AFL, включенный в запрос 314 данных счета, может соответствовать AFL в информации 312 обработки транзакции, обеспеченной с портативного устройства 301 связи.

[0124] В ответ на прием запроса 314 данных счета от устройства 360 доступа, портативное устройство 301 связи может отправлять данные 316 счета, хранящиеся в положении, указанном AFL, на устройство 360 доступа. В некоторых вариантах осуществления, данные 316 счета могут отправляться в форме ответа чтения записи. Данные 316 счета могут включать в себя, например, управление использованием приложения, которое указывает ограничения, налагаемые эмитентом на использование и услуги, разрешенные для приложения, имя держателя карты, исключительные данные покупателя, код страны эмитента, ID запросчика обозначения (например, если используется обозначение), и/или другие данные, относящиеся к счету, доступные в местоположении AFL.

[0125] Следует понимать, что в некоторых вариантах осуществления, данные 316 счета, отправляемые с портативного устройства 301 связи на устройство 360 доступа, могут включать в себя частично или полностью вышеописанную информацию, и, в некоторых вариантах осуществления, могут включать в себя дополнительную информацию, конкретно не описанную.

[0126] В некоторых вариантах осуществления, может существовать более чем одна пара запроса 314 данных счета и данных 316 счета, которыми обмениваются между собой устройство 360 доступа и портативное устройство 301 связи, например, если для завершения транзакции устройству 360 доступа необходимо хранить дополнительные данные, относящиеся к счету. После того, как устройство 360 доступа принимает необходимые данные из информации 312 обработки транзакции и/или одной или более передач данных 316 счета, некоторые или все из элементов данных в информации 312 обработки транзакции и/или одной или более передач данных 316 счета могут использоваться устройством 360 доступа для генерации сообщения запроса авторизации транзакции для запрашивания авторизации транзакции от эмитента. Например, в некоторых вариантах осуществления, сообщение запроса авторизации транзакции может включать в себя, по меньшей мере, эквивалентные данные дорожки-2 и криптограмму транзакции, сгенерированную с помощью LUK, и транзакция может авторизоваться на основании, по меньшей мере, проверки того, что криптограмма транзакции была сгенерирована правильно, и что LUK, используемый при генерации криптограммы транзакции, не истощил набор из одного или более порогов ограниченного использования LUK.

[0127] Транзакция на основе магнитной полоски

[0128] Фиг. 4 демонстрирует пример обмена информации между портативным устройством 401 связи и устройством 460 доступа в ходе транзакции на основе магнитной полоски, согласно некоторым вариантам осуществления. В некоторых вариантах осуществления, передачи могут принимать форму команд и ответов ADPU. Однако следует понимать, что для обмена полезной информацией для проведения транзакции можно использовать другие сообщения, протоколы обмена сообщениями или форматы. Передачи могут осуществляться между мобильным приложением, выполняющимся на портативном устройстве 401 связи и бесконтактном устройстве чтения устройства 460 доступа. В некоторых вариантах осуществления, мобильное приложение может осуществлять связь с бесконтактным устройством чтения с использованием API эмуляции карты мобильной операционной системы портативного устройства 401 связи, и, таким образом, транзакция может осуществляться без необходимости в использовании защитного элемента (хотя можно использовать защитный элемент).

[0129] Для транзакции на основе магнитной полоски, запрос 402 доступных приложений, ответ 404 доступного приложения, выбор 406 приложения и передачи запроса 408 данных транзакции с помощью терминала и соответствующие элементы данных, включенные в передачи аналогичны тем, которые применяются в транзакции на основе карты с интегральной микросхемой, как описано выше со ссылкой на фиг. 3, и, таким образом, их подробное описание не будет описано.

[0130] В ответ на прием запроса 408 данных транзакции с помощью терминала из мобильного приложения портативного устройства 401 связи, устройство 460 доступа может отправлять запрашиваемые данные 410 транзакции с помощью терминала на портативное устройство 401 связи. Данные 410 транзакции с помощью терминала, обеспеченные портативному устройству 401 связи в транзакции на основе магнитной полоски аналогичны тем, которые применяются в транзакции на основе карты с интегральной микросхемой, как описано выше со ссылкой на фиг. 3, за исключением того, что указатель типа транзакции, обеспеченный в данных 410 транзакции с помощью терминала (например, квалификаторы транзакции с помощью терминала (TTQ)) может указывать, что устройство 460 доступа поддерживает транзакции на основе магнитной полоски.

[0131] После того, как мобильное приложение портативного устройства 401 связи принимает данные 410 транзакции с помощью терминала и определяет, что устройство 460 доступа поддерживает транзакции на основе магнитной полоски, мобильное приложение может увеличивать свой счетчик транзакций с помощью приложения (ATC), и отправлять набор информации 412 обработки транзакции на устройство 460 доступа. В некоторых вариантах осуществления, информацию 412 обработки транзакции можно отправлять в форме ответа GPO. В некоторых вариантах осуществления, информация 412 обработки транзакции может включать в себя один или более указателей файлов приложения (AFL), которые устройством 460 доступа может использовать в качестве адреса(ов) файла для считывания данных счета, хранящихся на портативном устройстве 401 связи, и профиль смены приложений (AIP), который можно использовать для указания возможностей мобильного приложения. В некоторых вариантах осуществления, один или более AFL, обеспеченные устройству 460 доступа в ходе транзакции на основе магнитной полоски, могут отличаться от AFL, обеспеченного(ых) при осуществлении транзакции на основе интегральной микросхемы, таким образом, что мобильное приложение поддерживает разные места для хранения отдельных наборов данных для использования в транзакциях на основе магнитной полоски и в транзакциях на основе интегральной микросхемы. Мобильное приложение также может генерировать динамическую информацию обработки транзакции, которая может использовать или не использовать, по меньшей мере, некоторые из принятых данных 410 транзакции с помощью терминала, и сохранять сгенерированную информацию в положении, доступном по одному или более указателям файлов приложения (AFL). Динамическая информация обработки транзакции может включать в себя, например, криптограмму транзакции, сгенерированную с использованием LUK.

[0132] После того, как устройство 460 доступа принимает информацию 412 обработки транзакции, устройство 460 доступа может отправлять запрос 414 данных счета на мобильное приложение портативного устройства 401 связи для считывания данные счета, которые могут храниться на портативном устройстве 401 связи. В некоторых вариантах осуществления, запрос 414 данных счета может принимать форму команды чтения записи, и может включать в себя указатель файла приложения (AFL), указывающий местоположение данных счета, которые устройство 460 доступа пытается считывать. AFL, включенный в запрос 414 данных счета, может соответствовать AFL в информации 412 обработки транзакции, которая была обеспечена устройству 460 доступа с портативного устройства 401 связи.

[0133] В ответ на прием запроса 414 данных счета от устройства 460 доступа, портативное устройство 401 связи может отправлять данные 416 счета, хранящиеся в положении, указанном AFL, на устройство 460 доступа. В некоторых вариантах осуществления, данные 416 счета могут отправляться в форме ответа чтения записи. Данные 416 счета могут включать в себя, например, эквивалентные данные дорожки-2 и имя держателя карты, и т.д. В некоторых вариантах осуществления, для транзакции на основе магнитной полоски, криптограмма транзакции, сгенерированная с использованием LUK и/или индекса ключа, связанного с LUK, может быть внедрена в эквивалентные данные дорожки-2.

[0134] Следует понимать, что в некоторых вариантах осуществления, данные 416 счета, отправляемые с портативного устройства 401 связи на устройство 460 доступа, могут включать в себя частично или полностью вышеописанную информацию, и, в некоторых вариантах осуществления, могут включать в себя дополнительную информацию, конкретно не описанную.

[0135] В некоторых вариантах осуществления, может существовать более чем одна пара запроса 414 данных счета и данных 416 счета, которыми обмениваются между собой устройство 460 доступа и портативное устройство 401 связи, например, если для завершения транзакции устройству 460 доступа необходимо хранить дополнительные данные, относящиеся к счету. После того, как устройство 460 доступа принимает необходимые данные из информации 412 обработки транзакции и/или одной или более передач данных 416 счета, некоторые или все из элементов данных в информации 412 обработки транзакции и/или одной или более передач данных 416 счета могут использоваться устройством 460 доступа для генерации сообщения запроса авторизации транзакции для запрашивания авторизации транзакции от эмитента. Например, в некоторых вариантах осуществления, сообщение запроса авторизации транзакции может включать в себя, по меньшей мере, эквивалентные данные дорожки-2 и криптограмму транзакции, сгенерированную с помощью LUK, и транзакция может авторизоваться на основании, по меньшей мере, проверки того, что криптограмма транзакции была сгенерирована правильно, и что LUK, используемый при генерации криптограммы транзакции, не истощил набор из одного или более порогов ограниченного использования LUK.

[0136] Эквивалентные данные дорожки-2

[0137] Согласно некоторым вариантам осуществления, в зависимости от типа выполняемой транзакции (например, транзакции на основе интегральной микросхемы или транзакции на основе магнитной полоски), разные элементы данных могут быть включены в эквивалентные данные дорожки-2, обеспеченные из мобильного приложения портативного устройства связи устройству доступа. Таблица 1 демонстрирует пример формата эквивалентных данных дорожки-2 с внедренной криптограммой транзакции, которую можно использовать либо в транзакции на основе магнитной полоски, либо в транзакции на основе интегральной микросхемы.

Элемент данных

Идентификатор счета (например, PAN, альтернативный PAN, обозначение)

Разделитель полей = ‘D’

Дата истечения срока действия

Код услуги

Индекс ключа

Криптограмма транзакции

Заполнение ‘F’

Таблица 1: эквивалентные данные дорожки-2 с внедренной криптограммой транзакции

[0138] Индекс ключа связан с LUK, который использовался при генерации криптограммы транзакции для конкретной транзакции, и может включать в себя информацию, относящуюся к описанной здесь генерации LUK. Например, индекс ключа может быть начальным значением, которое использовалось для генерации LUK, и может включать в себя информацию времени (например, метку времени, указывающую, когда был сгенерирован LUK, и/или может включать в себя значение счетчика пополнения, указывающее, сколько раз LUK был обновлен или пополнен для конкретного счета, мобильного приложения или портативного устройства связи. В некоторых вариантах осуществления, индекс ключа может включать в себя значение счетчика транзакций с помощью приложения, указывающее количество транзакций, ранее проведенных мобильным приложением портативного устройства связи на момент генерации LUK, или может включать в себя псевдослучайное число, генерируемое поставщиком услуг облачной транзакции или подходящим субъектом, например, эмитентом, участвующим в обработке транзакции.

[0139] Криптограмма транзакции, внедренная в эквивалентные данные дорожки-2, может быть криптограммой, генерируемой с использованием LUK в качестве ключа шифрования. В некоторых вариантах осуществления, криптограмма транзакции, внедренная в эквивалентные данные дорожки-2, может отличаться от криптограммы транзакции, обеспечиваемой в информации 312 обработки транзакции (например, ответе GPO). Например, криптограмма транзакции, внедренная в эквивалентные данные дорожки-2 (может именоваться “преобразованной в десятеричную систему криптограммой транзакции”) может иметь уменьшенную длину (например, уменьшенную до шести цифр), и/или может генерироваться путем шифрования статических данных (например, заранее определенной числовой строки) вместо данных транзакции с помощью терминала.

[0140] В некоторых вариантах осуществления, где транзакция осуществляется с использованием оптического бесконтактного интерфейса, оптическое изображение, например, QR-код штрих-код, можно генерировать для кодирования формата эквивалентных данных дорожки-2, показанного в таблице 1, и оптическое изображение, кодирующее эквивалентные данные дорожки-2, может отображаться на портативном устройстве связи и представляться оптическому сканеру или устройству чтения устройства доступа для проведения транзакции.

[0141] Таблица 2 демонстрирует пример формата эквивалентных данных дорожки-2 без внедренной криптограммы транзакции, который можно использовать в транзакции на основе интегральной микросхемы.

Элемент данных

Идентификатор счета (например, PAN, альтернативный PAN, обозначение)

Разделитель полей = ‘D’

Дата истечения срока действия

Код услуги

Поле проверки PIN

Дискреционные данные дорожки 2

Заполнение ‘F’

Таблица 2: эквивалентные данные дорожки-2 без внедренной криптограммы транзакции

[0142] Для транзакции на основе интегральной микросхемы, криптограмма транзакции заранее обеспечена устройство доступа в информации 312 обработки транзакции (например, ответе GPO), и, таким образом, не обязательно включать криптограмму транзакции в эквивалентные данные дорожки-2 для транзакции на основе интегральной микросхемы. Поэтому формат эквивалентных данных дорожки-2, показанный в таблице 2, можно использовать для транзакции на основе интегральной микросхемы, хотя также можно использовать формат эквивалентных данных дорожки-2, показанный в таблице 1.

[0143] В некоторых вариантах осуществления, индекс ключа, связанный с LUK, может быть внедрен в дискреционные данные дорожки-2 в формате эквивалентных данных дорожки-2, показанном в таблице 2. Индекс ключа, например, может включать в себя информацию времени и/или значение счетчика пополнения, значение счетчика транзакций с помощью приложения или псевдослучайное число, или любой из описанных здесь примеров. В некоторых вариантах осуществления, индекс ключа может выступать в качестве начального значения для генерации криптограммы транзакции. Благодаря включению начального значения в дискреционные данные дорожки-2, сообщаемые эмитенту, эмитент может проверять начальное значение, и, в некоторых вариантах осуществления, повторно генерировать криптограмму транзакции с использованием начального значения для проверки криптограммы транзакции.

[0144] Следует понимать, что вышеописанные форматы эквивалентных данных дорожки-2 приведены в качестве примеров, и что в некоторых вариантах осуществления, в эквивалентных данных дорожки-2 могут быть опущены некоторые из элементов данных, и/или могут быть дополнительно включены конкретно не показанные элементы данных.

[0145] V. Журнал проверки транзакции

[0146] Согласно некоторым вариантам осуществления, мобильное приложение может обновлять журнал проверки транзакции, поддерживаемый мобильным приложением, в конце транзакции для включения информации о транзакции в журнал проверки транзакции. Мобильное приложение может распознавать конец транзакции путем распознавания, что вся информация обработки транзакции и/или данные счета, которые могут потребоваться устройству доступа для завершения транзакции, были обеспечены устройству доступа (например, распознавания, что последняя запись, заданная в AFL, была успешно возвращена, или в отсутствие AFL, когда был успешно возвращен ответ GPO).

[0147] Фиг. 5 демонстрирует примеры элементов данных, которые могут быть включены в журнал проверки транзакции, согласно некоторым вариантам осуществления. Мобильное приложение может поддерживать журнал проверки транзакции для каждого LUK или для каждого набора параметров счета. В некоторых вариантах осуществления, портативное устройство связи может поддерживать несколько журналов проверки транзакции для нескольких LUK или наборов параметров счета, или в необязательном порядке, после обновления или пополнения текущего LUK или текущих параметров счета, журнал проверки транзакции, соответствующий предыдущему LUK или предыдущим параметрам счета, можно удалять для экономии области памяти на портативном устройстве связи.

[0148] Журнал проверки транзакции может быть связан с и/или может включать в себя индекс ключа, соответствующий LUK или набору параметров счета, используемому в зарегистрированных транзакциях, и значение счетчика последовательности, связанное с индексом ключа или набором параметров счета, указывающее, сколько раз был пополнен LUK или набор параметров счета. Для каждой транзакции, проведенной с использованием конкретного LUK или конкретного набора параметров счета, журнал проверки транзакции может включать в себя метку времени транзакции, указывающую время соответствующей транзакции, непредсказуемое число (UN), обеспеченное от устройства доступа в ходе транзакции (при наличии), значение счетчика транзакций с помощью приложения (ATC), связанное с соответствующей транзакцией (например, значение, указывающее количество транзакций, проведенных с использованием мобильного приложения во время транзакции), и указатель типа транзакции, указывающий, была ли соответствующая транзакция проведена как транзакция на основе интегральной микросхемы или как транзакция на основе магнитной полоски. Метка времени транзакции может быть временем в формате UTC, определенным портативным устройством связи во время транзакции. В некоторых вариантах осуществления, дополнительная информация, например, местоположение портативного устройства связи во время соответствующей транзакции, может быть включена в журнал проверки транзакции. Следует понимать, что в некоторых вариантах осуществления, журнал проверки транзакции может включать в себя меньше элементов данных и/или может включать в себя другие, конкретно не показанные, элементы данных.

[0149] Журнал проверки транзакции можно использовать в различных целях, например, для постплатежной проверки и пополнения параметров счета. Фиг. 6 демонстрирует схему обмена информацией в иллюстративном процессе постплатежной проверки, согласно некоторым вариантам осуществления. Процесс постплатежной проверки может инициироваться эмитентом/базовой системой 672, когда эмитент/базовая система 672 решает проверить счет, например, в случае приема транзакции, помеченной как подозрительная или потенциально обманная, или когда эмитент/базовая система 672 проверяет счет случайным образом или периодически для противодействия мошенничеству.

[0150] Эмитент/базовая система 672 может инициировать процесс постплатежной проверки путем отправки на CBPP 680 запрос 622 журнала транзакций для запрашивания журнала проверки транзакции, связанного со счетом. Запрос 622 журнала транзакций может включать в себя такую информацию, как идентификатор счета, который CBPP 680 может использовать для идентификации счета. CBPP 680 может идентифицировать данный счет и мобильное приложение, на котором зарегистрирован счет, и пересылать эту информацию в качестве запроса 624 журнала транзакций на MAP 670. MAP 670 может идентифицировать и аутентифицировать портативное устройство связи, связанное со счетом и мобильным приложением, и отправлять запрос 626 журнала транзакций на идентифицированное мобильное приложение портативного устройства 601 связи.

[0151] Приняв запрос 626 журнала транзакций, мобильное приложение портативного устройства 601 связи может извлекать журнал проверки транзакции из памяти портативного устройства связи, и упаковывать данные в информацию 628 журнала транзакций для передачи эмитенту/базовой системе 672. Информация 628 журнала транзакций выводится из журнала проверки транзакции, хранящегося на портативном устройстве связи, и может включать в себя, частично или полностью, информацию, содержащуюся в журнале проверки транзакции, например, детали транзакции для каждой транзакции, например, метки времени транзакции, значения счетчика транзакций с помощью приложения, указателя типа транзакции, непредсказуемого числа, при наличии, и/или любой их комбинации; индекс ключа, связанный с LUK или параметрами счета, используемый для транзакций; счетчик последовательности, связанный с LUK или параметрами счета; и/или любую их комбинацию. Альтернативно или дополнительно, информация журнала транзакций, выведенная из журнала проверки транзакции, может включать в себя код аутентификации (например, код аутентификации сообщения, значение хэша и т.д.), вычисленный, частично или полностью, на основании информации в журнале проверки транзакции. Например, код аутентификации можно вычислять на основании деталей транзакции или на основании индекса ключа и/или счетчика последовательности совместно с деталями транзакции. В некоторых вариантах осуществления, код аутентификации можно генерировать с использованием LUK в качестве ключа шифрования.

[0152] После вывода полезной информации 628 журнала транзакций из журнала проверки транзакции, мобильное приложение на портативном устройстве 601 связи отправляет информацию 628 журнала транзакций на MAP 670. MAP 670 пересылает информацию в качестве информации 630 журнала транзакций на CBPP 680, и CBPP 680 пересылает информацию в качестве информации 632 журнала транзакций эмитенту/базовой системе 672. В некоторых вариантах осуществления, CBPP 680 может осуществлять проверку принятой информацией журнала транзакций, например, если CBPP 680 отслеживает транзакционную активность счета, и может, дополнительно или альтернативно, обеспечивать результат проверки в информации 632 журнала транзакций, передаваемой эмитенту/базовой системе 672.

[0153] Когда эмитент/базовая система 672 принимает информацию 632 журнала транзакций, эмитент/базовая система 672 может сравнивать информацию с подозрительной транзакцией и/или сравнивать информацию с транзакционной активностью для текущего LUK или набора параметров счета. Если информация 632 журнала транзакций указывает, что подозрительная транзакция была проведена мобильным приложением портативного устройства 601 связи и/или информация 632 журнала транзакций согласуется с транзакционной активностью, эмитент/базовая система 672 заканчивает процесс постплатежной проверки и поддерживает активный статус счета.

[0154] Если информация 632 журнала транзакций указывает, что подозрительная транзакция не происходит из мобильного приложения портативного устройства 601 связи, или если информация 632 журнала транзакций не согласуется с транзакционной активностью на стороне эмитента, эмитент/базовая система 672 может приостанавливать счет и отправлять извещение приостановки на CBPP 680. CBPP 680 может приостанавливать счет в своей собственной системе и пересылать извещение приостановки на MAP 670. Затем MAP 670 пересылает извещение приостановки на мобильное приложение портативного устройства 601 связи. В ответ на прием извещения приостановки, мобильное приложение может удалять текущий набор параметров счета из мобильного приложения и отображать сообщение для запрашивания пользователя связаться с эмитентом.

[0155] VI. Пополнение параметров счета

[0156] По истечении срока действия набора параметров счета (например, LUK) вследствие возраста параметров счета или когда использование параметров счета истощает соответствующий набор из одного или более порогов ограниченного использования, последующая транзакция, проведенная с использованием просроченного набора параметров счета, может быть отклонена. Для обеспечения возможности продолжать проведение транзакций с использованием мобильного приложения портативного устройства связи, мобильному приложению может потребоваться обновлять или пополнять набор параметров счета, доступный мобильному приложению. В некоторых вариантах осуществления, журнал проверки транзакции также можно использовать в процессе пополнения параметров счета для проверки, что мобильное приложение или портативное устройство связи, запрашивающее новые параметры счета, является тем же приложением или устройством, которое ранее приняло и использовало предыдущий набор параметров счета.

[0157] Для облегчения процесса пополнения параметров счета, мобильное приложение портативного устройства связи может отслеживать использование набора параметров счета (например, LUK), и поддерживать статус параметров счета, который указывает, исчерпан ли один или более порогов ограниченного использования, связанных с параметрами счета или LUK, или близок к истощению. Например, мобильное приложение может отслеживать, сколько транзакции было проведено с использованием набора параметров счета или LUK, сколько времени прошло после генерации набора параметров счета или LUK, и/или совокупную сумму транзакции по всем транзакциям, проведенным с использованием набора параметров счета или LUK. В конце каждой транзакции, мобильное приложение может обновлять использование набора параметров счета или LUK, отслеживаемого мобильным приложением, и сравнивать использование с набором из одного или более порогов ограниченного использования на устройстве. В некоторых вариантах осуществления, если мобильное приложение определяет, что использование текущего набора параметров счета или LUK истощило набор из одного или более порогов ограниченного использования на устройстве или использовался сверх лимита использования, мобильное приложение может инициировать запрос пополнения параметров счета. В некоторых вариантах осуществления, мобильное приложение может инициировать запрос пополнения параметров счета, если мобильное приложение определяет, что следующая транзакция, проведенная с использованием текущего набора параметров счета или LUK, исчерпает набор из одного или более порогов ограниченного использования. Это может осуществляться, например, для того, чтобы легче было гарантировать, что действительный набор параметров счета или LUK постоянно доступен мобильному приложению, таким образом, что следующая транзакция, проведенная с помощью мобильного приложения, не отклоняется.

[0158] Фиг. 7 демонстрирует схему обмена информацией в иллюстративном процессе пополнения параметров счета, согласно некоторым вариантам осуществления. В примере, показанном на фиг. 7, процесс пополнения параметров счета инициируется мобильным приложением портативного устройства 701 связи, и может именоваться процессом вытягивания пополнения. Когда мобильное приложение определяет, что набор из одного или более порогов ограниченного использования, связанный с текущим набором параметров счета, истощен или близок к истощению, мобильное приложение портативного устройства 701 связи может отправлять запрос 722 пополнения параметров счета на MAP 770 для пополнения набора параметров счета или LUK, доступного мобильному приложению.

[0159] Запрос 722 пополнения параметров счета может включать в себя информацию, идентифицирующую соответствующий счет, мобильное приложение и/или портативное устройство 701 связи, и может включать в себя информацию журнала транзакций, выведенную из журнала проверки транзакции, хранящегося на портативном устройстве связи. Информация журнала транзакций, обеспеченная в запросе 722 пополнения параметров счета, может включать в себя, частично или полностью, информацию, содержащуюся в журнале проверки транзакции, например, детали транзакции для каждой транзакции, проведенной с использованием текущего набора параметров счета или LUK (например, метки времени транзакции, значения счетчика транзакций с помощью приложения, указателя типа транзакции, непредсказуемого числа, при наличии, и/или любой их комбинации). Информация журнала транзакций может включать в себя индекс ключа, связанный с текущим набором параметров счета или LUK, и/или счетчик последовательности, связанный с текущим набором параметров счета или LUK. Альтернативно или дополнительно, информация журнала транзакций, выведенная из журнала проверки транзакции и обеспеченная в запросе 722 пополнения параметров счета, может включать в себя код аутентификации (например, код аутентификации сообщения, значение хэша и т.д.) вычисленный, частично или полностью, на основании информации в журнале проверки транзакции. Например, код аутентификации можно вычислять на основании деталей транзакции или на основании индекса ключа и/или счетчика последовательности совместно с деталями транзакции. В некоторых вариантах осуществления, код аутентификации можно генерировать с использованием LUK в качестве ключа шифрования.

[0160] Когда MAP 770 принимает запрос 722 пополнения параметров счета, MAP 770 пересылает запрос как запрос 724 пополнения параметров счета на CBPP 780. Приняв запрос 724 пополнения параметров счета, CBPP 780 может проверять информацию журнала транзакций или запрашивать эмитента/базовую систему 772 проверять информацию журнала транзакций. Если информация журнала транзакций согласуется с транзакционной активностью на CBPP 780 или эмитенте/базовой системе 772, CBPP 780 может генерировать новый набор параметров счета (например, новый индекс ключа и новый LUK) для пополнения текущего набора параметров счета на мобильном приложении. CBPP 780 может отправлять извещение 726 пополнения эмитенту/базовой системе 772 для извещения эмитента о том, что новый набор параметров счета пополняется на мобильном приложении. В некоторых вариантах осуществления, извещение 726 пополнения может включать в себя новый набор параметров счета (например, новый индекс ключа и новый LUK) таким образом, что эмитент/базовая система 772 может осуществлять свое собственное обновление. Эмитент/базовая система 772 может отвечать путем отправки квитирования 728 на CBPP 780.

[0161] После генерации нового набора параметров счета, CBPP 780 может отправлять новый набор 730 параметров счета на MAP 770. Новый набор 730 параметров счета может включать в себя новый индекс ключа, новый LUK и т.д., и, в некоторых вариантах осуществления, также может включать в себя новый набор из одного или более порогов ограниченного использования, связанный с параметрами счета или LUK, которые могут иметь другие лимиты использования, чем предыдущие пороги. Затем MAP 770 пересылает данные как новый набор 732 параметров счета на мобильное приложение портативного устройства 701 связи.

[0162] Когда мобильное приложение портативного устройства 701 связи принимает новый набор параметров счета (например, новый LUK и новый индекс ключа, связанный с LUK), мобильное приложение удаляет предыдущий набор параметров счета и соответствующие детали журнала проверки транзакции и отслеживание использования, и сохраняет новый набор параметров счета. Если новый набор параметров счета имеет разные лимиты использования для набора из одного или более порогов ограниченного использования, один или более порогов ограниченного использования может обновляться новыми лимитами использования. Мобильное приложение также увеличивает счетчик последовательности для каждого успешного пополнения параметров счета. После того, как мобильное приложение обновляет набор параметров счета, мобильное приложение портативного устройства 701 связи может отправлять подтверждение 734 на MAP 780, и MAP 780 может пересылать его как подтверждение 736 на CBPP 770 для подтверждения, что процесс пополнения параметров счета прошел успешно.

[0163] В некоторых вариантах осуществления, если эмитент/базовая система 772 отвечает за генерацию параметров счета, вместо отправки извещения 726 пополнения эмитенту/базовой системе 772, CBPP 780 может пересылать запрос 724 пополнения параметров счета эмитенту/базовой системе 772, и эмитент/базовая система 772 может генерировать новый набор параметров счета. (например, новый индекс ключа и новый LUK) в таких вариантах осуществления, эмитент/базовая система 772 может обеспечивать новый набор параметров счета для CBPP 780 и/или MAP 770 для пересылки на мобильное приложение на портативном устройстве 701 связи.

[0164] Согласно некоторым вариантам осуществления, процесс пополнения параметров счета может инициироваться CBPP 770 и/или эмитентом/базовой системой 772. Процесс пополнения параметров счета, который не инициируется мобильным приложением, может именоваться процессом проталкивания (push процессом) пополнения. Например, процесс пополнения параметров счета может запускаться транзакционной активностью, отслеживаемой CBPP 770 и/или эмитентом/базовой системой 772. В некоторых вариантах осуществления, CBPP 770 и/или эмитент/базовая система 772 может поддерживать свой собственный набор из одного или более порогов ограниченного использования, которые могут иметь или не иметь те же лимиты использования, что и пороги ограниченного использования на устройстве, поддерживаемые на мобильном приложении. CBPP 770 и/или эмитент/базовая система 772 может отслеживать использование текущего набора параметров счета (например, LUK).

[0165] Когда CBPP 770 определяет, что набор из одного или более порогов ограниченного использования на CBPP 770, связанный с текущим набором параметров счета, истощен или близок к истощению, CBPP 770 может отправлять сообщение проталкивания (push сообщение) на MAP 780, чтобы запрашивать мобильное приложение для пополнения своего текущего набора параметров счета. Когда эмитент/базовая система 772 определяет, что набор из одного или более порогов ограниченного использования эмитента, связанный с текущим набором параметров счета, истощен или близок к истощению, эмитент/базовая система 772 может отправлять сообщение проталкивания на CBPP 770 и/или MAP 780, чтобы запрашивать мобильное приложение для пополнения своего текущего набора параметров счета.

[0166] Приняв сообщение проталкивания для пополнения набора параметров счета от CBPP 770 или эмитента/базовой системы 772, MAP 780 может пересылать сообщение проталкивания на мобильное приложение портативного устройства 701 связи. В некоторых сценариях, портативное устройство 701 связи может отключаться, или мобильное приложение может не быть активным на портативном устройстве 701 связи, когда CBPP 770 и/или эмитент/базовая система 772 инициирует процесс пополнения. В таких сценариях, MAP 780 может ставить в очередь сообщение проталкивания для доставки на мобильное приложение в более позднее время, и может периодически пытаться обращаться к мобильному приложению, пока MAP 780 не установит связь с мобильным приложением. Когда мобильное приложение принимает сообщение проталкивания, запрашивающее мобильное приложение портативного устройства 701 связи пополнить параметры счета (например, LUK и соответствующий индекс ключа), в ответ, мобильное приложение портативного устройства 701 связи может отправлять запрос пополнения параметров счета с полезной информацией журнала транзакций на MAP 780. Процесс пополнения может продолжаться аналогичным образом, как процесс проталкивания пополнения, описанный выше со ссылкой на фиг. 7. В некоторых вариантах осуществления, CBPP 770 и/или эмитент/базовая система 772 может генерировать новый набор параметров счета и обеспечивать их для MAP 780 совместно с сообщением проталкивания, таким образом, что MAP 780 может обеспечивать новый набор параметров счета мобильному приложению, когда связь с мобильным приложением установлена.

[0167] Хотя вышеприведенное описание процесса пополнения параметров счета может быть приведено со ссылкой на пополнение LUK и индекс ключа, связанный с LUK, следует понимать, что процесс пополнения параметров счета можно использовать, например, для пополнения других параметров счета или соответствующей информации, например, для пополнения обозначения, которое используется в качестве заместителя для идентификатора счета. В некоторых вариантах осуществления, обозначение может пополняться одновременно с LUK и индексом ключа, или отдельно от LUK и индекса ключа.

[0168] VII. Криптограммы для транзакций

[0169] Согласно некоторым вариантам осуществления, поскольку для защиты реквизитов счета, хранящихся на портативном устройстве связи не требуется присутствия защитного элемента, параметры счета для проведения облачных транзакций могут иметь ограниченный срок действия, благодаря чему, даже если данный набор параметров счета скомпрометирован, похищенные параметры счета будут мало использоваться, поскольку срок их действия закончился или вскоре закончится. Например, вместо использования статического ключа, хранящегося в защитном элементе, для генерации криптограммы в ходе транзакций, как в некоторых реализациях защитного элемента, система облачной транзакции использует ключи ограниченного использования при генерации криптограмм транзакций.

[0170] В некоторых вариантах осуществления, можно использовать два типа криптограммы транзакции - один для данных дорожки-2, используемых в транзакциях на основе магнитной полоски, и другой для транзакций на основе интегральной микросхемы. Для обоих типов криптограммы транзакции, криптограмма транзакции генерируется с использованием ключа ограниченного использования (LUK). Различие между двумя типами криптограмм транзакций является входными данными, используемыми для генерации криптограммы и/или окончательного формата криптограммы транзакции, который передается на устройство доступа для проведения транзакции. Для транзакции на основе интегральной микросхемы, входные данные, используемые для генерации криптограммы, могут включать в себя динамические данные (например, данные, которые изменяются для каждой транзакции), принятые от бесконтактного устройства чтения устройства доступа в ходе транзакции (например, данные транзакции с помощью терминала), тогда как входные данные для транзакции на основе магнитной полоски могут быть статическими данными (например, данными, которые не изменяется от транзакции к транзакции, например, заранее определенной числовой строкой). Это означает, что в некоторых вариантах осуществления, для транзакции на основе магнитной полоски, либо CBPP, либо само мобильное приложение, может генерировать криптограмму транзакции, поскольку генерация криптограммы транзакции не опирается на данные от бесконтактного устройства чтения устройства доступа; и для транзакции на основе интегральной микросхемы, мобильное приложение обеспечивает генерацию криптограммы транзакции.

[0171] Следует также заметить, что в некоторых вариантах осуществления, вход для генерации криптограммы транзакции в транзакции на основе магнитной полоски может, альтернативно или дополнительно, включать в себя динамические данные, приняты от бесконтактного устройства чтения устройства доступа в ходе транзакции (например, данные транзакции с помощью терминала). Кроме того, вход для генерации криптограммы транзакции в транзакции на основе интегральной микросхемы может, альтернативно или дополнительно, включать в себя статические данные.

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

[0173] Фиг. 8 демонстрирует блок-схему в иллюстративном процессе 800 для генерации криптограммы транзакции, согласно некоторым вариантам осуществления. Любая из функций 806, 812, 818 и/или 824 шифрования может быть идентична или отличаться от любой из других функций шифрования. Например, любая из функций 806, 812, 818 и/или 824 шифрования может быть реализована как стандарт тройного шифрования данных (TDES), стандарт шифрования данных (DES), стандарт усовершенствованного шифрования (AES), или другие подходящие алгоритмы шифрования.

[0174] Процесс 800 можно разделить на две части - первую часть, относящуюся к генерации LUK (блоки 802-814), и вторую часть, относящуюся к генерации криптограммы транзакции (блоки 816-828). Первая часть, относящаяся к генерации LUK, может осуществляться однократно для генерации LUK (например, CBPP или эмитентом/базовой системой), и вторая часть, относящаяся к генерации криптограммы транзакции, может осуществляться несколько раз с использованием LUK, генерируемого из первой части (например, мобильным приложением), пока LUK не превысит свой набор из одного или более порогов ограниченного использования, при этом, первая часть, относящаяся к генерации LUK, может осуществляться повторно для пополнения или обновления LUK.

[0175] Процесс 800 может начинаться путем шифрования информации 804 счета первым ключом 802 шифрования с использованием функции 806 шифрования для генерации второго ключа 808 шифрования. Первым ключом 802 шифрования может быть основной ключ, который связан с эмитентом счета пользователя, и основной ключ может быть связан с группой счетов. Например, первый ключ 802 шифрования может быть связан с группой счетов в BIN или диапазоне PAN, предназначенном для услуги облачной транзакции. В некоторых вариантах осуществления, первым ключом 802 шифрования может быть главный ключ вывода (MDK), связанный с эмитентом счета, связанного с информацией 804 счета, и первый ключ 802 шифрования может поддерживаться на CBPP или на стороне эмитента/базовой системы.

[0176] Информация 804 счета может включать в себя информацию идентификации счета, например идентификатор счета (например, PAN), альтернативный идентификатор счета (например, альтернативный PAN) или обозначение, которое является заместителем для идентификатора счета, и может дополнительно включать в себя информацию идентификации пользователя, например порядковый номер (например, порядковый номер PAN (PSN)), который идентифицирует конкретного пользователя счета (например, когда несколько пользователей используют один и тот же счет). Например, информация 804 счета, которая используется в качестве входа функции 806 шифрования, может представлять собой конкатенацию информации идентификации счета и информации идентификации пользователя, или инвертированную версию конкатенации.

[0177] В некоторых вариантах осуществления, второй ключ 808 шифрования, генерируемый из информации 804 счета, может включать в себя несколько участков, каждый из которых генерируется из разных вариантов информации 804 счета. Например, второй ключ 808 шифрования может делиться на два участка. Первый участок второго ключа 808 шифрования можно генерировать путем шифрования информации 804 счета с использованием первого ключа 802 шифрования. Второй участок второго ключа 808 шифрования можно генерировать путем инвертирования информации 804 счета и шифрования инвертированной информации счета с использованием первого ключа 802 шифрования. Функция 806 шифрования, используемая для генерации второго ключа 808 шифрования, может представлять собой, например, стандарт тройного шифрования данных (TDES) или другие подходящие алгоритмы шифрования, и может использовать начальный вектор образования цепи, состоящий из двоичных нулей. В некоторых вариантах осуществления, второй ключ 808 шифрования, генерируемый из информации 804 счета, может соответствовать уникальному ключу вывода (UDK) для счета.

[0178] Процесс 800 может продолжаться путем шифрования информации 810 индекса ключа вторым ключом 808 шифрования с использованием функции 812 шифрования для генерации ключа 814 ограниченного использования (LUK). Информацию 810 индекса ключа можно выводить из индекса ключа, который включает в себя информацию, относящуюся к генерации LUK 814, и который можно использовать в качестве начального значения для генерации LUK 814. Например, индекс ключа может включать в себя информацию времени, указывающую, когда генерируется LUK 814. В некоторых вариантах осуществления, информацию времени можно представить в виде числовой строки ‘YHHHH’, где ‘Y’ (0-9) представляет младшую цифру текущего года, и ‘HHHH’ (0001-8784) представляет количество часов от начала 1 января текущего года, выраженное цифрами (например, первый час 1 января = 0001). В некоторых вариантах осуществления, индекс ключа также может включать в себя значение счетчика пополнения, указывающее, сколько раз этот LUK 814 был обновлен или пополнен в заранее определенный период времени (например, сколько раз генерировался LUK 814 каждый час). Например, значение счетчика пополнения можно представить в виде числовой строки ‘CC’ (00-99). В начале каждого часа, ‘CC’ начинается с 00 и увеличивается на 1 каждый раз, когда генерируется LUK 814. В некоторых вариантах осуществления, индекс ключа может включать в себя значение счетчика транзакций с помощью приложения, или псевдослучайное число, генерируемое CBPP или эмитентом.

[0179] Согласно некоторым вариантам осуществления, информацию 810 индекса ключа, обеспечиваемую в качестве входа функции 812 шифрования, можно генерировать путем заполнения индекса ключа одним или более числовыми значениями. Например, индекс ключа может заполняться числовым значением (например, 1 или 2, показанным на фиг. 8 как ‘m’ или ‘n’) в начале индекса ключа и/или числовым значением (например, 80000000, показанным на фиг. 8 как ‘xxxxxxxx’) в конце индекса ключа. В некоторых вариантах осуществления, LUK 814 генерируемый из информации 810 индекса ключа, может включать в себя несколько участков, каждый из которых генерируется из разных вариантов информации 810 индекса ключа. Например, LUK 814 может делиться на два участка. Первый участок LUK 814 можно генерировать путем заполнения индекса ключа первым значением для генерации первого заполненного индекса ключа (например, 1YHHHHCC80000000), и шифрования первого заполненного индекса ключа с использованием второго ключа 808 шифрования. Второй участок LUK 814 можно генерировать путем заполнения индекса ключа вторым значением для генерации второго заполненного индекса ключа (например, 2YHHHHCC80000000), и шифрования второго заполненного индекса ключа с использованием второго ключа 808 шифрования. Функция 812 шифрования, используемая для генерации LUK 814, может представлять собой, например, TDES или другие подходящие алгоритмы шифрования, и может использовать начальный вектор образования цепи, состоящий из двоичных нулей. Следует понимать, что описанные здесь числовые значения являются лишь примерами, и что в некоторых вариантах осуществления, можно использовать другие числовые значения.

[0180] После генерации LUK 814 (например, CBPP или эмитентом), LUK 814 и индекс ключа, который включает в себя информацию, относящуюся к генерации LUK 814 может поступать на портативное устройство связи для облегчения генерации криптограмм транзакций для транзакций, проведенных с использованием портативного устройства связи. LUK может быть связан с набором из одного или более порогов ограниченного использования, которые ограничивают количество транзакций, которые можно проводить с использованием LUK 814, например, описанных здесь. В ходе выполнения транзакции, криптограмма транзакции и/или индекс ключа могут передаваться от портативного устройства связи на устройство доступа, и транзакция может авторизоваться на основании проверки криптограммы транзакции и в зависимости от того, превысил ли LUK 814, используемый для генерации криптограммы транзакции, один или более из порогов ограниченного использования LUK.

[0181] Как рассмотрено выше, в некоторых вариантах осуществления, два типа криптограмм транзакций можно генерировать. Для транзакции на основе магнитной полоски, криптограмма 828 транзакции может быть криптограммой транзакции уменьшенной длины (также можно именовать преобразованной в десятеричную систему криптограмму транзакции). Криптограмму 828 транзакции можно генерировать путем шифрования статических данных 822 (например, она может представлять собой заранее определенную числовую строку, например ‘0000000000000001’) с использованием LUK 814 в качестве ключа шифрования в функции 824 шифрования для формирования зашифрованных статических данных или зашифрованной числовой строки, представленной в шестнадцатеричной системе счисления (0-F). Функция 824 шифрования может представлять собой, например, TDES или другие подходящие алгоритмы шифрования, и может использовать начальный вектор образования цепи, состоящий из двоичных нулей. Затем зашифрованные статические данные (или зашифрованная числовая строка) можно преобразовывать в десятеричную систему с использованием функции 826 перевода в десятеричную систему счисления для генерации криптограммы 828 транзакции.

[0182] В некоторых вариантах осуществления, криптограмма 828 транзакции может делиться на два блока данных. Функция 826 перевода в десятеричную систему счисления, используемая для генерации двух блоков данных криптограммы 828 транзакции, может включать в себя извлечение десятеричных цифр (0-9) из зашифрованных статических данных или зашифрованной числовой строки для формирования первого блока данных; и для второго блока данных, извлечение шестнадцатеричных цифр (A-F) из зашифрованных статических данных или зашифрованной числовой строки, и преобразование каждой извлеченной шестнадцатеричной цифры в десятеричную цифру путем вычитания десяти из соответствующей шестнадцатеричной цифры для формирования второго блока данных. Затем первый блок данных сцепляется со вторым блоком данных для формирования криптограммы 828 транзакции. В некоторых вариантах осуществления, преобразованная в десятеричную систему криптограмма 828 транзакции может иметь шесть цифр, и может внедряться с индексом ключа (например, ‘YHHHHCC’) в эквивалентные данные дорожки-2 для обеспечения сообщения запроса авторизации транзакции для запрашивания авторизации для транзакции от эмитента.

[0183] Для транзакции на основе интегральной микросхемы, криптограмму 820 транзакции можно генерировать путем шифрования динамических данных 816 транзакции с использованием LUK 814 в качестве ключа шифрования в функции 818 шифрования. Динамические данные 816 транзакции могут включать в себя, например, некоторые или все из данных 310 транзакции с помощью терминала, обеспечиваемых устройством доступа мобильному приложению портативного устройства связи в ходе выполнения транзакции. В некоторых вариантах осуществления, динамические данные 816 транзакции могут включать в себя следующие элементы данных: санкционированную сумму, другую сумму, код страны терминала, результаты проверки терминала, код валюты транзакции, дату транзакции, тип транзакции, и непредсказуемое число; и/или может включать в себя профиль смены приложений (AIP), счетчик транзакций с помощью приложения (ATC), и данные приложения эмитента (IAD). В некоторых вариантах осуществления, некоторые элементы данных могут быть опущены, и/или дополнительные элементы данных, конкретно не описанные, могут быть включены. Набор данных, который образует динамические данные 816 транзакции, обеспечивается в качестве входа функции 818 шифрования. В некоторых вариантах осуществления, криптограмму 820 транзакции можно генерировать путем шифрования динамических данных 816 транзакции с использованием первого участка LUK 814, дешифрования зашифрованных динамических данных транзакции с использованием второго участка LUK 814, и затем повторного шифрования дешифрованных динамических данных транзакции с использованием первого участка LUK 814.

[0184] Следует отметить, что согласно некоторым вариантам осуществления, помимо криптограммы 820 транзакции, преобразованную в десятеричную систему криптограмму 828 транзакции также можно использовать и генерировать в транзакции на основе интегральной микросхемы, и преобразованную в десятеричную систему криптограмму 828 транзакции можно вставлять в эквивалентные данные дорожки-2.

[0185] Фиг. 9 демонстрирует блок-схему иллюстративной функции 900 шифрования, согласно некоторым вариантам осуществления. В некоторых вариантах осуществления, функцию 900 шифрования можно использовать в качестве функции 818 шифрования. Например, набор данных, который образует динамические данные 816 транзакции, может быть сцеплен воедино (например, в вышеописанном порядке), и затем разделен на набор блоков данных D₁ - D_N равной длины (например, 8-байтовых блоков данных). Если динамические данные 816 транзакции не делятся на блоки данных равной длины, пропущенные младшие биты в последнем блоке данных D_N могут быть заполнены нулями. Первый ключ KA может соответствовать первому участку LUK 814 (например, 8 старшим байтам), и второй ключ KB может соответствовать второму участку LUK 814 (например, 8 младшим байтам) Итерационный процесс шифрования можно применять к набору блоков данных D₁ - D_N. Итерационный процесс шифрования может включать в себя шифрование первого блока данных D₁ с использованием ключа KA в качестве ключа шифрования в алгоритме шифрования данных (DEA(e)). Затем результат шифрования подвергается операции исключающего ИЛИ со следующим блоком данных D₂. Затем результат операции исключающего ИЛИ используется в качестве входа для следующей итерации процесса шифрования. Процесс шифрования продолжается, пока не будут обработаны все блоки данных D₁ - D_N, и выход I_N последней операции исключающего ИЛИ с последним блоком данных D_N шифруется для формирования выхода итерационного процесса шифрования O_N. Затем выход итерационного процесса шифрования O_N можно дешифровать с использованием ключа KB в качестве ключа дешифрования в алгоритме дешифрования данных (DEA(d)). Затем выход процесса дешифрования O_N+1 повторно шифруется с использованием ключа KA в качестве ключа шифрования в алгоритме шифрования данных (DEA(e)) для генерации выхода O_N+2. Согласно некоторым вариантам осуществления, выход O_N+2 можно использовать в качестве криптограммы 820 транзакции.

[0186] Следует отметить, что в некоторых вариантах осуществления, функцию 900 шифрования, описанную со ссылкой на фиг. 9, можно использовать для генерации кода аутентификации, который используется в процессе постплатежной проверки и/или процессе пополнения параметров счета, например, путем применения функции 900 шифрования к, по меньшей мере, журналу проверки транзакции, хранящемуся на портативном устройстве связи. В некоторых вариантах осуществления, функцию 900 шифрования, описанную со ссылкой на фиг. 9, также можно использовать для любой из функций 806, 812, 818 и/или 824 шифрования.

[0187] VIII. Иллюстративные способы

[0188] Фиг. 10 демонстрирует блок-схему операций иллюстративного способа 1000 улучшения защиты устройства связи (например, портативного устройства связи) при проведении транзакции с использованием устройства связи, согласно некоторым вариантам осуществления. Процесс 1000 может осуществляться, например, мобильным приложением, выполняющимся на портативном устройстве связи, и может осуществляться без использования защитного элемента (хотя можно использовать защитный элемент в некоторых вариантах осуществления).

[0189] На блоке 1002, устройство связи может принимать ключ ограниченного использования (LUK), который связан с набором из одного или более порогов ограниченного использования, который ограничивает использование LUK. LUK может приниматься от удаленного компьютера (например, удаленного компьютера, связанного с MAP, CBPP или эмитента/базовой системы). В некоторых вариантах осуществления, набор из одного или более порогов ограниченного использования может включать в себя, по меньшей мере, одно из времени существования, указывающего продолжительность времени, в течение которого LUK действителен, заранее определенного количества транзакций, на протяжении которых LUK действителен, и/или совокупной суммы транзакции, указывающей итоговую сумму транзакции, для которой LUK действителен. В некоторых вариантах осуществления, набор из одного или более порогов ограниченного использования может включать в себя порог международного использования и порог внутреннего использования.

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

[0191] На блоке 1004, транзакция (например, платежная транзакция, транзакция доступа или другая транзакция, которая осуществляется с использованием счета) может инициироваться, например, путем размещения устройства связи вблизи бесконтактного устройства чтения устройства доступа, например, терминала POS. На блоке 1006, устройство связи может генерировать криптограмму транзакции с использованием LUK. На блоке 1008, устройство связи может отправлять криптограмму транзакции на устройство доступа для проведения транзакции. В некоторых вариантах осуществления, устройство связи также может отправлять обозначение (например, заместитель для идентификатора счета) вместо реального идентификатора счета на устройство доступа для проведения транзакции. В некоторых вариантах осуществления, процесс 1000 не использует защитный элемент для хранения обозначения или LUK в устройстве связи. Транзакция может авторизоваться на основании, по меньшей мере, того, превысило ли использование LUK набор из одного или более порогов ограниченного использования и/или проверки криптограммы транзакции.

[0192] На блоке 1010, после проведения транзакции, процесс 1000 может определять, исчерпан или превышен ли (или близок к истощению или превышению) набор из одного или более порогов ограниченного использования, связанный с LUK. Если определено, что набор из одного или более порогов ограниченного использования, связанный с LUK, не был истощен или превышен (или не близок к истощению или превышению), процесс 1000 может переходить к блоку 1004 для проведения другой транзакции.

[0193] Если определено, что набор из одного или более порогов ограниченного использования, связанный с LUK, исчерпан или превышен (или близок к истощению или превышению), устройство связи может отправлять на удаленный компьютер запрос пополнения для нового LUK на блоке 1012. Запрос пополнения может отправляться в ответ определение, что набор из одного или более порогов ограниченного использования, связанный с LUK, исчерпан, или в ответ на определение, что следующая транзакция, проведенная с помощью LUK, исчерпает набор из одного или более порогов ограниченного использования. В некоторых вариантах осуществления, запрос пополнения может отправляться в ответ на прием сообщения проталкивания, запрашивающего устройство связи пополнить LUK.

[0194] Запрос пополнения может включать в себя информацию журнала транзакций, выведенную из журнала транзакций (например, журнала проверки транзакции), хранящегося на устройстве связи. В некоторых вариантах осуществления, журнал транзакций, хранящийся на устройстве связи, может включать в себя, для каждой транзакции, проведенной с использованием LUK, метку времени транзакции, указывающую время соответствующей транзакции, значение счетчика транзакций с помощью приложения, связанное с соответствующей транзакцией, и/или указатель типа транзакции, указывающий, является ли соответствующая транзакция транзакцией на основе магнитной полоски или транзакцией на основе интегральной микросхемы. В некоторых вариантах осуществления, информация журнала транзакций, отправленная на удаленный сервер или компьютер, может включать в себя код аутентификации, вычисленный, по меньшей мере, по журналу транзакций с использованием LUK. Если информация журнала транзакций в запросе пополнения совпадает с информацией журнала транзакций на удаленном компьютере, процесс 1000 может переходить к блоку 1002, и устройство связи может принимать новый LUK и новый индекс ключа, связанный с новым LUK.

[0195] Фиг. 11 демонстрирует блок-схему операций иллюстративного способа 1100 улучшения защиты устройства связи при проведении транзакции с использованием устройства связи, согласно некоторым вариантам осуществления. Процесс 1100 может осуществляться, например, компьютером, связанным с CBPP или эмитентом.

[0196] На блоке 1102, информация счета, связанная со счетом, шифруется с использованием первого ключа шифрования для генерации второго ключа шифрования. В некоторых вариантах осуществления, информация счета может включать в себя идентификатор счета, например PAN, альтернативный идентификатор счета, например альтернативный PAN, или обозначение, которое является заместителем для идентификатора счета. В некоторых вариантах осуществления, первым ключом шифрования может быть главный ключ вывода, связанный с эмитентом счета. Согласно некоторым вариантам осуществления, шифрование информации счета для генерации второго ключа шифрования может включать в себя шифрование информации счета с использованием первого ключа шифрования для генерации первого участка второго ключа шифрования, инвертирование информации счета, и шифрование инвертированной информации счета с использованием первого ключа шифрования для генерации второго участка второго ключа шифрования. В некоторых вариантах осуществления, вторым ключом шифрования может быть уникальный ключ вывода для счета

[0197] На блоке 1104, информация индекса ключа шифруется с использованием второго ключа шифрования для генерации ключа ограниченного использования (LUK). Информация индекса ключа может включать в себя индекс ключа, имеющий информацию, относящуюся к генерации LUK. Например, информация индекса ключа может включать в себя значение счетчика, указывающее, сколько раз LUK был обновлен или пополнен в заранее определенный период времени и/или информацию времени, указывающую, когда сгенерирован LUK. В некоторых вариантах осуществления, шифрование информации индекса ключа для генерации LUK может включать в себя заполнение индекса ключа первым значением для генерации первой информации заполненного индекса ключа и шифрования первой информации заполненного индекса ключа для генерации первого участка LUK. Шифрование информации индекса ключа для генерации LUK также может включать в себя заполнение индекса ключа вторым значением для генерации второй информации заполненного индекса ключа и шифрование второй информации заполненного индекса ключа для генерации второго участка LUK.

[0198] На блоке 1106, процесс 1100 связывает LUK с набором из одного или более порогов ограниченного использования, который ограничивает использование LUK. На блоке 1108, LUK и индекс ключа обеспечиваются устройству связи (например, портативному устройству связи) для облегчения генерации криптограммы транзакции для транзакции, проведенной с использованием устройства связи. Транзакция может авторизоваться на основании LUK и криптограммы транзакции (например, превысило ли использование LUK набор из одного или более порогов ограниченного использования и/или проверки криптограммы транзакции).

[0199] В некоторых вариантах осуществления, когда транзакция является транзакцией на основе интегральной микросхемы, криптограмму транзакции можно генерировать путем шифрования информации о транзакции (например, динамической информации о транзакции, например, данных транзакции с помощью терминала, принятых от устройства доступа в ходе транзакции) с использованием первого участка LUK, дешифрования зашифрованной информации о транзакции с использованием второго участка LUK и повторного шифрования дешифрованный информация о транзакции с использованием первого участка LUK.

[0200] Когда транзакция является транзакцией на основе магнитной полоски, криптограмму транзакции можно генерировать путем шифрования заранее определенной числовой строки с использованием LUK и преобразования зашифрованной заранее определенной числовой строки в десятеричную систему счисления. В некоторых вариантах осуществления, преобразование зашифрованной заранее определенной числовой строки в десятеричную систему счисления может включать в себя извлечение десятеричных цифр из зашифрованной заранее определенной числовой строки для формирования первого блока данных, извлечение шестнадцатеричных цифр из зашифрованной заранее определенной числовой строки и преобразование каждой извлеченной шестнадцатеричной цифры в десятеричную цифру для формирования второго блока данных и конкатенацию первого блока данных и второго блока данных для формирования криптограммы транзакции. Криптограмма транзакции и/или индекс ключа могут быть внедрены в эквивалентные данные дорожки-2 сообщения запроса авторизации.

[0201] IX. Платформа облачных платежей (CBPP)

[0202] В этом разделе более подробно описаны некоторые функции, которые могут осуществляться платформой облачных платежей (CBPP) (например, CBPP 180). В некоторых вариантах осуществления, эти функции могут включать в себя управление ключами, управление активным счетом и пополнение параметров счета, платеж и обработка платежной транзакции, проверку платежа, предоставление, управление жизненным циклом и постплатежную проверку. Связь между CBPP и платформой мобильного приложения (MAP) можно устанавливать с использованием защищенных каналов, например, отвечающих протоколу защиты транспортного уровня (TLS), протоколу защищенных сокетов (SSL) с привязкой по времени или протоколу защищенной передачи гипертекста (HTTPS). Связь между CBPP и эмитентом/базовой системой можно устанавливать с использованием защищенных каналов, отвечающих требованиям защиты эмитента.

[0203] Управление ключами

[0204] Эмитент счета может использовать особый набор ключей (например, MDK) в диапазоне идентификационных номеров банка (BIN) или в диапазоне первичных номеров счета (PAN) для облачных платежных транзакций во избежание ситуаций, когда одни и те же ключи используются как для транзакций на основе защитного элемента, так и облачных транзакций. MDK можно использовать в качестве основного ключа для генерации LUK, которые обеспечиваются портативному устройству связи. В некоторых вариантах осуществления, CBPP может обеспечивать свой собственный набор ключей MDK эмитента (предназначенных для облачной среды), которые хранятся в ее собственных аппаратных защитных модулях. В некоторых вариантах осуществления, вместо использования своего собственного набора MDK для генерации LUK, CBPP может обращаться к эмитенту/базовой системе для извлечения LUK, хранящихся в аппаратных защитных модулях эмитента/базовой системы.

[0205] Управление активным счетом и пополнение параметров счета

[0206] Описанные здесь способы облачных платежей не требуют использования защитного элемента для безопасного хранения данных, например уникального выведенного ключа (UDK). Таким образом, портативное устройство связи может не иметь доступа ко всем возможностям, связанным с защитным элементом, например, возможности генерации криптограммы приложения (AC) для транзакций с использованием только безопасно хранящейся информации. Для снижения риска компрометации параметров счета, параметры счета ограниченного использования могут периодически генерироваться CBPP и пополняться в мобильном приложении портативного устройства связи, а также обновляться на эмитенте/базовой системе для поддержания счета в активном состоянии.

[0207] Для инициирования процесса управления активным счетом, CBPP может принимать запрос на генерацию параметров счета от MAP или эмитента/базовой системы. Например, MAP может запрашивать новый набор параметров счета, например, ключ ограниченного использования и соответствующий индекс ключа у CBPP в ответ на запрос обновления данных параметров счета от мобильного приложения. В порядке другого примера, эмитент/базовая система может проверять, в ходе обработки транзакции, по-прежнему ли действителен текущий набор параметров счета (например, используемый с его порогами ограниченного использования, например, количеством разрешенных транзакций, временем существования и т.д.). В случае превышения порога для данной настройки рисков, эмитент/базовая система может предупреждать CBPP о необходимости обновления нового набора параметров счета в мобильном приложении.

[0208] В ответ на запрос, CBPP может генерировать набор данных, относящихся к счету. Данные, относящиеся к счету, могут включать в себя полустатическую информацию счета и динамические параметры счета, которые изменяется с каждым пополнением, например LUK, который может использоваться мобильным приложением для генерации криптограммы транзакции (например, криптограммы приложения (AC)), когда портативное устройство связи представляется бесконтактному устройству чтения устройства доступа. Параметры счета могут зависеть от конкретного счета (например, разные параметры счета для разных счетов пользователя), зависеть от конкретного портативного устройства связи (например, разные параметры счета для разных портативных устройств связи пользователя, даже при одном и том же базовом счете), и/или зависеть от конкретного мобильного приложения (например, разные параметры счета для разных мобильных приложений, даже когда разные мобильные приложения установлены на одном и том же портативном устройстве связи).

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

[0210] В некоторых вариантах осуществления, эмитент/базовая система может реализовывать свой собственный набор пределов риска или порогов ограниченного использования, который применяется для каждого счета, чтобы обобщенно рассматривать все транзакции, осуществляемые по счету, поскольку один и тот же счет может предоставляться в разных мобильных приложениях, которые могут иметь свои собственные пределы риска, тогда как все транзакции, проведенные разными мобильными приложениями с использованием этого счета, могут авторизоваться одним и тем же эмитентом/базовой системой. Параметры управления рисками могут заранее задаваться на мобильном приложении и на эмитенте/базовой системе, или могут управляться отдельно другими системами, таким образом, что CBPP может не требоваться генерировать их. Набор данных, относящихся к счету, также может включать в себя параметры управления порогами устройства, которые используются для запуска обновления параметров счета в мобильном приложении, а также, по возможности, для обновления параметров управления рисками на эмитенте/базовой системе.

[0211] Мобильное приложение может хранить или принимать из облака несколько параметров управления рисками (например, пороги ограниченного использования), которые запускают обновление текущего набора параметров счета. Когда параметры счета близки к моменту устаревания (например, когда известно, что следующая транзакция, проведенная с помощью LUK, исчерпает набор из одного или более порогов ограниченного использования), мобильное приложение может запрашивать обновление у CBPP через MAP для пополнения параметров счета. параметры управления порогами устройства, отслеживаемые мобильным приложением, могут включать в себя, например, количество транзакций с данным набором параметров счета, которые могут осуществляться до того, как параметры счета нужно будет обновить (например, пять транзакций). Мобильное приложение может отправлять предупреждение на платформу мобильного кошелька до того, как этот лимит будет превышен, чтобы портативное устройство связи можно было использовать для одной или более транзакций до того, как они начнут отклоняться (например, предупреждение можно отправлять после четырех транзакций, чтобы портативное устройство связи можно было использовать для еще одной транзакции). Поэтому, если параметры счета действительны для заранее заданного числа транзакций в параметрах управления рисками CBPP, то число транзакций для параметров управления порогами на устройстве, управляемом мобильным приложением, можно конфигурировать с порогом, более низким, чем значение в CBPP для запуска пополнения.

[0212] Параметры управления порогами устройства также могут включать в себя время существования для данного набора параметров счета до того, как их потребуется обновить (например, пять дней). Мобильное приложение 114 может извещать платформу мобильного кошелька до того, как этот лимит будет истощен, для запрашивания нового набора параметров счета (например, четыре дня спустя). Поэтому, если параметры счета имеют время окончания срока действия в CBPP, то значение времени существования для параметров управления порогами на устройстве, управляемом мобильным приложением, можно конфигурировать с порогом до этого указанного времени в CBPP для запуска пополнения. В некоторых вариантах осуществления, параметры управления порогами устройства также могут включать в себя, но без ограничения: используемую сумму транзакции, чтобы мобильное приложение принимало решение, следует ли обновить параметры счета (например, меньшие суммы транзакции могут не требовать немедленного обновления параметров счета); совокупную сумму транзакции в качестве триггера для обновления параметров счета на основании суммы сумм отдельных транзакций; и/или настройки внутренних и международных рисков для более частого запуска обновлений для международных транзакций в случае, когда они считаются более рискованными.

[0213] Поскольку параметры счета предназначены для ограниченного использования, дополнительные параметры управления рисками, относящиеся к облачной среде, могут реализоваться и осуществляться эмитентом/базовой системой. Эти параметры управления рисками либо могут обеспечиваться эмитенту/базовой системе CBPP в процессе управления активным счетом, либо могут задаваться и управляться отдельно. Например, эмитент/базовая система может проверять, что текущий набор параметров счета (например, LUK и соответствующий индекс ключа) можно использовать только ограниченное число раз (например, пять раз) прежде чем эмитент/базовая система выдаст предупреждение для запрашивания у CBPP генерации нового набора параметров счета, подлежащего пополнению в мобильном приложении. Эмитент/базовая система также может проверять, что текущий набор параметров счета можно использовать только в течение ограниченного периода времени (например, пять дней) прежде чем CBPP потребуется сгенерировать новый набор параметров счета и отправить на мобильное приложение.

[0214] Дополнительные параметры управления рисками проверяет, например, суммы отдельных транзакций, и эмитент/базовая система также может осуществлять совокупные итоговые суммы транзакции. Например, меньшие суммы транзакции могут не требовать немедленного обновления параметров счета, тогда как транзакции высокого значения могут чаще требовать обновлений. В порядке другого примера, когда совокупная итоговая сумма транзакции на основании превышения суммы сумм отдельных транзакций, эмитент/базовая система может извещать CBPP о том, что новый набор параметров счета необходимо генерировать и пополнять в мобильном приложении. Настройки внутренних и международных рисков также можно проверять для более частого запуска обновлений для международных транзакций в случае, когда они считаются более рискованными.

[0215] После того, как CBPP принимает запрос обновления параметров счета либо от MAP, либо от эмитента/базовой системы, CBPP, может осуществляться генерация данных для данного счета. CBPP может использовать свой собственный набор ключей MDK эмитента (предназначенных для облачной среды), который она сохраняет в своих собственных аппаратных защитных модулях, и генерировать LUK, выведенный из MDK с использованием вновь сгенерированного индекса ключа, или CBPP может извлекать LUK, выведенный из MDK с использованием вновь сгенерированного индекса ключа из аппаратных защитных модулей эмитента/базовой системы.

[0216] После генерации или иного извлечения нового набора параметров счета, CBPP может отправлять параметры счета на запросившие их субъекты. MAP может принимать новый набор параметров счета и параметры управления порогами устройства, и дополнительно отправлять его на мобильное приложение. В некоторых вариантах осуществления, набор параметров рисков или порогов ограниченного использования для данного счета может изменяться в течение времени, и новый набор параметров счета может иметь другие пороги, чем предыдущий набор параметров счета. Пределы порогов могут изменяться, например, на основании привычных трат покупателя, или если покупатель путешествует за границей. Эмитент/базовая система также может принимать новый набор параметров счета от CBPP. В некоторых вариантах осуществления, CBPP может быть отключена от эмитента/базовой системы или может не быть подключена в реальном времени. В этом случае, эмитент/базовая система может использовать метку времени в сообщении авторизации для определения, когда были сгенерированы данные. В частности, можно генерировать индекс ключа, содержащий указание даты генерирования параметров счета.

[0217] После того, как MAP и эмитент/базовая система принимают новый набор параметров счета и параметры управления порогами устройства от CBPP, они может осуществлять определенные действия. MAP может доставлять и применять новый набор параметров счета на мобильное приложение по сети связи. После пополнения набора параметров счета в мобильном приложении, старый набор набора параметров счета устаревает и подлежит удалению из мобильного приложения. Если MAP не способна сразу связаться с мобильным приложением, она может продолжать пытаться делать это, пока не установит связь с мобильным приложением; в противном случае эмитент/базовая система может начать отклонять транзакции, которые осуществляются со старым набором параметров счета с этого момента времени. В некоторых вариантах осуществления, MAP может принимать от мобильного приложения подтверждение обновления параметров счета для извещения эмитента/базовой системы о начале использования нового набора параметров счета. Эмитент/базовая система, получив обновление, также может обновлять параметры управления рисками для данного набора параметров счета. В случае, когда эмитент/базовая система принимает обновление от CBPP напрямую в реальном времени или с определенной задержкой, она может обновлять параметры управления рисками для нового набора параметров счета, например, если эмитент/базовая система принимает от CBPP подтверждение, что новый набор данных успешно применен к мобильному приложению. В случае, когда эмитент/базовая система не принимает обновление напрямую от CBPP, эмитент/базовая система может принимать новый набор параметров счета в первой транзакции, проведенной с портативным устройством связи после обновления. В этот момент, система авторизации обработки может активировать новые параметры управления рисками для нового набора параметров счета и применять другую политику или выводить из употребления старый набор параметров счета.

[0218] Эмитент/базовая система может действовать синхронно с CBPP и, следовательно, с MAP, чтобы гарантировать, что процесс обработки данных транзакции синхронизирован с процессом генерации параметров счета. Система генерации данных и главная система обработки данных также могут использовать алгоритмы, метки времени и другие механизмы, чтобы гарантировать, что данные на эмитенте/базовой системе и мобильном приложении являются согласованными, обновленными и подчиняющимися одной и той же модели рисков.

[0219] Платеж и обработка платежной транзакции

[0220] Когда платежная транзакция инициируется на устройстве доступа и затем обрабатывается системой авторизации обработки, мобильное приложение и эмитент/базовая система может предпринимать дополнительные действия для обработки облачной транзакции. Когда происходит платежная транзакция, и портативное устройство связи и бесконтактное устройство чтения обмениваются данными, мобильное приложение может использовать LUK или совместно с его соответствующим индексом ключа, хранящимся в мобильном приложении, для генерации криптограммы транзакции (например, криптограммы приложения (AC)). С точки зрения устройства чтения, транзакция может иметь вид стандартной бесконтактной транзакции. Для транзакции на основе интегральной микросхемы, устройство доступа может обеспечивать непредсказуемое число (UN), которое используется для генерации криптограммы транзакции. Для транзакции на основе магнитной полоски, криптограмма транзакции может генерироваться мобильным приложением без использования входа от устройства доступа. В некоторых вариантах осуществления, динамическое значение проверки карты (dCVV) могут быть опущено.

[0221] После того, как мобильное приложение отправляет криптограмму транзакции и другие данные транзакции на устройство доступа, мобильное приложение может проверять, что параметры счета все еще действительны, путем проверки параметров управления порогами на устройстве (например, порогов ограниченного использования на устройстве). Мобильное приложение может предупреждать MAP о превышении параметров управления порогами устройства, и запрашивать у CBPP новый набор параметров счета. Мобильное приложение может проверять, что даже если параметры счета не были обновлены в мобильном приложении, старый набор параметров счета все еще можно использовать в последующих транзакциях, чтобы эмитент/базовая система мог/ла принимать решение по авторизации и рискам.

[0222] После того, как происходит взаимодействие между мобильным приложением и устройством доступа, торговец и приобретатель передают данные транзакции эмитенту/базовой системе. Когда эмитент/базовая система принимает данные транзакции в сообщении запроса авторизации, эмитент/базовая система может удостоверять криптограмму транзакции и другие данные транзакции, преобразовывать, при необходимости, альтернативный идентификатор счета или назначенный обозначение в реальный идентификатор счета (например, реальный PAN), осуществлять проверку параметра риска и проверять, находится ли счет в нормальном состоянии. Эмитент/базовая система может проверять, что данные, в частности, криптограмма транзакции и индекс ключа, все еще действительны для данного счета путем проверки параметры управления рисками. CBPP может изменяться в случае превышения параметров управления рисками и запрашивать пополнение нового набора параметров счета из CBPP в мобильном приложении через MAP. Даже если параметры счета не были обновлены в мобильном приложении, эмитент/базовая система может проверять, что старый набор параметров счета все еще можно использовать в последующих транзакциях в случае, когда эмитент допускает, что этот риск приемлем для данного счета, диапазона BIN или PAN или конкретной среды транзакции (например, внутренней или международной).

[0223] Хотя параметры счета могут быть превышены с точки зрения эмитента/базовой системы, поскольку они не были обновлены в мобильном приложении, эмитент/базовая система может разрешать транзакцию и обеспечивать некоторый уровень допуска. CBPP может быть извещена о том, что эмитент/базовая система может начать отклонять дальнейшие транзакции, если параметры счета не обновлены в мобильном приложении. Пороги устанавливаются для каждого из параметров управления рисками на эмитенте/базовой системе, например, количества транзакций и времени существования, которые позволяют заранее извещать CBPP до превышения фактических параметров управления рисками. Это может давать CBPP дополнительное время для генерации нового набора параметров счета и позволять MAP пополнять параметры счета в мобильном приложении.

[0224] Проверка платежа

[0225] Для проведения транзакции, покупатель может активировать портативное устройство связи до представления портативного устройства связи бесконтактному устройству чтения для продолжения транзакции. В некоторых вариантах осуществления, активация портативного устройства связи может предусматривать, что покупатель вводит входной сигнал для метода проверки держателя карты с покупательским устройством (CDCVM) на пользовательском интерфейсе портативного устройства связи. В зависимости от конфигурации мобильное приложение, CDCVM может осуществляться на уровне устройства (например, блокировка экрана) или на уровне мобильного приложения (например, пароль/код-пропуск приложения). Мобильное приложение может быть настроено для использования CDCVM в каждой транзакции или в каждой транзакции свыше определенной суммы транзакции. Если мобильное приложение сконфигурирован для использования CDCVM, покупателю можно предлагать ввести входной сигнал, соответствующий CDCVM, для аутентификации до или в ходе мобильной платежной транзакции. Если CDCVM используется в транзакции, и CDCVM был получен до представления портативного устройства связи бесконтактному устройству чтения, транзакция может переходить к завершению. Если CDCVM используется в транзакции, и CDCVM не был получен до представления портативного устройства связи бесконтактному устройству чтения, процесс транзакции может зависеть от версии устройства доступа торговца.

[0226] CBPP может обеспечивать набор функций, где эмитент может устанавливать CDCVM, и эта информация конфигурации CDCVM (например, блокировка экрана, код-пропуск, и т.д.) предоставляется мобильному приложению. CBPP может поддерживать требования к CDCVM эмитента и позволять эмитенту конфигурировать данные CDCVM в данных предоставления. В некоторых вариантах осуществления, эмитент/базовая система может определять, введен ли входной сигнал, соответствующий CDCVM. Когда входной сигнал, соответствующий CDCVM, захватывается устройством, результат может передаваться эмитенту/базовой системе в сообщении авторизации для обработки транзакции.

[0227] Предоставление

[0228] CBPP может обеспечивать набор функций предоставления, которые позволяют отправлять данные облачного счета на MAP. CBPP может управлять данными для каждого облачного счета и гарантировать, что данные отправляются на MAP по запросу. CBPP может осуществлять подготовку данных до отправки на MAP и поддерживать функцию предоставления, где эмитент может инициировать запрос пополнения или обновления данных облачного счета. CBPP может обеспечивать функцию предоставления для предоставления данных параметров счета MAP для каждого держателя счета, и подготавливать и упаковывать данные до отправки на MAP. Например, CBPP может обеспечивать функцию для предоставления участка полустатических данных (например, идентификатора счета или обозначение) и участка динамических данных (например, LUK и индекса ключа) MAP. CBPP может поддерживать конечный автомат для каждого счета и обеспечивать функцию проталкивания или вытягивания на/от MAP для инициирования запроса предоставления/пополнения. CBPP может обеспечивать функцию пополнения для предоставления данных параметров счета MAP для каждого держателя счета. CBPP может обеспечивать функцию предоставления/пополнения с признаками проталкивания от эмитента. CBPP может обеспечивать функцию предоставления/пополнения, которая поддерживает единый счет, который может инициироваться MAP или эмитентом/базовой системой. В некоторых вариантах осуществления, CBPP может обеспечивать обновленные параметры счета как часть запроса предоставления/пополнения, только если он вызван мобильным приложением.

[0229] Управление жизненным циклом

[0230] Управление жизненным циклом является набором функций, которые осуществляют события жизненного цикла счета. CBPP может принимать и обрабатывать сообщения о событиях жизненный цикл от MAP или от эмитента/базовой системы. В ряде случаев, запрос жизненного цикла может инициироваться покупателем, как в случае удаления счета из мобильного приложения или блокировка счета от эмитента для обработки мошеннической активности. CBPP 180 может осуществлять функции управления жизненным циклом для каждого счета и обеспечивать события жизненного цикла счета, например, добавление, удаление, приостановку и возобновление приостановленных счетов. В некоторых вариантах осуществления, события жизненного цикла счета могут включать в себя замену или блокировку счета и/или управление потерянными или похищенными счетами. CBPP может обеспечивать интерфейс для MAP и/или эмитента/базовой системы для осуществления обновления жизненного цикла счета покупателя. Запрос может запускать предоставление или пополнение новых параметров счета. В некоторых вариантах осуществления, CBPP может действовать на событиях жизненного цикла, например, немедленно удалять или приостанавливать счета по такому запросу. CBPP может обеспечивать извещение обо всех событиях жизненного цикла системам, подвергнутых влиянию, например, эмитенту/базовой системе и MAP.

[0231] Постплатежная обработка

[0232] Постплатежная проверка может снижать риск фальсификации параметров счета. Она также может препятствовать раскрытию параметров счета, хранящихся на портативном устройстве связи, например эмитент/базовая система может осуществлять периодическую проверку, которая ограничивает раскрытие, связанное с параметрами счета, хранящимися на портативном устройстве связи. CBPP может задавать протокол для обмена сообщениями постплатежной проверки. Протокол постплатежной проверки может базироваться на интерфейсах реального времени и может подчиняться защите транспортного уровня (TLS). Эмитент/базовая система и/или CBPP может запускать обмен сообщениями постплатежной проверки. CBPP дает возможность эмитентам конфигурировать параметры постплатежной проверки, что запускает обмен сообщениями постплатежной проверки с CBPP. Например, эмитент может конфигурировать параметры таким образом, что CBPP запускает постплатежную проверку транзакций, превышающих порог (например, $100). Эмитент может конфигурировать параметры таким образом, что CBPP запускает постплатежную проверку при каждом обновлении параметров счета или после нескольких обновлений (например после пяти обновлений). В некоторых вариантах осуществления, эмитент может конфигурировать параметры таким образом, что эмитент/базовая система инициирует постплатежную проверку. В этом случае, CBPP облегчает обмен сообщениями между эмитентом/базовой системой и мобильным приложением.

[0233] В некоторых вариантах осуществления, CBPP может воздерживаться от совершения каких-либо действий на основании результатов проверки и, вместо этого, информировать эмитента/базовую систему о подозрительной активности. Эмитент/базовая система может принять решение о надлежащем действии на основании их процесса и профиля риска счета. CBPP может поддерживать постплатежную обработку с использованием журнала проверки транзакции для проверки, надлежащее ли устройство совершило платеж. CBPP может поддерживать постплатежную обработку с использованием журнала проверки транзакции для проверки, надлежащее ли устройство инициирует запрос для пополнения параметров счета, например, путем проверки, что журнал транзакций для данного набора параметров счета, хранящихся на портативном устройстве связи, согласуется с транзакциями на стороне эмитента/базовой системы. CBPP может обеспечивать возможность конфигурировать пороги для запуска сообщений постплатежной проверки от CBPP. CBPP может совершать действие управления жизненным циклом на основании результатов постплатежной проверки. Если проверка завершается неудачей, то CBPP может сообщать эмитенту/базовой системе о подозрительной активности. CBPP может обеспечивать дополнительную информацию, например, информацию местоположения о транзакции или уникальные идентификаторы устройств, в журнале проверки транзакции.

[0234] X. Платформа мобильного приложения (MAP)

[0235] В этом разделе более подробно описаны некоторые функции, которые могут осуществляться платформой мобильного приложения (MAP) (например, MAP 170). Согласно некоторым вариантам осуществления, MAP может управлять мобильным приложением и непосредственной связью между CBPP и мобильным приложением. MAP может поддерживать взаимодействия облачного платежа, например, регистрацию в службе облачных платежей, предоставление облачных платежных счетов, управление активным счетом (т.е., пополнение параметров счета, управление жизненным циклом счета и запросы журнала постплатежной проверки транзакции. MAP и CBPP могут осуществлять связь с использованием защищенного транспортного канала, например, SSL с привязкой по времени или HTTPS. MAP и CBPP могут обмениваться сообщения защищенных с использованием защиты веб-услуг (WSS).

[0236] Для осуществления связи с мобильным приложением, MAP может аутентифицировать пользователя, портативное устройство связи и/или мобильное приложение с использованием одно- или многофакторной аутентификации для установления защищенного канала между мобильным приложением и MAP. С этой целью, MAP может устанавливать счет с покупателем с уникальным именем пользователя и паролем. MAP может сохранять и проверять пароль. Покупатель может создавать свой сертификат мобильного приложения (имя пользователя/пароль) посредством процесса регистрации. В некоторых вариантах осуществления, эти имя пользователя и пароль могут отличаться или не отличаться от проверки портативного устройства связи или CDCVM.

[0237] Регистрация и предоставление счета

[0238] MAP может пересылать данные регистрации счета и покупателя, принятые от мобильного приложения, на CBPP или эмитенту/базовой системе для удостоверения запросов регистрации и осуществления процессов идентификации и проверки, заданных эмитентом. Эмитент может участвовать в процессе регистрации (например, эмитент принимает решение на прием/отклонение регистрации или дает право принимать решение третьей стороне в заранее заданных условиях). В обоих случаях, эмитент может руководствоваться критериями и, в частности, задавать способы проверки счета и способы аутентификации покупателя. MAP может поддерживать получение запроса регистрации и соответствующих данных регистрации из мобильного приложения.

[0239] MAP может маршрутизировать запрос регистрации и соответствующие данные на CBPP и/или эмитенту/базовой системе. После успешной регистрации, MAP может инициировать запрос предоставления с CBPP. В случае успешного предоставления посредством CBPP, MAP может принимать данные от CBPP для конфигурирования нового облачного платежного счета в мобильном приложении. MAP может принимать подтверждение предоставления или извещение о неудаче из мобильного приложения. MAP может маршрутизировать подтверждение или извещение о неудаче от мобильного приложения на CBPP и/или эмитенту/базовой системе. Если CBPP не удалось предоставление, MAP может принимать извещение о неудаче регистрации от CBPP, и MAP может маршрутизировать извещение о неудаче предоставления на мобильное приложение. Мобильное приложение может отображать соответствующее сообщение покупателю.

[0240] Управление активным счетом

[0241] Для снижения риска компрометации параметров счета, параметры счета периодически генерируются CBPP (или эмитентом/базовой системой) и пополняются в мобильном приложении, а также обновляются на эмитенте/базовой системе для поддержания счета в активном состоянии. Для инициирования процесса управления активным счетом, CBPP может принимать запрос пополнения для новых параметров счета из мобильного приложения через MAP. CBPP также может действовать по запросу пополнения, принятому от эмитента/базовой системы. MAP действует как посредник и маршрутизирует передачи на и от мобильного приложения и на и от CBPP для взаимодействий управления активным счетом.

[0242] В реализации вытягивания, MAP принимает запрос пополнения параметров счета от мобильного приложения. До инициирования обмена сообщениями запроса из мобильного приложения, MAP может устанавливать защищенный канал связи. После приема запроса пополнения, MAP пересылает сообщение запроса пополнения на CBPP. Обработав запрос пополнения, CBPP отправляет новые параметры счета на MAP, который затем пересылает их на мобильное приложение. При необходимости, MAP может повторно устанавливать защищенное соединение с мобильным приложением. Если MAP не удалось отправить ответ пополнения параметров счета от CBPP на мобильное приложение после заранее определенного числа попыток во временном окне, MAP может извещать CBPP о том, что попытка доставки пополнения параметров счета не увенчалась успехом.

[0243] В реализации проталкивания, CBPP (или эмитент/базовая система) инициирует процесс для обновления параметров счета. CBPP отправляет сообщение проталкивания на MAP для инициирования проталкивания пополнения. Затем MAP отправляет сообщение проталкивания на мобильное приложение. Затем мобильное приложение генерирует запрос пополнения параметров счета для каждого вышеописанного потока вытягивания. До инициирования обмена конфиденциальной информацией, MAP может осуществлять аутентификацию на уровне пользователя, портативного устройства связи и/или приложения в соответствии с требованиями защиты. Если MAP не удалось отправить ответ пополнения параметров счета от CBPP на мобильное приложение после заранее определенного числа попыток в указанном временном окне, MAP может извещать CBPP о том, что попытка пополнения параметров счета не увенчалась успехом.

[0244] После того, как мобильное приложение принимает и обрабатывает новый набор параметров счета из реализаций проталкивания или вытягивания, мобильное приложение может генерировать извещение статуса или подтверждения для MAP, который затем пересылает извещение статуса или подтверждения на CBPP.

[0245] Управление жизненным циклом

[0246] Когда покупатель инициирует удаление счета, MAP может облегчать обмен сообщением удаления из мобильного приложения на CBPP и эмитент/базовая система. MAP может удалять данные счета, связанные со счетом из своей базы данных, и пересылать сообщение удаления из мобильного приложения на CBPP.

[0247] Когда эмитент инициирует удаление счета, MAP может облегчать обмен сообщением удаления от CBPP или эмитента/базовой системы на мобильное приложение. Эмитент/базовая система может отправлять запрос удаления на CBPP или MAP. MAP может пересылать сообщение удаления от эмитента/базовой системы или CBPP на мобильное приложение. MAP может отправлять квитирование на CBPP или эмитенту/базовой системе после приема квитирования из мобильного приложения. MAP может гарантировать, что счет запрос удаления отправляется на надлежащее мобильное приложение, установленное на надлежащем портативном устройстве связи. MAP может удалять данные, связанные с удаленным счетом из своих записей, чтобы гарантировать, что ранее предоставленный счет для профиля мобильного приложения конкретного покупателя больше не является активным счетом облачных платежей.

[0248] Когда эмитент/базовая система или CBPP инициирует приостановку счета, MAP может облегчать обмен сообщением приостановки от CBPP или эмитента/базовой системы на мобильное приложение. Эмитент/базовая система может отправлять запрос приостановки на CBPP или MAP. MAP может пересылать сообщение приостановки от эмитента/базовой системы или CBPP на мобильное приложение. MAP может отправлять квитирование на CBPP или эмитенту/базовой системе после приема квитирования из мобильного приложения. MAP может гарантировать, что счет запрос приостановки отправляется на надлежащее мобильное приложение, установленное на надлежащем портативном устройстве связи.

[0249] Когда эмитент/базовая система или CBPP инициирует возобновление счета, MAP может облегчать обмен сообщением возобновления от CBPP или эмитента/базовой системы на мобильное приложение. Эмитент/базовая система может отправлять запрос возобновления на CBPP или напрямую на MAP. MAP может пересылать сообщение возобновления от эмитента/базовой системы или CBPP на мобильное приложение. MAP может отправлять квитирование на CBPP или эмитенту/базовой системе после приема квитирования из мобильного приложения. MAP может гарантировать, что запрос возобновления счета отправляется на надлежащее мобильное приложение, установленное на надлежащем портативном устройстве связи.

[0250] Постплатежная обработка

[0251] Постплатежные взаимодействия могут помогать эмитентам снижать риск компрометации параметров счета и, таким образом, могут помогать ограничивать раскрытие параметров счета, хранящихся на портативном устройстве связи. MAP может поддерживать получение информации, захваченной из журнала проверки транзакции на устройстве (например, соответствующей конкретному индексу ключа) в целях обеспечения правильности запросов пополнения параметров счета. Эмитент/базовая система, работающий/ая совместно с CBPP, имеет возможность инициирования запроса, через MAP, для данных журнала проверки транзакции, захваченных и сохраненных мобильным приложением. Мобильное приложение может отвечать, через MAP, на запрос запрашиваемыми данными журнала проверки транзакции. Затем эти данные могут проверяться эмитентом/базовой системой для подтверждения, исходила ли конкретная транзакция из запрошенного портативного устройства связи. Примеры элементов данных, которые можно использовать с этой целью, могут включать в себя, для каждой транзакции, проведенной с использованием набора параметров счета, время транзакции (например, время бесконтактного взаимодействия), счетчик транзакций с помощью приложения (ATC), который отсчитывает количество транзакций, проведенных из мобильного приложения, сумму транзакции и/или непредсказуемое число (UN) терминала, принятое от устройства доступа в ходе транзакции.

[0252] В целях использования журнала проверки транзакции для установления, проведена ли транзакция с определенного портативного устройства связи, MAP может принимать от CBPP запрос на данные журнала проверки транзакции с помощью мобильного приложения, поданный эмитентом/базовой системой. В целях использования журнала проверки транзакции для обеспечения CBPP некоторой гарантии, что запрос исходит от надлежащего портативного устройства связи, MAP может использовать информацию, обеспеченную из журнала проверки транзакции в запросах пополнения параметров счета от мобильного приложения. MAP может идентифицировать и аутентифицировать портативное устройство связи до передачи или приема сообщений постплатежного взаимодействия на и от мобильного приложения.

[0253] XI. Мобильное приложение

[0254] В этом разделе более подробно описаны некоторые функции, которые могут осуществляться портативным устройством связи и мобильным приложением, установленным на портативном устройстве связи, используемым для проведения облачных транзакций. Фиг. 12 демонстрирует подробную блок-схему портативного устройства 1201 связи, согласно некоторым вариантам осуществления. Портативное устройство 1201 связи может включать в себя оборудование 1204 устройства и память 1202. Оборудование 1204 устройства может включать в себя процессор 1205, подсистему 1209 связи, пользовательский интерфейс 1206, дисплей 1207 (который может входить в состав пользовательского интерфейса 1206) и бесконтактный интерфейс 1208. Процессор 1205 можно реализовать в виде одной или более интегральных схем (например, одного или более одноядерных или многоядерных микропроцессоров и/или микроконтроллеров), и использовать для управления работой портативного устройства 1201 связи. Процессор 1205 может выполнять различные программы в соответствии с программным кодом или машиночитаемым кодом, хранящимся в памяти 1202, и может поддерживать одновременное выполнение множественных программ или процессов. Подсистема 1209 связи может включать в себя один или более RF приемопередатчиков и/или соединителей, которые могут использоваться портативным устройством 1201 связи для подключения к внешним сетям (например, сети 192 связи) и осуществления связи с другими устройствами. Пользовательский интерфейс 1206 может включать в себя любую комбинацию элементов ввода и вывода, позволяющих пользователю взаимодействовать с функциями портативного устройства 1201 связи и вызывать их. В некоторых вариантах осуществления, дисплей 1207 может входить в состав пользовательского интерфейса 1206.

[0255] Бесконтактный интерфейс 1208 может включать в себя один или более RF приемопередатчиков для взаимодействия с бесконтактным устройством чтения устройства доступа. В реализациях на основе защитных элементов, только защитный элемент может иметь доступ к бесконтактному интерфейсу 1208. В описанных здесь способах облачных платежей, доступ к бесконтактному интерфейсу 1208 может осуществлять мобильная OS 1214 без участия пользователя защитного элемента. В некоторых вариантах осуществления, дисплей 1207 также может входить в состав бесконтактного интерфейса 1208, и использоваться, например, для осуществления транзакций с использованием QR-кодов, штрих-кодов, и т.д.

[0256] Память 1202 можно реализовать с использованием любой комбинации из любого количества энергонезависимых блоков памяти (например, флэш-памяти) и энергозависимых блоков памяти (например, DRAM, SRAM), или любого другого нетранзиторного носителя данных или их комбинации. В памяти 202 может храниться мобильная OS 1214 и среда 1210 мобильного приложения, где присутствует одно или более мобильных приложений, в том числе, мобильное приложение 1212 (например, приложение мобильного кошелька, приложение мобильных платежей и т.д.), выполняемых процессором 1205. Мобильная OS 1214 может реализовывать набор API 1216 эмуляции карты, которые мобильное приложение 1212 может вызывать для осуществления доступа к бесконтактному интерфейсу 208 для взаимодействия с устройством доступа.

[0257] Для реализаций облачных платежей, среда платежной системы (например, PPSE) и функции приложения мобильных платежей объединяются в мобильное приложение 1212, тогда как реализации на основе защитных элементов могут обеспечивать некоторые или все из этих функций из защитного элемента. Мобильное приложение 1212 может включать в себя логику 1250 облачных платежей. Логика 1250 облачных платежей может включать в себя логику 1258 бесконтактного платежа, логику 1256 среды системы ближнего бесконтактного платежа (PPSE), журнал 1254 проверки транзакции и пороги 1252 параметров счета (например, набор из одного или более порогов ограниченного использования, связанный с LUK 1242). Логика 1258 бесконтактного платежа может включать в себя функции, которые обеспечивают возможность осуществления бесконтактной связи для проведения бесконтактной транзакции с бесконтактным устройством чтения устройства доступа. Логика 1256 PPSE используется для информирования устройства доступа, какой платежный продукт доступен на мобильном приложении 1212. Затем устройство доступа использует эту информацию для выбора платежного счета для инициирования бесконтактной транзакции. Журнал 1254 проверки транзакции можно использовать для постплатежной поддержки. Мобильное приложение 1212 может поддерживать журнал 1254 проверки транзакции (может быть скрыт от покупателя), где хранятся детали транзакции для транзакций, инициированных из мобильного приложения 1212. Мобильное приложение 1212 также может использовать журнал 1254 проверки транзакции для поддержки процессов управления активным счетом и постплатежных взаимодействий. Пороги 1252 параметров счета (например, пороги ограниченного использования) первоначально сконфигурированы и могут потенциально обновляться с разными порогами для информирования мобильного приложения 1212, когда инициировать запрос обновленных параметров счета (например, времени существования, количества транзакций, совокупной суммы транзакции и т.д.).

[0258] Мобильное приложение 1212 также может включать в себя хранилище 1240 параметров счета и логику 1246 связи платформы мобильного приложения (MAP). В хранилище 1240 параметров счета хранятся параметры счета (например, идентификатор счета или альтернативный идентификатор счета или обозначение, LUK 1242, индекс ключа 1244, и т.д.), которые используются для инициирования облачной платежной транзакции. Логика 1246 MAP связи используется для обеспечения защищенной связи с платформой мобильного приложения (MAP) для запрашивания, отправления и приема информации для управления облачными платежными счетами пользователя. Она может включать в себя логику для потребления и обработки информации для логики 1230 управления счетом.

[0259] Логика 1230 управления счетом включает в себя логику для обработки информации для услуг облачных платежей, например, логику 1232 регистрации, логику 1233 предоставления, логику 1236 управления активным счетом, логику 1234 управления жизненным циклом и логика 1238 постплатежных взаимодействий. Логика 1232 регистрации включает в себя логику, позволяющую покупателю инициировать регистрацию счета в службе облачных платежей. Логика 1233 предоставления включает в себя логику для обработки данных эмитентом для конфигурирования счета в мобильном приложении 1212, включающую в себя предоставление начальных параметров счета. Логика 1236 управления активным счетом можно использовать для инициирования запроса с MAP для обновления параметров счета в случае превышения порогов параметров счета. Логика 1234 управления жизненным циклом может включать в себя логику для инициирования и обработки событий жизненного цикла счета, например, удаления, инициируемого покупателем, удаления, инициируемого эмитентом, приостановки, инициируемой эмитентом, и/или возобновления, инициируемого эмитентом, и т.д. Логика 1238 постплатежных взаимодействий используется для поддержки проверки платежа. Логика 1238 постплатежных взаимодействий может включать в себя логику для приема от MAP и ответа на запросы на журнал 1254 проверки транзакции. Логику постплатежных взаимодействий 238 также можно использовать для поддержки пополнения параметров счета, и может включать в себя логику для извлечения необходимой информации из журнала 1254 проверки транзакции для отправки на MAP как часть запроса пополнения параметров счета.

[0260] Мобильное приложение 1212 также может включать в себя признаки 1220 мобильного приложения. Признаки 1220 мобильного приложения может включать в себя логику 1224 методов проверки покупателя (CVM), режимы 1222 платежа и пользовательские настройки 1226. Логика 1224 CVM может включать в себя логику, необходимую для подтверждения кода-пропуска мобильного приложения, или метод проверки на устройстве (например, блокировка экрана) или другой способ проверки информации, поддерживаемый мобильным приложением 1212. Режимы 1222 платежа могут включать в себя логику для поддержки различных способов настройки мобильного приложения 1212 и портативного устройства 1201 связи для обеспечения готовности к инициированию транзакции, и могут включать в себя поддержку для ручного режима и/или режима постоянной активности.

[0261] Ручной режим представляет собой состояние, в котором к мобильному приложению 1212 можно осуществлять доступ для совершения платежа, когда покупатель в явном виде выбирает (1) открыть мобильное приложение 1212, (2) ввести, при необходимости, пользовательский ввод для метода проверки покупателя, и (3) выбрать счет для совершения бесконтактной платежной транзакции и для единой транзакции или ограниченное время. В ручном режиме может приниматься решение, потребуется ли метод проверки держателя карты с покупательским устройством (CDCVM) до совершения платежа. В случае использования CDCVM, сценарий двойного поднесения для транзакций высокого значения может не требоваться. Напротив, для снижения барьеров для использования, если эмитент решает не запрашивать CDCVM в ручном режиме, то покупатель сможет проводить транзакции, при выполнении условий работы в ручном режиме. В этом последнем сценарии, мобильное приложение 1212 может поддерживать ввод CDCVM, если CDCVM запрашивается в ходе платежа высокого значения.

[0262] Режим постоянной активности представляет собой состояние, в котором счет на портативном устройстве связи 1212 (счет по умолчанию) постоянно доступен бесконтактному устройству чтения. Портативное устройство связи, счет которого установлен в этом состоянии, позволяет покупателю инициировать бесконтактную платежную транзакцию путем представления портативного устройства связи бесконтактному устройству чтения. Режим постоянной активности также может поддерживать проверку устройства (ниже именуется режимом постоянной активности с проверкой на устройстве). Эта настройка обеспечивает дополнительную защиту. Например, пользователю может потребоваться разблокировать пользовательский интерфейс портативного устройства связи или экран дисплея, прежде чем мобильное приложение 1212 ответит на попытку бесконтактного устройства чтения инициировать платежную транзакцию.

[0263] Фиг. 13-15 демонстрируют конечный автомат мобильного приложения 1212, когда мобильное приложение 1212 работает в ручном режиме (фиг. 13), режиме постоянной активности (фиг. 14), и режиме постоянной активности с проверкой на устройстве (фиг. 15). Ниже описаны различные состояния, показанные на фиг. 13-15.

[0264] Загруженное: покупатель загружает приложение. Загруженное состояние может быть переходным состоянием в зависимости от конструкции приложения и OS. Если покупатель подносит портативное устройство связи к бесконтактному устройству чтения в этом состоянии, то между портативным устройством связи и устройством чтения не происходит обмена информацией.

[0265] Установленное: покупатель осуществляет установку. Если покупатель подносит портативное устройство связи к бесконтактному устройству чтения в этом состоянии, то между портативным устройством связи и устройством чтения не происходит обмена информацией.

[0266] Инициализированное: покупатель устанавливает счет с MAP, но без добавления платежной карты. Если покупатель подносит портативное устройство связи к бесконтактному устройству чтения в этом состоянии, то между портативным устройством связи и устройством чтения не происходит обмена информацией.

[0267] Активное: покупатель добавляет платежную карту и действительные параметры счета предоставляются в мобильном приложении. Если покупатель подносит портативное устройство связи к бесконтактному устройству чтения в этом состоянии, то мобильное приложение может переходить в режим обработки с удостоверением.

[0268] Готовность к оплате (ручной режим): покупатель активирует платежная карта для совершения платежа. Это переходное состояние, и мобильное приложение должно устанавливать таймер для выхода из состояния. Мобильное приложение переходит в состояние "платеж отправлен", если транзакция совершается, или переходит в активное состояние, если ее время истекает, или переходит к “вводу CDCVM”, если требуется ввод CDCVM. Если покупатель подносит портативное устройство связи к бесконтактному устройству чтения в этом состоянии, то мобильное приложение инициирует бесконтактный обмен данными.

[0269] Готовность к оплате (оба режима постоянной активности): портативное устройство связи готово инициировать транзакцию с бесконтактным устройством чтения. Покупатель выбирает режим постоянной активности в мобильном приложении. Мобильное приложение переходит в состояние "платеж отправлен", если транзакция совершается, или переходит в состояние ввода CDCVM, если требуется CDCVM. Если покупатель подносит портативное устройство связи к бесконтактному устройству чтения в этом состоянии, то мобильное приложение инициирует бесконтактный обмен данными.

[0270] Ввод CDCVM: бесконтактное устройство чтения запрашивает CDCVM. Это переходное состояние, и мобильное приложение должно устанавливать таймер для выхода из состояния. Мобильное приложение переходит в состояние второго поднесения, если покупатель вводит действительный CDCVM, иначе оно переходит в активное состояние (ручной режим) или готовности к оплате (в обоих режимах постоянной активности) по истечении таймера. Если покупатель подносит портативное устройство связи к бесконтактному устройству чтения в этом состоянии, то между портативным устройством связи и устройством чтения не происходит обмена информацией.

[0271] Второе поднесение: портативное устройство связи готово ко второму поднесению для передачи информации проверки CDCVM на бесконтактное устройство чтения. Это переходное состояние, и мобильное приложение может устанавливать таймер для выхода из состояния. Мобильное приложение переходит в состояние "платеж отправлен", если покупатель подносит портативное устройство связи к бесконтактному устройству чтения, иначе оно переходит в активное состояние (ручной режим) или готовности к оплате (в обоих режимах постоянной активности) по истечении таймера. Если покупатель подносит портативное устройство связи к бесконтактному устройству чтения в этом состоянии, то оно отправляет флаг проверки CDCVM на бесконтактное устройство чтения.

[0272] "Платеж отправлен": покупатель отправляет полезную нагрузку платежа на бесконтактное устройство чтения. Это переходное состояние. Если покупатель подносит портативное устройство связи к бесконтактному устройству чтения в этом состоянии, то между портативным устройством связи и устройством чтения не происходит обмена информацией.

[0273] Фон: мобильное приложение выполняется в фоне. Если покупатель подносит портативное устройство связи к бесконтактному устройству чтения в этом состоянии, то мобильное приложение может переходить в режим обработки с удостоверением.

[0274] Не выполняющееся: мобильное приложение не выполняется на портативном устройстве связи. Если покупатель подносит устройство к бесконтактному устройству чтения в этом состоянии, то между портативным устройством связи и устройством чтения не происходит обмена информацией.

[0275] Защита мобильного приложения

[0276] Для обеспечения дополнительной защиты, мобильное приложение 1212 может обфусцировать и защищать сохраненные ключи посредством одобренного механизма, например, свертывания ключей. Код и данные в мобильном приложении 1212 можно обфусцировать для защиты кода от обратного проектирования. Передачи между мобильным приложением 1212 и MAP, которые содержат конфиденциальную информацию, могут обмениваться после того, как канал защищен MAP (например с использованием TLS). Мобильное приложение 1212 может отвечать надлежащим промышленным стандартам; например FIPS-140-2. Коды ошибок, отправленные в инфраструктуру регистрации OS, могут раскрывать только информацию, которая не будет помогать взломщику. Журналы событий и информация отладки позволяет избегать прямого или косвенного раскрытия каких-либо реквизитов. Зарегистрированная информация также может быть зашифрована. Мобильное приложение 1212 и MAP могут обеспечивать механизмы для обнаружения, противодействия и сообщения, находится ли портативное устройство связи в режиме отладки. Состояние устройства, включающее в себя получение полного доступа к файловой системе, получение прав администратора, вредоносные программы, целостность среды выполнения мобильного приложения, и т.д. можно проверять до персонализации и предоставления мобильного приложения 1212, и когда новый параметр счета отправляется на мобильное приложение 1212. При обнаружении любой компрометации, мобильное приложение 1212 может деактивироваться, и причина деактивации передается обратно на MAP. Возможности защиты мобильного приложения могут быть встроены в мобильное приложение 1212, и зависимости от портативного устройства связи и возможности защиты платформы OS можно минимизировать. Для получения доступа с помощью взломанного или похищенного устройства, можно использовать выявление характерных признаков устройства и инструменты, которые поддерживают анализ и аттестацию устройства.

[0277] В некоторых вариантах осуществления, MAP может аутентифицировать покупателя и/или портативное устройство 1201 связи с использованием одно- или многофакторной аутентификации. Хранилище/память, используемое/ая для хранения ключей в мобильном приложении 1212, может проходить процесс сертификации. Например, можно генерировать корневой сертификат. Вход для генерации корневого сертификата можно создавать из атрибутов высокой энтропии, например, труднокопируемых функций (UF), присутствующих на портативном устройстве связи, и атрибутов с привязкой по времени, принятых и сохраненных из внутренней системы. Последующие сертификаты, размещенные в хранилище ключей, можно извлекать из генерируемого ключа шифрования ключей (KEK). Сертификаты пользователей можно использовать в качестве входа для генерации корневого сертификата и KEK. Логика обфусцированной перестановки может обеспечиваться в качестве входа для генерации корневого сертификата и KEK. Логика обфусцированной перестановки может основываться на xx-морфных (полиморфных, метаморфных) механизмах. Хранилище сертификатов может быть привязанным по времени и изменчивым. Извлеченный из хранилища ключей ключ хранимых данных можно шифровать и дешифровать из еще одного KEK при наличии в качестве используемых данных. Двоичные атрибуты для логики приложения, обрабатывающей ключ, может обеспечиваться в качестве входа (связанного) для генерации KEK для защиты используемых данных. Ключи используемых данных можно стирать посредством логики приложения, обрабатывающей ключи. Можно устанавливать следующие профили защиты (PP): PP для хранилища ключей, защищенного KEK1, PP для логика генерации KEK1 и 2, PP для ключа используемых данных, защищенного KEK2, и/или PP для стирания ключа используемых данных.

[0278] Код и данные в мобильном приложении 1212 могут обфусцировать для защиты кода от обратного проектирования. Логика приложения, которая также инициирует извлечение ключа, может быть сертифицирована для противодействия внешнему вмешательству для обеспечения защиты ключей. Логика приложения, где присутствуют сертификаты, используемые для аутентификации, и сами сертификаты могут быть сертифицированы для противодействия внешнему вмешательству. Механизмы обнаружения/противодействия внешнему вмешательству можно реализовать для сохранения целостность логики кода/приложения. Сертификаты пользователя можно использовать в качестве входа в важные части шифрования логики кода. Логика обфусцированной перестановки может обеспечиваться в качестве входа для генерации KEK. Логика обфусцированной перестановки может основываться на xx-морфных (полиморфных, метаморфных) механизмах. Логика кода и приложения может быть привязанной по времени и изменчивой. Можно устанавливать следующие профили защиты (PP): PP для обнаружения/противодействия внешнему вмешательству, PP для обфускации логики генерации, PP для обеспечения измеренной инициализации и/или PP для обновления.

[0279] Запуск мобильного приложения и подготовка счета

[0280] При каждом инициируемом покупателем ручном запуске (т.е. посредством аппаратной или программной клавиши или из среды 1210 мобильного приложения устройства), мобильное приложение 1212 может проверять и сообщать MAP, действует ли портативное устройство 1201 связи в режиме отладки. Мобильное приложение 1212 может проверять, что платежные счета, предоставленные в мобильном приложении 1212, активны и доступны, и проверять, превышены ли пороги 1252 параметров счета, и определять, требуется ли запрос пополнения параметров счета. Мобильное приложение 1212 может проверять состояние устройства, включающее в себя получение полного доступа к файловой системе, получение прав администратора, вредоносные программы, целостность среды выполнения мобильного приложения и, отправлены ли новые параметры счета на мобильное приложение 1212. В случае обнаружения компрометации устройства или приложения, мобильное приложение 1212 может деактивироваться, и причина деактивации может передаваться обратно на MAP.

[0281] Если платежный счет, управляемый мобильным приложением 1212, находится в приостановленном состоянии, то покупатель может воспользоваться предоставленной информацией для совершения необходимого действия или для контакта со своим эмитентом. Для подготовки платежного счета, предоставленного в мобильном приложении 1212, для платежа, пользователь может сначала выбрать оплату с использованием этого платежного счета. Это может осуществляться следующим образом для каждого режима платежа. В ручном режиме, пользователь запускает мобильное приложение 1212, выбирает карту или счет для использования с целью платежа, отмечает на экране платежа выбранную(ый) карту или счет и дает команду заплатить. В режиме постоянной активности, пользователь выбирает карту или счет, подлежащую(ий) использованию для платежа, как платежный счет по умолчанию. В режиме постоянной активности с проверкой на устройстве, пользователь выбирает карту или счет, подлежащую(ий) использованию для платежа, как платежный счет по умолчанию. После выбора карты или счета для платежа, мобильное приложение 1212 может конфигурировать PPSE 1256 надлежащими деталями счета выбранной(ого) карты или счета. После конфигурирования PPSE 1256, выбранная(ый) карта или счет готов(а) для платежа, когда пользователь подносит портативное устройство 1201 связи к устройству доступа или иначе осуществляют связь с устройством доступа.

[0282] Проверка пользователя мобильного приложения

[0283] В некоторых вариантах осуществления, мобильное приложение 1212 может поддерживать проверку пользователя при взаимодействии с MAP и/или взаимодействии с устройством доступа. При взаимодействии с MAP (например, предоставлении или пополнении параметров счета, хранящихся в хранилище 1240 параметров счета), MAP может проверять уникальное имя пользователя и пароль, в зависимости от контекста этого взаимодействия и требований эмитента. Мобильное приложение 1212 также может обеспечивать список методов проверки держателя карты, поддерживаемых мобильным приложением 1212, устройству доступа при взаимодействии с устройством доступа. Методы проверки держателя карты, которые поддерживаются в карточной среде, например, онлайновый PIN и подпись, также могут поддерживаться облачными платежами.

[0284] Портативное устройство 1201 связи также может иметь конкретную категорию методов проверки держателя карты, именуемую метод проверки держателя карты с покупательским устройством (CDCVM). Существует несколько разных способов, которые можно использовать для обеспечения CDCVM для мобильного приложения 1212, которые могут включать в себя одни и те же имя пользователя/пароль, используемые при аутентификации с помощью MAP. Способ CDCVM, используемый мобильным приложением 212, может обеспечивать разные уровни защиты.

[0285] Облачный CDCVM, осуществляемый путем подключения к онлайновой услуге, может обеспечивать наивысший уровень защиты. Это может быть то же, что имя пользователя/пароль, используемые для аутентификации с помощью MAP. Однако, в отсутствие возможности передачи данных, это не позволит совершить платеж, требующий CDCVM. Поэтому эту возможность можно использовать в ручном режиме для предотвращения прерывания платежной транзакции в процессе двойного поднесения вследствие отсутствия возможности передачи данных.

[0286] CDCVM на устройстве, осуществляемый на уровне портативного устройства связи через операционную систему, может обеспечивать улучшение ощущений покупателя. Для примера рассмотрим способ, необходимый для разблокировки экрана портативного устройства связи. Мобильное приложение 1212 принимает указание от портативного устройства 1201 связи при успешном вводе CDCVM. Мобильное приложение 1212 не имеет возможности изменять CDCVM на устройстве. CDCVM мобильного приложения может осуществляться при открытии и запуске мобильного приложения 1212. Примером является ввод числового кода для открытия мобильного приложения 1212. Поскольку программный CDCVM может быть менее защищенным, чем другие возможности, этот способ можно использовать совместно с более защищенной возможностью, например, с облачным CDCVM, где CDCVM мобильного приложения используется в отсутствие возможности передачи данных.

[0287] Пользовательские настройки

[0288] Мобильное приложение 1212 может принимать эти возможности, или их поднабор, подходящим образом или предполагать по умолчанию для одной или более из этих возможностей. Эти возможности описывают общее поведение мобильного приложения 1212. Например, пользовательские настройки 1226 могут включать в себя режимы платежа, например, ручной, постоянной активности или постоянной активности с проверкой на устройстве. Пользовательские настройки 1226 могут включать в себя, может ли покупатель вносить изменения в эти начальные предпочтения, сколько времени нужно покупателю для совершения платежа в каждом режиме, сколько времени нужно покупателю для ввода пароля в транзакции двоичного поднесения (можно применять к сценариям транзакции более высокого значения), в течение какого периода времени мобильное приложение 1212 должно закрыться в отсутствие взаимодействия с покупателем, и т.д. Пользовательские настройки 1226 также могут поддерживать смену пароля. Пользователь может задавать выбранный пароль мобильного приложения покупателя, вызывая процесс смены пароля и обеспечивая текущий или принятый по умолчанию пароль и вновь выбранный пароль покупателя. Покупатель может выбирать эту возможность для изменения ранее выбранного кода-пропуска/пароля. Мобильное приложение 1212 может предлагать покупателю ввести текущий пароль и новый пароль (в зависимости от реализации и от того, замаскированы ли пароли, покупателю может быть предложено ввести новый пароль дважды, чтобы гарантировать правильный ввод). Мобильное приложение 1212 может заменять старый код-пропуск/пароль новым кодом-пропуском/паролем. Местоположение кода-пропуска/пароля может храниться удаленно или локально на устройстве.

[0289] Если покупатель выбирает изменить настройки режима постоянной активности, PPSE 1256 можно конфигурировать надлежащим образом (например, шаблон информация управления файлами (FCI) можно обновлять записью каталога для платежного счета по умолчанию). Это гарантирует, что счет по умолчанию используется, когда портативное устройство связи 1212 подносится к устройству доступа при проведении транзакций.

[0290] Если настройка проверки на устройстве включена, мобильное приложение 1212 может гарантированно не инициировать транзакцию, пока не будет подтвержден способ проверки. В этом случае способ проверки может задаваться пользователем для разблокировки телефона. После успешной проверки, в мобильном приложении 1212 может устанавливаться поле "метод проверки держателя карты (CVM) проверен". Затем успешная проверка в этой настройке переносится на устройство доступа и, в конце концов, эмитенту через поле "CVM проверен".

[0291] События взаимодействия мобильного приложения

[0292] Поведение событий взаимодействия мобильного приложения может зависеть от того, выполняется в данный момент ли мобильное приложение 1212, когда происходит это событие, или является ли получение события базовой средой 1210 мобильного приложения триггером, обуславливающим запуск мобильного приложения 1212. В зависимости от возможностей базовой среды 1210 мобильного приложения, мобильное приложение 1212 имеет возможность отличать друг от друга разные события.

[0293] Извещение проталкивания, полученное базовой средой 1210 мобильного приложения, может перенаправляться на мобильное приложение 1212. Обращение к мобильному приложению 1212 может осуществляться в полосе через MAP для пополнения параметров счета для облачного счета или проталкивания других данных, которые эмитент и/или MAP может считать необходимыми. Канал связи с MAP также может использоваться эмитентами для отправки событий управления жизненным циклом, например, приостановки, возобновления, удаления.

[0294] При закрытии, мобильное приложение 1212 может гарантировать, что состояние каждого платежного счета является подходящим состоянием. Это может применять, когда мобильное приложение 1212 проходит через предполагаемую последовательность закрытия, а также когда мобильное приложение 1212 неожиданно прекращает работу. Предыдущая проверка счета, применяемая в ходе ручного запуска, может быть обращена, и указатели проверки платежного счета CDCVM можно задавать отрицательными. Мобильное приложение 1212 может гарантировать отражение выбранных настроек покупателя и что платежные счета находятся в своих стандартных неактивных состояниях.

[0295] Закрытие/очистка мобильного приложения

[0296] Мобильное приложение 1212 может осуществлять очистку, когда оно закрывается неожиданно (например, портативное устройство связи отключается вследствие низкого заряда батареи) или целенаправленно. В любом режиме платежа, мобильное приложение 1212 может сохранять режим платежа, параметры счета, соответствующие пороги и настройки карты по умолчанию, чтобы они были доступны при повторном запуске мобильного приложения 1212. Мобильное приложение 1212 может заканчивать любую текущую транзакцию, закрывать и открывать сеанс с MAP, сохранять журналы транзакции, если закрытию непосредственно предшествовала успешная транзакция, и освобождать любые ресурсы системы и памяти, используемые мобильным приложением 1212. В некоторых вариантах осуществления, мобильное приложение 1212 может по своему выбору устанавливать или сбрасывать флаг “CDCVM успешно осуществлен”, в зависимости от реализации логики проверки CDCVM.

[0297] Реализация логики, связанной с конфигурацией PPSE, может различаться в ходе закрытия/очистки в зависимости от выбранного режима платежа, когда мобильное приложение 1212 закрывается. В режиме постоянной активности, мобильное приложение 1212 может сохранять конфигурацию PPSE, таким образом, что PPSE берет карту по умолчанию как единственную активную карту для платежа при повторном запуске мобильного приложения 1212. В ручном режиме, конфигурация PPSE может не сохраняться после закрытия. Вместо этого, PPSE может повторно наполняться, когда покупатель выбирает карту для платежа при следующем запуске мобильного приложения 1212. При закрытии мобильного приложения 1212, мобильное приложение 1212 может гарантировать отражение выбранных настроек покупателя и что платежные счета находятся в своих стандартных неактивных состояниях.

[0298] Навигация из мобильного приложения

[0299] Когда покупатель нажимает кнопку возврата в главное меню или кнопку возврата к предыдущему состоянию портативного устройства связи для выхода из мобильного приложения 1212 и затем возврата в него, мобильное приложение 1212 может продолжать выполняться в фоне и продолжать осуществляемую операцию. Мобильное приложение 1212 может применять ограничения для дополнительной защиты, например перерывы, для ограничения времени, когда оно может продолжаться выполняться в фоне. Если покупатель переводит мобильное приложение 1212 в фон во время выполнения транзакции, мобильное приложение 1212 может продолжать обработку транзакции.

[0300] Деинсталляция мобильного приложения

[0301] В процессе деинсталляции, мобильное приложение 1212 может очищать любые конфиденциальные данные, например ключи, сертификаты и параметры счета. Мобильное приложение 1212 может информировать MAP таким образом, что CBPP и эмитент/базовая система могут выполнять необходимые процессы управления жизненным циклом для счетов, предоставленных в мобильном приложении 1212, во время деинсталляции. Мобильное приложение 1212 может закрывать и открывать сеанс с MAP, заканчивать текущую транзакцию, при наличии, и освобождать любые ресурсы системы и памяти, используемые мобильным приложением 1212.

[0302] Регистрация счета

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

[0303] Логика 1232 регистрации может позволять покупателю вводить детали карты для инициирования регистрации платежного счета. Детали для захвата может определяться эмитентом/базовой системой и/или CBPP, но должны быть достаточными для уникальной идентификации и проверки платежного счета. Эмитент/базовая система и/или CBPP может определять способ и информацию, необходимую для аутентификации покупателя, владеющего этим счетом. Мобильное приложение 1212 может отправлять данные регистрации платежного счета на MAP, которая затем будет отправлять и управлять процессом регистрации счета и проверки счета с эмитентом/базовой системой и/или CBPP.

[0304] В случае успешной регистрации, мобильное приложение 1212 может принимать от MAP данные для предоставления нового платежного счета для платежа, включающие в себя ID приложения (AID) платежного счета, PPSE AID, настройки эмитента платежного счета, дизайн карты платежного счета, параметры счета, настройки и пороги параметров счета, и т.д. В случае успешной регистрации, логика 1232 регистрации может обеспечивать платежный счет на основании информации, принятой от MAP. Мобильное приложение 1212 также может, в процессе конфигурирования, просить покупателя установить способ проверки счета (например, код-пропуск), если он еще не установлен. По завершении конфигурирования счета, мобильное приложение 1212 может отображать покупателю сообщение, что регистрация прошла успешно. Мобильное приложение 1212 может поддерживать и конфигурировать пороги параметров счета, заданные эмитентом/базовой системой и/или CBPP. Пороги параметров счета могут включать в себя число транзакций (т.е. совокупное число транзакций, которые запрашивают пополнение для конкретного платежного счета), время существования (т.е. необходимую продолжительность времени до того, как мобильное приложение 1212 запросит пополнение для конкретного платежного счета) и/или совокупную сумму транзакции (т.е. итоговую денежную сумму по одной или более транзакций, проведенных на конкретном счете, прежде чем мобильное приложение 1212 запросит пополнение для этого счета). Если регистрация прошла неудачно, мобильное приложение 1212 может принимать и обрабатывать извещение о неудаче и код причины, и отображать покупателю сообщение, что регистрация прошла неудачно, и просить покупателя совершить любое надлежащее действие.

[0305] Платеж с использованием мобильного приложения

[0306] Мобильное приложение 1212 позволяет пользователю осуществлять бесконтактные транзакции на бесконтактном устройстве доступа через портативное устройство 1201 связи. Мобильное приложение 1212 способствует этому с использованием параметров счета, обеспеченных CBPP для генерации формата данных для проведения платежных транзакций. Чтобы покупатель не испытывал замешательства в отношении назначения платежа, при наличии нескольких платежных мобильных приложений, установленных на портативном устройстве связи 1212, покупателю может потребоваться выбрать мобильное приложение, используемое для платежа. Существует несколько возможностей добиться этого. Покупатель может, по своему выбору, устанавливать платежное мобильное приложение по умолчанию в настройках мобильной OS. Покупатель имеет возможность устанавливать платежный продукт по умолчанию в настройках конкретного мобильного приложения. Покупатель имеет возможность вручную выбирать платежный продукт в этом мобильном приложении. Чтобы гарантировать использование выбора покупателя, мобильное приложение 1212 может представлять выбранный платежный счет устройству доступа. Мобильное приложение 1212 может поддерживать либо путь транзакции на основе интегральной микросхемы, либо путь транзакции на основе магнитной полоски, в зависимости от того, какой тип транзакции поддерживает устройство доступа. Транзакция на основе интегральной микросхемы является путем по умолчанию, используемым с устройством доступа для работы с чипованной картой, и транзакция на основе магнитной полоски является путем по умолчанию, используемым с устройством доступа для работы только с магнитной полоской.

[0307] В некоторых вариантах осуществления, мобильное приложение 1212 может поддерживать множественные идентификаторы приложений (AID) для одного счета. С одним счетом может быть связано несколько AID, например, если транзакция, проведенная по этому счету, может обрабатываться разными сетями обработки платежей и/или если счет имеет разные услуги, признаки, типы продукта и возможности платежа, связанные со счетом. Множественные AID могут передаваться на устройство доступа, чтобы устройство доступа могло выбирать предпочтительный AID для выбора метода обработки транзакции (например, сети обработки платежей) и/или какие услуги или признаки можно связывать с транзакцией. С этой целью множественные AID можно вносить в запись каталога для PPSE и передавать на устройство доступа.

[0308] Например, единый счет может иметь общий дебетовый AID и AID, зависящий от сети обработки платежей (например, Visa AID), связанный с единым счетом. Эти AID можно вносить в запись каталога для PPSE, и информация управления файлами (FCI) PPSE для каждой записи каталога может включать в себя идентификационный номер эмитента (IIN) и код страны эмитента (ICC). В некоторых вариантах осуществления, CVM для дебетового AID может быть онлайновым CVM (например, онлайновым PIN), тогда как CVM для AID, зависящий от сети обработки платежей, может быть подписью.

[0309] Бесконтактный платеж может инициироваться покупателем, подносящим портативное устройство 1201 связи к бесконтактному устройству чтения (например, устройство чтения NFC), или иначе осуществляющим связь с бесконтактным устройством чтения (например, отображения QR-код или штрих-код) устройства доступа. Устройство доступа может запрашивать метод проверки держателя карты (CVM) для транзакций выше пороговой суммы (например, транзакций свыше $20). Мобильное приложение 1212 может поддерживать несколько разных CVM, включающий в себя метод проверки держателя карты с покупательским устройством (CDCVM) для конкретного мобильного устройства. Не все устройства доступа могут поддерживать CDCVM, и в этих случаях, может запрашиваться альтернативный CVM, например подпись или онлайновый PIN.

[0310] Указание успешного ввода CDCVM отправляется в ходе платежной транзакции на бесконтактное устройство чтения. Мобильное приложение 1212 может конфигурировать надлежащие данные в параметрах счета во время платежа, когда CDCVM успешно подтвержден. Всякий раз, когда CDCVM успешно введен, мобильное приложение 1212 может сохранять эту информацию, поэтому указатель проверки CDCVM и указатель типа CDCVM можно задавать и передавать на бесконтактное устройство чтения в ходе платежной транзакции. Это может препятствовать устройству доступа в предложении покупателю ввести CDCVM на устройстве доступа. Мобильному приложению 1212 предоставляется возможность обеспечивать указание успешного CDCVM по запросу устройства доступа в ходе платежной транзакции двойного поднесения.

[0311] Когда мобильное приложение 1212 блокируется вследствие неактивности, мобильное приложение 1212 может сохранять эту информацию, поэтому указатель проверки CDCVM можно задать отрицательным. Если в этом состоянии инициируется бесконтактный платеж, устройство доступа может предлагать покупателю для ввода CDCVM. Мобильное приложение 1212 может обеспечивать возможность сброса CDCVM, если оно обеспечивает способ ввода проверки покупателя для CDCVM. Мобильное приложение 1212 может устанавливать предельное количество попыток проверки покупателя и блокировать мобильное приложение 1212 в случае превышения этого предела. В целях защиты, эмитенты могут запрашивать дополнительную проверку покупателя до разблокировки мобильного приложения 1212. В некоторых вариантах осуществления, мобильное приложение 1212 может иметь CDCVM, не синхронизированный с онлайновым PIN карты компаньона.

[0312] В ручном режиме, покупатель может открывать или запускать мобильное приложение 1212 для обеспечения функции платежа. Когда мобильное приложение 1212 открыто, функция может позволять покупателю инициировать платеж путем поднесения портативного устройства 1201 связи к бесконтактному устройству чтения. Портативное устройство 1201 связи может препятствовать покупателю в осуществлении транзакции на основании любых счетов, хранящихся в мобильном приложении 1212, если мобильное приложение 1212 не открыто и активно как приложение переднего плана.

[0313] Если указатель CDCVM не положителен (т.е. действительный CDCVM еще не введен), мобильное приложение 1212 может запрашивать ввод CDCVM после открытия. Если этот путь реализации выбран, это может гарантировать, что покупатель повторно не запрашивается для ввода CDCVM в ходе платежной транзакции (т.е. во избежание сценария двойного поднесения для платежей высокого значения). Напротив, если этот путь реализации не выбран, применимость для покупателя можно повысить, пропуская запрос для ввода CDCVM для транзакций ниже лимита высокого значения, причем от покупателя требуется компромисс для ввода CDCVM в случае проведения платежа высокого значения.

[0314] При наличии более чем одной платежной карты или счета, доступного в мобильном приложении 1212, по умолчанию будет выбрана карта или счет, используемый для платежной транзакции, пока покупатель не выберет альтернативную карту или счет как активный для платежа. Когда приложение 1212 открыто, PPSE 1256 может наполняться, и портативное устройство 201 связи может инициировать платежную транзакцию. Мобильное приложение 1212 может отображать покупателю сообщение, указывающее, что портативное устройство 1201 связи “готово к платежу”. Мобильное приложение 1212 может задавать лимит времени для неактивности и, в случае его превышения, может блокировать мобильное приложение 1212. Это гарантирует, что покупатель продолжает управлять функцией платежа, и неактивность не приводит к переходу из ручного режима в режим постоянной активности. Мобильное приложение 1212 также может позволять покупателю выбирать предпочтительный лимит времени в настройках. В зависимости от того, требуется ли CDCVM, мобильное приложение 1212 может требовать ввода CDCVM для разблокировки мобильного приложения 1212, заблокированного вследствие неактивности.

[0315] В режиме постоянной активности, бесконтактный платеж возможность доступен всякий раз, когда экран телефона активен. Возможность бесконтактной связи (например, NFC) может быть доступна даже если экран телефона все еще находится в заблокированном состоянии. Чтобы гарантировать, что покупатели осведомлены об этой возможности и могут подписываться на ее использование, мобильное приложение 1212 может препятствовать установлению режима постоянной активности как режима по умолчанию. Всякий раз, когда экран телефона активен, PPSE 1256 может активироваться и наполняться, и портативное устройство 1201 связи способно инициировать платежную транзакцию. Когда покупатель инициирует бесконтактную транзакцию с экраном в заблокированном состоянии, бесконтактное устройство чтения может запрашивать ввод CDCVM. В случае использования CDCVM на уровне устройства, указатель в виде пиктограммы может отображаться на панели уведомлений, и экран телефона необходимо разблокировать. Затем мобильное приложение 1212 может предписывать покупателю подносить портативные устройства 1201 связи к бесконтактному устройству чтения. В случае использования CDCVM на уровне мобильных приложений, указатель в виде пиктограммы может отображаться на панели уведомлений. Мобильное приложение 1212 может представлять покупателю экран ввода CDCVM и затем предписывать покупателю подносить портативные устройства 1201 связи к бесконтактному устройству чтения после успешного ввода CDCVM.

[0316] В режиме постоянной активности с проверкой устройства, бесконтактный платеж возможность доступен всякий раз, когда экран телефона активен и разблокирован. Возможность бесконтактной связи недоступна, когда экран телефона все еще находится в заблокированном состоянии. Всякий раз, когда экран телефона разблокирован, PPSE 1256 можно активировать и наполнять, и портативное устройство 1201 связи способно инициировать платежную транзакцию. Если покупатель пытается инициировать бесконтактный платеж с экраном в заблокированном состоянии, бесконтактное устройство чтения не сможет осуществлять связь с портативным устройством 1201 связи, и таким образом, ничего не будет происходить ни не устройстве доступа, ни на портативном устройстве 1201 связи. Когда покупатель инициирует бесконтактный платеж с экраном в разблокированном состоянии, бесконтактное устройство чтения может запрашивать ввод CDCVM. В случае использования CDCVM на уровне устройства, мобильное приложение 1212 может предписывать покупателю подносить портативные устройства 1201 связи к бесконтактному устройству чтения. В случае использования CDCVM на уровне мобильного приложения, мобильное приложение 1212 может представлять покупателю экран ввода CDCVM и затем предписывать покупателю подносить портативные устройства 1201 связи к бесконтактному устройству чтения после успешного ввода CDCVM.

[0317] Когда мобильное приложение 1212 и устройство доступа завершила передачи для обеспечения данных для завершения транзакции, мобильное приложение 1212 может отображать сообщение, указывающее, что платеж был отправлен. Бесконтактный платеж, проведенный с использованием пути транзакции на основе интегральной микросхемы, может обеспечивать мобильное приложение 1212 некоторыми данными транзакции, например, суммой транзакции и информацией торговца. Мобильное приложение 1212 может наполнять сообщение "платеж отправлен" этой информацией. Бесконтактный платеж, проведенный с использованием пути транзакции на основе магнитной полоски не обеспечивает мобильное приложение 1212 никакими данными транзакции. После платежа, мобильное приложение 1212 может проверять пороги параметров счета, и определять, нужно ли мобильному приложению 1212 отправлять запрос для пополнения параметров счета.

[0318] Управление активным счетом

[0319] Логика 1236 управления активным счетом мобильного приложения 1212 инициирует и регулирует запрос для пополнения параметров счета, в случае превышения порогов параметров счета. Для снижения риска компрометации параметров счета, хранящихся в хранилище 1240 параметров счета, параметры счета могут периодически генерироваться CBPP и пополняться в мобильном приложении 1212, а также обновляться на эмитенте/базовой системе для поддержания счета в активном состоянии. Для инициирования процесса управления активным счетом, CBPP может принимать запрос пополнения для новых параметров счета из мобильного приложения 1212 через MAP. CBPP 180 также может действовать по запросу, принятому от эмитента/базовой системы.

[0320] В некоторых вариантах осуществления, логика 1236 управления активным счетом мобильного приложения 1212 может запускать обновление или пополнение параметров счета в процессе вытягивания пополнения параметров счета. Логика 1236 управления активным счетом может пытаться инициировать поток пополнения параметров счета во время, когда покупатель запускает мобильное приложение 1212, или после завершения транзакции, и в случае превышения порогов 1252 параметров счета. Приняв обновленный набор параметров счета, мобильное приложение 1212 может обрабатывать полезную нагрузку параметров счета и делать новые параметры счета доступными для платежа. После успешной обработки нового набора параметров счета, мобильное приложение 1212 может генерировать извещение на MAP. MAP может извещать CBPP о том, что параметры счета успешно доставлены на мобильное приложение 1212. Заметим, что обновленные параметры счета могут сопровождаться новым набором параметров управления порогами устройства (например, порогами ограниченного использования, отличающимися от предыдущего набора параметров счета), который эмитент может пожелать использовать, когда покупатель находится в других средах (например вне внутреннего рынка). До инициирования обмена конфиденциальной информацией, MAP может осуществлять аутентификацию на уровне пользователя, устройства и приложения.

[0321] Обновление или пополнение параметров счета также может осуществляться посредством процесса проталкивания пополнения параметров счета. В этом потоке, CBPP инициирует процесс для обновления параметров счета. CBPP отправляет сообщение проталкивания на MAP для инициирования проталкивания пополнения. Затем MAP может отправлять сообщение проталкивания на мобильное приложение 1212. Затем мобильное приложение 1212 генерирует запрос обновления параметров счета для каждого вышеописанного потока вытягивания пополнения. До инициирования обмена конфиденциальной информацией, MAP может осуществлять аутентификацию на уровне пользователя, устройства и приложения. Если аутентификация на уровне пользователя используется после истечения предыдущей аутентификации, то мобильное приложение 1212 может кэшировать запрос, пока покупатель не откроет мобильное приложение 1212 и не осуществит аутентификацию на уровне пользователя. После успешной аутентификации, мобильное приложение 1212 выполняет ту же процедуру, что и в потоке вытягивания пополнения. Если аутентификация на уровне пользователя не требуется после истечения предыдущей аутентификации, мобильное приложение 1212 может сразу же выполнять ту же процедуру, что и в потоке вытягивания пополнения.

[0322] Приняв обновленный набор параметров счета, логика 1236 управления активным счетом может проверять пригодность новых параметров счета, делать новые параметры счета доступными для платежа, сбрасывать пороги параметров счета, сбрасывать пороговые конфигурации параметров счета, и удалять старый набор параметров счета. В некоторых вариантах осуществления, мобильное приложение 1212 может позволять инициировать транзакцию, даже если параметры счета не были обновлены вследствие отсутствия возможности осуществления связи по сети. Эмитент/базовая система или сеть обработки платежей, действующая от имени эмитента, может принимать решение на одобрение или отклонение транзакции на основании информации о просроченных параметрах счета совместно с другими метрики риска, заданными эмитентом.

[0323] Мобильное приложение 1212 может включать в себя несколько порогов 1252 параметров счета устройства облачных платежей или пределы риска, которые запускают обновление текущего набора параметров счета. Они могут включать в себя число транзакций, время существования и/или совокупную сумму транзакции, и т.д. Если параметры счета действительны для число транзакций в CBPP, то пороги 1252 параметров счета в мобильном приложении 1212 можно конфигурировать с более низким пороговым числом транзакций (например, на одну меньше, чем число транзакций в CBPP) для запуска пополнения. Если параметры счета имеют время окончания срока действия в CBPP, пороги 1252 параметров счета в мобильном приложении 1212 можно конфигурировать с пороговой продолжительностью времени, меньшей, чем время окончания срока действия для запуска пополнения. Когда доступно от бесконтактного устройства чтения, логика 1236 управления активным счетом может использовать сумму транзакции для принятия решения, следует ли обновлять параметры счета. Меньшие суммы транзакции не обязательно требуют немедленного обновления параметров счета. Однако этот механизм может быть ненадежен в средах, где мобильное приложение 1212 не согласованно принимает сумму транзакции от терминала доступа. Когда доступна, совокупную сумму транзакции можно использовать в качестве триггера для обновления параметров счета. Этот лимит базируется на суммах сумм отдельных транзакций. Эти данные не обязательно надежны с точки зрения мобильного приложения 1212, пока данные не будут синхронизированы с эмитентом/базовой системой, чтобы гарантировать, что данная транзакция одобрена. Настройку внутренних и международных рисков также можно использовать для более частого запуска обновлений для международных транзакций в случае, когда они считаются более рискованными.

[0324] Управление жизненным циклом счета

[0325] Мобильное приложение 1212 может включать в себя логику 1234 управления жизненным циклом, обеспечивающую пользователю возможность удаления, инициируемого пользователем, для удаления карты или счета из мобильного приложения 1212 посредством логики 1234 управления жизненным циклом. Логика 1234 жизненного цикла счета может удалять параметры счета, хранящиеся в хранилище 1240 параметров счета, связанном с этим счетом, совместно со всеми остальными данными или артефактами конфигурации счета. Логика 1234 управления жизненным циклом может инициировать процесс удаления счета в CBPP путем инициирования запроса удаления на CBPP через MAP.

[0326] Логика 1234 управления жизненным циклом может обеспечивать эмитенту механизм удаления, инициируемого эмитентом для удаления счета. Эмитент/базовая система может отправлять запрос удаления на CBPP, и CBPP, в свою очередь, может маршрутизировать запрос на мобильное приложение 1212. Логика 1234 управления жизненным циклом может удалять локально хранящийся параметры счета, связанные со счетом, совместно со всеми остальными данными или артефактами конфигурации счета. Мобильное приложение 1212 может отправлять квитирование на MAP, указывающее, что удаление завершено. Мобильное приложение 1212 также может отображать пользователю сообщение, указывающее, что счет удален.

[0327] Логика 1234 управления жизненным циклом может обеспечивать эмитенту механизм приостановки, инициируемой эмитентом, для приостановки счета. Эмитент/базовая система может отправлять запрос приостановки на CBPP, и CBPP, в свою очередь, может маршрутизировать запрос на мобильное приложение 1212. Логика 1234 управления жизненным циклом может приостанавливать карту или счет в мобильном приложении 1212. В приостановленном состоянии, счет нельзя выбрать в настройках мобильного приложения для совершения платежа. Логика 1234 управления жизненным циклом может отправлять квитирование на MAP после приостановки счета. Мобильное приложение 1212 может отображать пользователю сообщение, указывающее, что счет приостановлен, и также сообщать покупателю о необходимости связаться с эмитирующим банком.

[0328] Логика 1234 управления жизненным циклом может обеспечивать эмитенту механизм возобновления, инициируемого эмитентом, для возобновления счета, когда он был приостановлен в мобильном приложении 1212. Эмитент/базовая система может отправлять запрос возобновления на CBPP, и CBPP, в свою очередь, может маршрутизировать запрос на мобильное приложение 1212. Логика 1234 управления жизненным циклом может возобновлять карту или счет в мобильном приложении 1212. После возобновления, карту или счет можно выбирать в настройках мобильного приложения для платежа. Мобильное приложение 1212 может отправлять квитирование на MAP после возобновления счета и отображать пользователю сообщение, указывающее, что счет возобновлен.

[0329] Постплатежные взаимодействия

[0330] Постплатежные взаимодействия или обработка могут помогать эмитентам снижать риск компрометации параметров счета и, таким образом, могут помогать ограничивать раскрытие параметров счета, хранящихся на портативном устройстве 1201 связи. Информацию, содержащуюся в журнале проверки транзакции, можно использовать для обеспечения реперной точки, помогающей CBPP гарантировать, что запросы пополнения параметров счета исходят из предполагаемого портативного устройства связи. Мобильное приложение 1212 может включать в себя постплатежную логику 1238 для извлечения информации из журнала 1254 проверки транзакции для построения запросов пополнения параметров счета.

[0331] Кроме того, эмитент/базовая система, работающий/ая совместно с CBPP, может иметь возможность инициирования запроса, через MAP, для данных журнала проверки транзакции, захваченных и сохраненных мобильным приложением 1212 для проверки транзакции. Мобильное приложение 1212 может отвечать, через MAP, на запрос запрашиваемыми данными журнала проверки транзакции. Затем эти данные могут проверяться эмитентом/базовой системой для подтверждения, исходила ли конкретная транзакция из запрошенного портативного устройства связи. Примеры элементов данных, которые могут быть включены в журнал проверки транзакции, могут включать в себя, для каждой транзакции, время транзакции (например, время бесконтактного взаимодействия, сумму транзакции и непредсказуемое число, принятое от устройства доступа в ходе транзакции), а также информацию параметров счета, например, индекс ключа, связанный с LUK, который использовался для проведения транзакций. Для проверки платежной транзакции, мобильное приложение 1212 может принимать и обрабатывать запрос от MAP для данных журнала проверки транзакции, захваченных и сохраненных мобильным приложением 1212. Мобильное приложение 1212 может отвечать на запрос MAP запрашиваемыми данными журнала проверки транзакции. Мобильное приложение 1212 может использовать LUK текущего параметра счета или эквивалентный на участке динамических данных параметров счета для подписывания запрашиваемых данных журнала проверки транзакции.

[0332] Журнал проверки транзакции

[0333] Мобильное приложение 1212 может поддерживать журнал 1254 проверки транзакции для регистрации всех бесконтактных взаимодействий (например, NFC), где параметры платежного счета совместно использовались с устройством доступа, независимо от того, была ли транзакция одобрена или отклонена, или независимо от того, видит ли мобильное приложение 1212 результат транзакции (например, одобрена она или отклонена). Мобильное приложение 1212 может сохранять данные журнала проверки транзакции для текущего и предыдущего набора параметров счета для каждого платежного счета. В некоторых вариантах осуществления, данные журнала проверки транзакции для старого набора параметров счета можно удалять, как только мобильное приложение 1212 принимает новый набор параметров счета. Журнал 1254 проверки транзакции может быть или не быть доступен или видим пользователю.

[0334] XII. Иллюстративная компьютерная система

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

[0336] Примеры таких подсистем или компонентов показаны на фиг. 16. Подсистемы, показанные на фиг. 16, соединены между собой системной шиной 1602. Показаны дополнительные подсистемы, например, принтер 1604, клавиатура 1606, жесткий диск 1608 (или другое запоминающее устройство, содержащее компьютерно-считываемые носители), монитор 1610, который подключен к адаптеру 1612 дисплея и пр. Периферийные устройства и устройства ввода/вывода (I/O), которые подключены к контроллеру 1614 ввода/вывода (которым может быть процессор или другой подходящий контроллер), могут быть подключены к компьютерной системе любыми средствами, известными в технике, например, через последовательный порт 1616. Например, последовательный порт 1616 или внешний интерфейс 1618 можно использовать для подключения компьютерного устройства к глобальной сети, например, интернету, устройству ввода типа мышь или сканеру. Внутреннее соединение через системную шину позволяет центральному процессору 1620 осуществлять связь с каждой подсистемой и управлять выполнением инструкций, хранящихся в системной памяти 1622 или на жестком диске 1608, а также обеспечивает обмен информации между подсистемами. Системная память 1622 и/или жесткий диск 1608 могут служить примерами компьютерно-считываемого носителя.

[0337] Варианты осуществления изобретения не ограничиваются вышеописанными вариантами осуществления. Например, хотя отдельные функциональные блоки показаны для эмитента, сети обработки платежей и приобретателя, некоторые субъекты осуществляют все эти функции и могут быть включены в варианты осуществления изобретения.

[0338] Выше приведены конкретные детали, касающиеся некоторых из вышеописанных аспектов. Конкретные детали конкретных аспектов можно объединить любым пригодным образом, не выходя за рамки сущности и объема вариантов осуществления изобретения. Например, внутренняя обработка, анализ данных, сбор данных и другие транзакции можно объединять в некоторых вариантах осуществления изобретения. Однако другие варианты осуществления изобретения могут быть связаны с конкретными вариантами осуществления, относящимися к каждому отдельному аспекту или конкретным комбинациям этих отдельных аспектов.

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

[0340] Любой из программных компонентов или функций, описанных в данной заявке, может быть реализован как программный код, подлежащий выполнению процессором с использованием любого пригодного компьютерного языка, например, Java, C++ или Perl с использованием, например, традиционных или объектно-ориентированных методов. Программный код может храниться в виде последовательности инструкций, или команд на компьютерно-считываемом носителе, например, в оперативной памяти (RAM), постоянной памяти (ROM), на магнитном носителе, например, жестком диске или флоппи-диске, или на оптическом носителе, например CD-ROM. Любой такой компьютерно-считываемый носитель может располагаться на или в едином вычислительном устройстве, и может присутствовать на или в разных вычислительных устройствах в системе или сети.

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

[0342] Один или более признаков любого варианта осуществления можно объединить с одним или более признаками любого другого вариант осуществления, не выходя за рамки объема изобретения.

[0343] Использование единственного числа призвано означать "один или более", если конкретно не указано обратное.

[0344] Все вышеупомянутые патенты, патентные заявки, публикации и описания включены сюда посредством ссылки в полном объеме для всех целей. Ничто не признается уровнем техники.

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

принимают от удаленного компьютера ключ ограниченного использования (LUK), который связан с набором из одного или более порогов ограниченного использования, которые ограничивают использование LUK;

генерируют посредством устройства связи криптограмму транзакции с использованием LUK;

отправляют на устройство доступа обозначение вместо реального идентификатора счета и криптограммы транзакции для проведения транзакции, причем транзакция авторизуется на основании, по меньшей мере, того, превысило ли использование LUK набор из одного или более порогов ограниченного использования;

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

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

2. Способ по п. 1, в котором устройство связи не хранит LUK или обозначение в защитном элементе.

3. Способ по п. 1, в котором прием LUK дополнительно включает в себя этап, на котором принимают индекс ключа, который включает в себя информацию, относящуюся к генерации LUK.

4. Способ по п. 3, в котором индекс ключа отправляют с криптограммой транзакции на устройство доступа для проведения транзакции.

5. Способ по п. 3, в котором индекс ключа включает в себя информацию времени, указывающую, когда сгенерирован LUK.

6. Способ по п. 3, в котором индекс ключа включает в себя значение счетчика пополнения, указывающее, сколько раз был пополнен LUK.

7. Способ по п. 3, в котором индекс ключа включает в себя псевдослучайное число, которое используется в качестве начального значения для генерации LUK.

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

9. Способ по п. 1, в котором набор из одного или более порогов ограниченного использования включает в себя, по меньшей мере, один из:

времени существования, указывающего продолжительность времени, в течение которого LUK действителен;

заранее определенного числа транзакций, на протяжении которых LUK действителен; и

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

10. Способ по п. 1, в котором набор из одного или более порогов ограниченного использования включает в себя порог международного использования и порог внутреннего использования.

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

прием нового LUK включает в себя этап, на котором принимают второй индекс ключа, связанный с новым LUK.

12. Способ по п. 1, в котором журнал транзакций, хранящийся на устройстве связи, включает в себя:

для каждой транзакции, проведенной с использованием LUK:

метку времени транзакции, указывающую время соответствующей транзакции;

значение счетчика транзакций с помощью приложения, связанное с соответствующей транзакцией; и

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

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

14. Способ по п. 1, в котором запрос пополнения отправляют в ответ на определение, что следующая транзакция, проведенная с помощью LUK, исчерпает набор из одного или более порогов ограниченного использования.

15. Способ по п. 1, в котором запрос пополнения отправляют в ответ на определение, что набор из одного или более порогов ограниченного использования, связанный с LUK, исчерпан.

16. Способ по п. 1, в котором запрос пополнения отправляют в ответ на прием сообщения проталкивания, запрашивающего устройство связи пополнить LUK.

17. Способ по п. 3, в котором генерируют LUK, для чего

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

осуществляют шифрование индекса ключа, используя второй ключ шифрования, для генерирования LUK.

18. Способ по п. 17, в котором этап шифрования информации счета первым ключом шифрования для генерирования второго ключа шифрования содержит:

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

инвертирование информации счета;

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

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

заполняют индекс ключа первым числовым значением для генерирования информации первого заполненного индекса ключа;

осуществляют шифрование информации первого заполненного индекса ключа для генерирования первого участка LUK;

заполняют индекс ключа вторым числовым значением для генерирования информации второго заполненного индекса ключа;

осуществляют шифрование информации второго заполненного индекса ключа для генерирования второго участка LUK.

20. Способ по п.1, в котором генерируют криптограмму транзакции, для чего

осуществляют шифрование информации транзакции, используя первый участок LUK;

осуществляют дешифрование зашифрованной информации транзакции, используя второй участок LUK; и

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

21. Способ по п. 1, в котором генерируют криптограмму транзакции, для чего

осуществляют шифрование заранее определенной числовой строки с использованием LUK; и

преобразуют зашифрованную заранее определенную числовую строку в десятеричную систему счисления.

22. Способ по п. 21, в котором этап преобразования зашифрованной заранее определенной числовой строки содержит:

извлечение десятеричных цифр из зашифрованной заранее определенной числовой строки для формирования первого блока данных;

извлечение шестнадцатеричных цифр из зашифрованной заранее определенной числовой строки и преобразование каждой извлеченной шестнадцатеричной цифры в десятеричную цифру для формирования второго блока данных; и

конкатенацию первого блока данных и второго блока данных.

23. Устройство связи, содержащее:

процессор; и

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