РОДСТВЕННЫЕ ЗАЯВКИ
[0001]Данная заявка испрашивает преимущество и приоритет предварительной заявки США № 62/107966, поданной 26 января 2015 года, и предварительной заявки США № 62/056401, поданной 26 сентября 2014, содержание которых полностью включено в данный документ посредством ссылки для всех целей.
ПРЕДПОСЫЛКИ ИЗОБРЕТЕНИЯ
[0002]Для выполнения транзакций доступа к ресурсам с использованием мобильного устройства, такого как мобильный телефон, пользователю может быть необходимо предоставить конфиденциальные данные пользователя (например, пароль, номер счета, маркированную информацию и т. д.) на мобильное устройство. Например, пользователь может ввести конфиденциальные данные пользователя в мобильное устройство, и она может быть сохранена на мобильном устройстве.
[0003]Проблема, связанная с использованием мобильного устройства для транзакций доступа к ресурсам заключается в том, что конфиденциальные данные пользователя могут быть получены неуполномоченными лицами во время их хранения на мобильном устройстве. Например, неуполномоченное лицо может попытаться получить доступ к конфиденциальным данным пользователя, если сам пользователь потеряет свое мобильное устройство, или если постороннее лицо попытается взломать мобильное устройство через сеть связи или передачи данных.
[0004]Существует необходимость в улучшенных способах, системах и устройствах защиты данных. Варианты осуществления настоящего изобретения устраняют эти и другие недостатки, вместе и по отдельности.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
[0005]Варианты осуществления настоящего изобретения направлены на надежные и эффективные способы осуществления связи между субъектами, вовлеченными в генерирование, доставку и хранение защищенных данных пользователя на мобильном устройстве. Мобильное устройство согласно варианту осуществления изобретения может предоставлять конфиденциальные данные пользователя (например, информацию о платеже, номер счета, номер социального страхования, идентификационный номер и т. д.) на компьютер поставщика услуг (например, компьютер поставщика токенов) в зашифрованном формате, так что мобильное устройство не имеет доступа к конфиденциальным данным пользователя. Компьютер поставщика услуг может затем генерировать токен (то есть, маркированную версию данных пользователя) и может затем передавать токен на мобильное устройство. Токен может быть сохранен на мобильном устройстве и может затем быть использован для проведения транзакций доступа к ресурсам (например, платежных транзакций, транзакций для доступа к местам проведения мероприятий и т. д.).
[0006]Один вариант осуществления настоящего изобретения включает прием мобильным устройством с удаленного сервера мобильных приложений зашифрованных данных пользователя, связанных с пользователем мобильного устройства. Зашифрованные данные пользователя генерируют с применением ключа шифрования, связанного с серверным компьютером токенов. В некоторых вариантах осуществления ключ шифрования и данные пользователя, связанные с пользователем мобильного устройства, сохраняет удаленный сервер мобильных приложений. Мобильное устройство генерирует сообщение с запросом токена, содержащее зашифрованные данные пользователя, и отправляет сообщение с запросом токена на серверный компьютер токенов. Серверный компьютер токенов расшифровывает зашифрованные данные пользователя с использованием ключа шифрования, идентифицирует счет, связанный с расшифрованными данными пользователя, генерирует токен, связанный со счетом, сохраняет токен и отправляет токен на мобильное устройство. Способ также включает прием мобильным устройством токена, связанного с зашифрованными данными пользователя, с серверного компьютера токенов. Мобильное устройство сохраняет токен в памяти для токенов. В некоторых вариантах осуществления памятью для токенов управляет модуль токенов (например, комплект разработки программного обеспечения (SDK) для токенов), предусмотренный на мобильном устройстве. Модуль токенов может быть связан с серверным компьютером токенов и может облегчать взаимодействие между мобильным устройством и серверным компьютером токенов. Модуль токенов может соединяться с программным интерфейсом приложений (API) серверного компьютера токенов.
[0007]Варианты осуществления настоящего изобретения предусматривают ряд технических преимуществ. Даже если токен на мобильном устройстве украден неуполномоченным пользователем, эффект от кражи и/или сбоя для пользователя является минимальным, поскольку токен может быть легко заменен и/или может быть периодически обновлен (например, через каждые несколько транзакций или в предварительно определенный промежуток времени, например, каждые три-четыре дня). В упомянутом выше примере мобильное устройство никогда не обладает прямым доступом к конфиденциальным данным пользователя. За счет предотвращения предоставления мобильному устройству доступа к конфиденциальным данным пользователя (т. е., в незашифрованном формате), данные пользователя могут быть защищены от кражи, подделывания или иной дискредитации.
[0008]В некоторых вариантах осуществления сохранение токена в памяти для токенов может включать сохранение токена в защищенной памяти мобильного устройства, определение ключа токена, связанного с сохраненным токеном, и предоставление ключа токена мобильному приложению на мобильном устройстве для использования в качестве ссылочного идентификатора токена для токена.
[0009] В некоторых вариантах осуществления способ может также включать запрос мобильным устройством статуса токена. Способ может включать прием мобильным устройством ответа о статусе токена от серверного компьютера токенов. Мобильное устройство может сохранять статус, связанный с токеном, в памяти для токенов.
[0010] Согласно различным вариантам осуществления сообщение с запросом токена может быть отправлено на серверный компьютер токенов через модуль токенов, предусмотренный на мобильном устройстве, и токен, связанный с зашифрованными данными пользователя, принимается с серверного компьютера токенов модулем токенов.
[0011]В некоторых вариантах осуществления способ также включает взаимодействие с устройством доступа для инициирования транзакции с использованием мобильного приложения, предусмотренного на мобильном устройстве. Способ дополнительно включает предоставление токена устройству доступа. Токен предоставляется устройству доступа модулем токенов минуя мобильное приложение. Модуль токенов хранится на мобильном устройстве.
[0012]В некоторых вариантах осуществления сообщение с запросом токена может быть отправлено на серверный компьютер токенов через удаленный сервер мобильных приложений, и токен, связанный с зашифрованными данными пользователя, может быть принят с серверного компьютера токенов через удаленный сервер мобильных приложений.
[0013]Эти и другие варианты осуществления более подробно описаны ниже.
КРАТКОЕ ОПИСАНИЕ ГРАФИЧЕСКИХ МАТЕРИАЛОВ
[0014]На фиг. 1 показана приведенная в качестве примера система обработки токена согласно варианту осуществления настоящего изобретения.
[0015]На фиг. 2 показана функциональная схема способа предоставления зашифрованных данных пользователя мобильному устройству для предоставления токена на мобильное устройство и использования токена для выполнения транзакции согласно варианту осуществления настоящего изобретения.
[0016]На фиг. 3 показан ряд снимков экрана, на которых показана конфигурация покупателя и процесс выполнения платежа с использованием мобильного приложения, выполненного с возможностью использования с системой обработки токена, согласно варианту осуществления настоящего изобретения.
[0017]На фиг. 4 показана первая приведенная в качестве примера конфигурация интеграции, когда SDK токенов непосредственно связывается с серверным компьютером токенов с использованием интерфейсов API серверного компьютера токенов, согласно варианту осуществления настоящего изобретения.
[0018]На фиг. 5 показана функциональная схема приведенного в качестве примера способа аутентификации для системы с первой приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции SDK с серверным компьютером токенов, проиллюстрированной на фиг. 4.
[0019]На фиг. 6 показана функциональная схема приведенного в качестве примера способа предоставления для системы с первой приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции SDK с серверным компьютером токенов, проиллюстрированной на фиг. 4.
[0020]На фиг. 7 показана функциональная схема приведенного в качестве примера способа продления динамических параметров для системы с первой приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции SDK с серверным компьютером токенов, проиллюстрированной на фиг. 4.
[0021]На фиг. 8 показана функциональная схема приведенного в качестве примера способа приостановления для системы с первой приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции SDK с серверным компьютером токенов, проиллюстрированной на фиг. 4.
[0022]На фиг. 9 показана вторая приведенная в качестве примера конфигурация интеграции, когда компьютер поставщика мобильных приложений (MAP) непосредственно связывается с серверным компьютером токенов с использованием интерфейсов API серверного компьютера токенов, согласно приведенному в качестве примера варианту осуществления настоящего изобретения.
[0023]На фиг. 10 показана функциональная схема приведенного в качестве примера способа аутентификации для системы со второй приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции компьютера MAP с серверным компьютером токенов, проиллюстрированной на фиг. 9.
[0024]На фиг. 11 показана функциональная схема приведенного в качестве примера способа предоставления для системы со второй приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции компьютера MAP с серверным компьютером токенов, проиллюстрированной на фиг. 9.
[0025]На фиг. 12 показана функциональная схема приведенного в качестве примера способа продления динамических параметров для системы со второй приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции MAP компьютера с серверным компьютером токенов, проиллюстрированной на фиг. 9.
[0026]На фиг. 13 показана функциональная схема приведенного в качестве примера способа приостановления для системы со второй приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции компьютера MAP с серверным компьютером токенов, проиллюстрированной на фиг. 9.
[0027]На фиг. 14 показана схема, представляющая компоненты в компьютерной системе.
ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
[0028]Для выполнения транзакции, осуществляющей доступ к ресурсу, конфиденциальные данные пользователя (например, номер счета, номер социального страхования, идентификационный номер и т. д. пользователя) могут быть предоставлены предоставляющему ресурс субъекту. Такие конфиденциальные данные пользователя могут присутствовать на мобильном устройстве, если указанное мобильное устройство используется для осуществления доступа к ресурсу, предоставляемому предоставляющим ресурс субъектом. Например, пользователь мобильного устройства может пожелать провести транзакцию с помощью мобильного устройства. Мобильное устройство должно быть выполнено с возможностью осуществления доступа к конфиденциальным данным пользователя для проведения транзакции. Если конфиденциальные данные пользователя находятся на мобильном устройстве, существует вероятность их получения неуполномоченным лицом.
[0029]Варианты осуществления настоящего изобретения относятся к защищенным способам получения и хранения конфиденциальных данных пользователя на мобильном устройстве, а также к эффективным способам передачи данных пользователя субъектам, вовлеченным в обеспечение безопасности данных пользователя для транзакций с использованием мобильного устройства, а также от указанных субъектов. Варианты осуществления предотвращают получение мобильным устройством доступа к конфиденциальным данным пользователя в незашифрованном формате и/или их хранение. По существу данные пользователя защищены от неуполномоченных лиц даже если мобильное устройство утеряно, украдено, взломано или другим образом повреждено.
[0030]Согласно вариантам осуществления на мобильное устройство предоставляют зашифрованные данные пользователя. Модуль токенов (т. е., комплект разработки программного обеспечения (SDK) для токенов), предусмотренный на мобильном устройстве, может получать токен, представляющий данные пользователя. SDK для токенов может получить токен с путем прямого взаимодействия с серверным компьютером токенов, который генерирует токен. Альтернативно SDK для токенов может взаимодействовать с компьютером поставщика мобильных приложений (MAP) и отправлять запрос на компьютер MAP для получения токена с серверного компьютера токенов.
[0031]Компьютер MAP может создавать мобильное приложение (например, программное приложение с возможностью выполнения платежей) на мобильном устройстве. В некоторых вариантах осуществления мобильное приложение может производить платежи на основе хост-эмуляции банковской карты (HCE) в точке продажи (POS) посредством SDK для токенов. Например, варианты осуществления могут быть использованы для выполнения платежной транзакции на основе ближней бесконтактной связи (NFC) на устройстве доступа, таком как POS продавца, с использованием токена, сгенерированного серверным компьютером токенов (также называемым службой токенов и/или системой токенов). После генерирования токен может быть доставлен на мобильное устройство.
[0032]Токен может заменять конфиденциальные данные пользователя. Например, токен может содержать любые данные, которые представляют пользователя или связаны с ним, такие как идентификатор расчетного счета, выданный банком эмитента, номер социального страхования пользователя, идентификационный номер пользователя, которые дают возможность пользователю осуществлять доступ к защищенным хранилищам документов, защищенным зданиям и т. д. В частности, токен, предоставленный серверным компьютером токенов, может представлять счет пользователя для определенного мобильного приложения, предусмотренного на мобильном устройстве пользователя. Согласно некоторым вариантам осуществления множество токенов могут быть связаны с одним счетом. Токены снижают риск того, что конфиденциальные данные пользователя будут использованы в мошеннических целях.
[0033]Перед обсуждением вариантов осуществления изобретения для понимания вариантов осуществления настоящего изобретения может быть полезным описание некоторых терминов.
[0034]В контексте данного документа «мобильное устройство» может включать любое устройство, которое содержит один или более электронных компонентов (например, интегральную схему), которые могут осуществлять связь с другим устройством. «Портативное устройство связи» может представлять собой мобильное устройство, которое может переносить и которым может управлять пользователь. Портативное устройство связи может обеспечивать возможности удаленной связи c сетью. Портативное устройство связи может быть выполнено с возможностью передачи и получения данных или сообщений на другие устройства и от них. Портативное устройство связи может иметь вид мобильного устройства, такого как мобильный телефон (например, смартфон, сотовый телефон и т. д.), планшетных устройств, передвижного транспортного средства, такого как автомобиль, портативного медиа-плеера, карманных персональных компьютерных устройств (PDA), носимых вычислительных устройств (например, смарт-часов, фитнес-лент, электронных браслетов, колец, серег и т. д.), электронного считывающего устройства и т. д., или вид карты (например, смарт-карты) или брелока и т. д. Примеры портативных устройств связи могут также включать портативные вычислительные устройства (например, ноутбуки, нетбуки, ультрабуки и т. д.).
[0035]«Платежное устройство» может включать любое устройство, которое может быть использовано для проведения финансовой транзакции так, чтобы предоставлять информацию о расчетном счете продавцу. Платежное устройство может иметь любую подходящую форму. Например, подходящие платежные устройства могут быть ручными и компактными, так что они могут помещаться в кошельке и/или кармане покупателя (например, они могут быть карманного формата). Они могут включать смарт-карты, карты с магнитной полосой, устройства типа брелока (такие как Speedpass™, поставляемые на рынок компанией Exxon-Mobil Corp.) и т. п. Другие примеры платежных устройств включают сотовые телефоны, карманные персональные компьютеры (PDA), пейджеры, платежные карты, карты безопасности, карты доступа, флеш-карты, ретрансляторы, двумерные штрих-коды, электронный или цифровой кошелек и т. п. Если платежное устройство имеет форму дебетовой, кредитной или смарт-карты, платежное устройство также необязательно может иметь такие признаки, как магнитные полосы. Такие устройства могут работать или в контактном, или в бесконтактном режиме. Согласно различным вариантам осуществления мобильное устройство может быть использовано в качестве платежного устройства.
[0036]«Расчетный счет» или «счет» (который может быть связан с одним или более платежными устройствами) может включать любой подходящий расчетный счет, включая счет кредитной карты, текущий счет или предоплаченный счет.
[0037]«Информация о счете» может включать любую подходящую информацию, связанную со счетом (например, расчетным счетом и/или платежным устройством, связанным со счетом). Такая информация может непосредственно относиться к счету или может быть получена из информации, относящейся к счету. Примеры информации о расчетном счете могут включать номер основного счета (PAN) или «номер счета», имя пользователя, дату завершения срока действия, CVV (проверочный параметр карты), dCVV (динамический проверочный параметр карты), CVV2 (2 проверочный параметр карты), проверочные параметры карты CVC3 и т. д. Под CVV2 обычно понимают статический проверочный параметр, связанный с платежным устройством. Коды CVV2 обычно видны пользователю (например, покупателю), тогда как параметры CVV и dCVV, как правило, встроены в память или сообщения с запросом авторизации и абсолютно неизвестны пользователю (хотя они известны эмитенту и платежным операторам). Информация о расчетном счете может также быть использована в качестве аутентификационных данных.
[0038]«Токен» может включать любой идентификатор для расчетного счета, являющийся заменой для других данных. Например, токен может включать ряд цифробуквенных символов, который может быть использован в качестве замены оригинального идентификатора счета. Например, токен может быть использован вместо идентификатора основного счета или номера основного счета (PAN). В некоторых вариантах осуществления токен может быть «сохраняющим формат»; он может иметь численный формат, который соответствует идентификаторам счетов, используемым в существующих сетях обработки платежей. В некоторых вариантах осуществления токен может содержать те же элементы в том же порядке, что и PAN. В других вариантах осуществления токен может иметь тот же размер, что и PAN, но может содержать другие элементы или элементы других размеров. В некоторых вариантах осуществления токен может быть использован вместо PAN для запуска, авторизации, проведения или завершения платежной транзакции или представления оригинального идентификатора счета в других системах, в которых обычно был бы использован оригинальный идентификатор счета (например, PAN).
[0039]В некоторых вариантах осуществления значение токена может быть сгенерировано так, что оригинальный PAN или другой идентификатор счета, связанный со значением токена, не может быть произведен вычислительным путем только из токена. Например, токен может содержать случайно сгенерированное значение, связанное с оригинальным PAN в таблице преобразования, так что токен не может быть расшифрован, переформатирован или другим образом обратно разработан для определения оригинального PAN. Кроме того, в некоторых вариантах осуществления непосредственное или опосредованное знание таблицы преобразования может быть единственным способом определения оригинального PAN, соответствующего токену. В некоторых вариантах осуществления субъект, который поддерживает упомянутую выше таблицу преобразования, может быть назван «хранилищем токенов».
[0040]В некоторых вариантах осуществления токены могут быть зависящими от устройства, так что каждое устройство, связанное со счетом, может быть снабжено отдельным токеном. По сути, если транзакция использует токен, который инициируется устройством, отличным от устройства, на которое был предоставлен токен, транзакция может быть мошеннической. Соответственно, информация об устройстве может быть сохранена в хранилище токенов и использована для обеспечения гарантии того, что устройство, используемое в транзакции, связано с токеном, используемым в транзакции. Дополнительно, поскольку каждый токен может быть связан с единственным устройством, один PAN или счет может иметь множество токенов, связанных с ним, при этом каждый PAN может иметь разный токен для разных устройств, которые могут быть использованы для инициирования транзакции, связанной с PAN, с использованием определенного токена. Это обеспечивает дополнительную защиту для транзакций, поскольку системы токенов сети имеют дополнительную информацию для проверки подлинности с целью управления использованием конфиденциальной информации в системе обработки транзакций.
[0041]Токен может обладать рядом характеристик токенов, которые предотвращают использование не по назначению. Данные характеристики могут включать использование ключа ограниченного использования (LUK), который может быть использован для создания удостоверяющих данных, которые аутентифицируют пользователя во время осуществления транзакции. Дополнительно использование токена может быть ограничено устройством пользователя, на котором может быть использован токен. Кроме того, использование токена может быть ограничено несколькими разами, когда может быть использован LUK. Соответственно, ограничение счетчика транзакции снижает вероятность того, что токен может быть использован не по назначению многократно. Кроме того, токен может быть ограничен в продолжительности. Например, токен может быть ограничен сроком действия LUK, который предотвращает использование токена дольше заданной продолжительности. Это может предотвращать использование токена не по назначению в течение длительного периода времени.
[0042]Кроме того, использование токена может быть ограничено определенным каналом связи. Например, серверный компьютер токенов может ограничивать путь, по которому может быть передан токен, например, посредством ограничения использования токена до транзакций на основе NFC или на основе POS. Это может предотвращать использование токена вне его предназначенных канала связи или области. Дополнительные ограничения включают ограничения величины, когда серверный компьютер токенов ограничивает величину значения, для которого может быть использован токен. Таким образом, ограничение величины снижает риск посредством предотвращения использования токена, ограниченного транзакциями небольшой величины, для совершения более крупных покупок. Кроме того, серверный компьютер токенов может ограничивать токены конкретными продавцами, у которых может быть принят токен, что предотвращает использование токена не по назначению у других продавцов.
[0043]Операции в отношении токенов могут быть разделены на несколько категорий: (1) предоставление, которое включает получение токена и активацию токена на мобильном устройстве; (2) управление активными ключами, которое включает управление ключом ограниченного использования (LUK) для непрерывного процесса выполнения платежа покупателя; и (3) управление временем существования, которое включает определение статуса токена и приостановление, возобновление или удаление токена.
[0044]Предоставление включает генерирование, доставку и хранение токена на мобильном устройстве. Например, токен может представлять номер счета (PAN). Серверный компьютер токенов может предоставлять токен для каждого счета для мобильного приложения и мобильного устройства. Чтобы мобильное приложение использовало токен, токен может быть предоставлен для мобильного приложения на мобильном устройстве. Эмитент платежного инструмента может авторизовать поставщика мобильных приложений для запроса и управления токенами, связанными со счетом эмитента. Серверный компьютер токенов может включать процесс регистрации счета (открытия нового счета), который включает сбор информации об организации поставщика мобильных приложений и разрешение на проведение проверки соответствия. Поставщику мобильных приложений может быть назначен ID поставщика, идентификатор инициатора запроса токена и другие уникальные идентификаторы, связанные с операциями серверного компьютера токенов во время регистрации.
[0045]Управление активными ключами включает управление и обновление ключей ограниченного использования (LUK), связанных с токенами. Например, когда токен был предоставлен для устройства, LUK может поддерживаться актуальным для обеспечения возможности обработки транзакций с использованием токена. В некоторых случаях LUK может быть действительным на протяжении расширенного периода времени, подобно карте, выдаваемой на год или более. В некоторых вариантах осуществления LUK может иметь короткий срок действия и может требовать регулярного продления. Если предоставленный токен все еще предоставлен на устройстве, его динамические данные могут периодически продлеваться, что означает, что LUK, связанный с токеном, обновляется для увеличения его срока действия.
[0046]Управление временем существования может включать любые действия для обновления статуса и/или конфигурации токена. Например, оно может быть необходимо для изменения статуса токена. Например, мобильное приложение может предоставлять владельцу счета возможность удаления счета, в этом случае мобильное приложение может удалить токен, представляющий счет. Чтобы позже добавить счет потребуется повторное предоставление токена.
[0047]«Сообщение с запросом на предоставление токена» может представлять собой электронное сообщение, отправляемое для запроса на предоставление токена на мобильном устройстве. Сообщение с запросом на предоставление токена может быть отправлено на серверный компьютер токенов. Сообщение с запросом на предоставление токена может содержать информацию, которая может быть использована для идентификации счета. Сообщение с запросом на предоставление токена может также содержать дополнительные элементы данных, такие как одно или более из кода услуги, даты завершения срока действия и т. д.
[0048]«Сообщение с ответом предоставления токена» может представлять собой ответ в виде электронного сообщения на сообщение с запросом на предоставление токена. Сообщение с ответом предоставления токена может быть сгенерировано серверным компьютером токенов. Сообщение с ответом предоставления токена может содержать токен, выданный в ответ на сообщение с запросом на предоставление токена.
[0049]Термин «транзакция» может включать обмен или взаимодействие между двумя субъектами. В некоторых вариантах осуществления транзакция может относится к переводу величины между двумя пользователями (например, физическими лицами или субъектами). Транзакция может включать обмен денежными средствами, обмен товарами или услугами за денежные средства, обмен данными (например, данными доступа) между двумя сторонами. В других вариантах осуществления транзакция может включать покупку товаров или услуг физическим лицом или субъектом у продавца или другого субъекта за денежные средства. В других вариантах осуществления транзакция может представлять собой не связанный с финансами запрос, такой как обмен данными или информацией между двумя субъектами, например, передача данных.
[0050]Термин «данные о транзакции» может включать информацию, относящуюся к транзакции. Данная информация может содержать данные для финансовой транзакции (например, платежные данные, общий итог транзакции, данные о потребителе). Данные о транзакции могут быть использованы для обработки финансовой транзакции. Данные о транзакции могут включать данные для конкретной транзакции, включая покупаемый товар, цены на товар, общую стоимость, данные о потребителе (например, адрес доставки, адрес электронной почты), способы оплаты, аутентификационные данные, данные о продавце (например, название продавца, месторасположение/адрес продавца) и т. д. В некоторых вариантах осуществления данные о транзакции могут быть сгенерированы после попытки пользователя или покупателя передать транзакцию на обработку. В других вариантах осуществления данные о транзакции могут быть сгенерированы и отправлены системой продавца на основе товаров, добавленных в корзину покупателя. В некоторых вариантах осуществления данные о транзакции могут содержать информацию для нефинансовой транзакции (например, данные с предупреждением, данные с побуждением, данные о продукте и т. д.). Данные о транзакции могут иметь любой подходящий формат и могут содержать любую подходящую информацию в зависимости от цели транзакции.
[0051]Данные о транзакции могут быть включены в сообщение авторизации транзакции и/или сообщение клиринга и расчетов по транзакции. В некоторых вариантах осуществления данные о транзакции могут быть отправлены в режиме реального времени при выполнении транзакции. В некоторых вариантах осуществления данные о транзакции могут быть отправлены после завершения или выполнения транзакции. В некоторых вариантах осуществления данные о транзакции могут быть отправлены в сеть обработки платежей.
[0052]В контексте данного документа «серверный компьютер», как правило, представляет собой мощный компьютер или кластер компьютеров. Например, серверный компьютер может представлять собой крупный универсальный компьютер, кластер миникомпьютеров или группу серверов, функционирующих как один элемент. В одном примере серверный компьютер может представлять собой сервер баз данных, подключенный к веб-серверу.
[0053]«Эмитент» может, как правило, относиться к субъекту предпринимательства (например, банку), который поддерживает счет для пользователя, который связан с портативным устройством связи.
[0054]«Продавец», как правило, может представлять собой субъект, который вовлечен в транзакции и может продавать товары или услуги или предоставлять доступ к товарам или услугам.
[0055]«Эквайер» может, как правило, представлять собой субъект предпринимательства (например, коммерческий банк), который имеет коммерческую связь с конкретным продавцом или другим субъектом. Некоторые субъекты могут выполнять функции как эмитента, так и эквайера. Некоторые варианты осуществления могут охватывать такие единые субъекты эмитента-эквайера.
ОБЗОР СИСТЕМЫ
[0056]Варианты осуществления могут быть исполнены с использованием системы 100 обработки токена, как проиллюстрировано на фиг. 1. Система обработки токена предоставляет зашифрованные данные пользователя (например, информацию о платеже, номер социального страхования, идентификационный номер и т. д.) на мобильное устройство согласно приведенному в качестве примера варианту осуществления настоящего изобретения. Система 100 может включать мобильное устройство 110, компьютер 140 поставщика мобильных приложений (MAP) и серверный компьютер 160 токенов. Как представлено на фиг. 1, серверный компьютер 160 токенов может быть частью сети 170 обработки платежей. В некоторых вариантах осуществления серверный компьютер 160 токенов может представлять собой отдельный компьютер вне и в электронной связи с сетью 170 обработки платежей.
[0057]Мобильное устройство 110 может содержать мобильное приложение 111. Мобильное приложение 111 может быть предоставлено на мобильное устройство 110 компьютером 140 MAP. Мобильное устройство 110 может также содержать комплект 112 разработки программного обеспечения для системы токенов (SDK для токенов), который может получать и безопасно сохранять токены и/или другую защищенную информацию. В некоторых вариантах осуществления токены могут быть сохранены в памяти 113 для токенов.
[0058]Компьютер 140 MAP может предоставлять обслуживание для пользователей мобильных устройств. Например, компьютер 140 MAP может представлять собой поставщика мобильного кошелька, эмитента, продавца или любого другого подходящего субъекта, который предоставляет цифровой контент, приложения или услуги пользователям мобильных/сотовых устройств. Например, компьютер 140 MAP может разрабатывать, создавать и/или предоставлять мобильное приложение 111 для мобильного устройства 110. Например, мобильное приложение 111 может включать приложение мобильного кошелька, приложение эмитента, приложение продавца и т. д., которые могут быть скачаны, установлены и использованы на мобильном устройстве 110. Мобильное приложение 111 может предоставлять пользовательский интерфейс для различных функций, таких как мобильные платежи, работа со счетом (например, запрос баланса, клиентское обслуживание и т. д.), денежные переводы от человека человеку (P2P) или любая другая соответствующая функция или возможность, связанная с поставщиком услуг и/или компьютером 140 MAP.
[0059]Компьютер 140 MAP может также сохранять конфиденциальные данные пользователя (например, информацию о платеже, номер социального страхования, идентификационный номер и т. д.), связанные с пользователем мобильного устройства 110. Компьютер 140 MAP может также сохранять ключ шифрования, связанный с серверным компьютером 160 токенов (и/или предоставленный им). Компьютер 140 MAP может использовать ключ шифрования для шифрования данных пользователя и предоставлять зашифрованные данные пользователя на мобильное устройство 110.
[0060]Мобильное устройство 110 может предоставлять зашифрованные данные пользователя на серверный компьютер 160 токенов, чтобы получать токен, представляющий зашифрованные данные пользователя. Например, когда зашифрованные данные пользователя содержат информацию о платеже (например, номер расчетного счета), токен может представлять собой платежный токен, который действует как посредник для информации о платеже. То есть, токен может быть предоставлен для транзакции вместо действительной информации о платеже.
[0061]Согласно вариантам осуществления настоящего изобретения токен (токены) может быть предоставлен на мобильном устройстве 110 двумя способами: SDK 112 для токенов может находиться в непосредственной связи 182 с серверным компьютером 160 токенов (через программные интерфейсы 180 приложений (API) серверного компьютера токенов) для запроса и приема токена (токенов) с серверного компьютера 160 токенов. Альтернативно SDK 112 для токенов может отправлять на компьютер 140 MAP запрос на извлечение токена (токенов) с серверного компьютера 160 токенов. В последнем случае компьютер 140 MAP может находиться в непосредственной связи 184 с серверным компьютером 160 токенов (через интерфейсы API 180 серверного компьютера токенов) для запроса и приема токена (токенов) с серверного компьютера 160 токенов.
[0062]Серверный компьютер 160 токенов может представлять собой сервер, выполненный с возможностью приема запроса токена (также называемого запросом на предоставление токена или сообщением с запросом токена), расшифровки зашифрованных данных пользователя, включенных в запрос токена, идентификации счета (например, расчетного счета), связанного с данными пользователя, генерирования токена, связанного со счетом, сохранения токена и/или предоставления токена на мобильное устройство 110. Серверный компьютер 160 токенов может быть связан с сетью 170 обработки платежей (например, VisaNet™, MasterCard™ и т. д.) или любым другим подходящим субъектом. Серверный компьютер 160 токенов может генерировать и/или принимать криптографические ключи для шифрования и расшифровки данных пользователя, включенных в запрос на предоставление токена. Серверный компьютер 160 токенов может также предоставлять один или более криптографических ключей компьютеру 140 MAP, так что компьютер 140 MAP может шифровать данные пользователя с использованием криптографических ключей, предоставленных серверным компьютером 160 токенов.
[0063]Серверный компьютер 160 токенов может также содержать или осуществлять связь с хранилищем 162 токенов, которое хранит статус токена для различных токенов, управляемых серверным компьютером 160 токенов, в базе данных о статусах токена. Статус токена может быть любым из активного, приостановленного, устаревшего, удаленного и/или не найденного. База данных о статусах токена может хранить записи, связанные с токенами, такие как данные пользователя и/или информация о счете, связанная с токеном, служебная информация о токенах, и/или является ли определенный токен активным, приостановленным, рассматриваемым, отмененным и т. д. Токен, сгенерированный серверным компьютером 160 токенов, может быть предоставлен на SDK 112 для токенов, предусмотренный на мобильном устройстве 110. SDK 112 для токенов может сохранять токен в памяти 113 для токенов.
[0064]Серверный компьютер 160 токенов может использовать ряд средств управления защитой для усиления и защиты SDK 112 для токенов от атак и обратной разработки. Одной из мер защиты является использование криптографии типа «белый ящик» (WBC) для защиты ключей и конфиденциальных данных токена. WBC необходима по причине работы мобильного устройства 110 в ненадежной, открытой среде, которая может быть видна третьим сторонам. WBC защищает ресурсы SDK 112 для токенов посредством запутывания данных и кода путем использования дополнительных криптографических технологий для изменения ключа и соответствующих операций так, чтобы конфиденциальные данные не могли быть раскрыты в такой среде.
[0065]SDK 112 для токенов может содержать любой программный интерфейс приложений (API), службу, приложение, апплет или другой исполняемый код, подходящий для осуществления связи с мобильным приложением 111 и/или серверным компьютером 160 токенов. SDK 112 для токенов может быть связан с серверным компьютером 160 токенов, сетью 170 обработки платежей или любым другим подходящим субъектом. SDK 112 для токенов может быть выполнен с возможностью предоставления мобильному приложению 111 возможности соединения с серверным компьютером 160 токенов. Таким образом, SDK 112 для токенов может принимать команды, связанные с серверным компьютером 160 токенов, из мобильного приложения 111 и может быть выполнен с возможностью приема зашифрованных данных пользователя (например, зашифрованной информации о платеже) из компьютера 140 MAP через мобильное приложение 111. SDK 112 для токенов может соединяться с серверным компьютером 160 токенов через интерфейсы API 180 серверного компьютера токенов для обработки и сохранения токена в памяти 113 для токенов. Память 113 для токенов может представлять собой память на мобильном устройстве 110 для хранения зашифрованных данных пользователя, токенов (например, платежных токенов) и любой другой подходящей информации. Память 113 для токенов может быть безопасной для хранения информации о платеже.
[0066]SDK 112 для токенов может находиться в непосредственной связи 182 с серверным компьютером 160 токенов (через интерфейсы API 180 серверного компьютера токенов) и запрашивать платежные токены с серверного компьютера 160 токенов. Более того, SDK 112 для токенов может быть выполнен с возможностью предоставления информации о платеже для мобильной платежной транзакции в ответ на запрос с мобильного приложения 111 для завершения платежной транзакции посредством устройства 120 доступа.
[0067]Согласно различным вариантам осуществления действительные токены могут быть сохранены безопасно в памяти 113 для токенов и могут не быть раскрыты мобильному приложению 111. Вместо этого SDK 112 для токенов может генерировать ключ токена для каждого токена. Ключ токена может представлять собой уникальный номер, символ, строку или их комбинацию, которая идентифицирует токен в памяти 113 для токенов. Однако ключ токена не может быть использован вместо токена. Например, если ключ токена генерируется для платежного токена, ключ токена не может быть использован для проведения платежной транзакции. Ключ токена может быть предоставлен на мобильное приложение 111. Мобильное приложение 111 может предоставлять ключ токена на SDK 112 для токенов во время транзакции и отправлять на SDK 112 для токенов запрос на извлечение платежного токена из памяти 113 для токенов (или автоматически приводить к этому). Соответственно, мобильное приложение не может иметь доступ к данным пользователя в расшифрованном формате или токену, представляющему данные пользователя. Это может предотвратить несанкционированный доступ к защищенным данным, когда мобильное устройство утеряно, украдено или нарушена его безопасность. SDK 112 для токенов может управлять данными токена, например, для (1) идентификации определенного токена на основе запроса от мобильного приложения 111, (2) проведения транзакции от имени мобильного приложения 111 с использованием токена, (3) отправки запросов на серверный компьютер 160 токенов и/или (4) управления временем существования токенов, включая использование ключей ограниченного использования (LUK).
[0068]В некоторых вариантах осуществления SDK 112 для токенов может обладать различными возможностями. Например, SDK 112 для токенов может (1) предоставлять сервис оркестровки, который удовлетворяет потребностям мобильного устройства 110 с использованием интерфейсов API 180 серверного компьютера токенов; (2) предоставлять возможность осуществления связи между мобильным устройством 110 и устройством 120 доступа с использованием стандартов мобильного приложения (например, Visa™ payWave™); (3) предоставлять идентификационную информацию устройства, чтобы гарантировать, что токен связан с определенным мобильным устройством; и (4) управлять сохраненным токеном и связанными параметрами счета (например, с использованием ключа токена), данными пользователя и авторизацией API и шифрованием канала. В целом, SDK 112 для токенов может обеспечивать защиту конфиденциальных данных токена. SDK 112 для токенов может объединять множество функциональных компонентов, которые реализуют эти вышеперечисленные возможности в рамках SDK 112 для токенов, или может обеспечивать разделение возможностей для обеспечения их независимой доступности таким образом, что каждый компонент может быть реализован в виде плагина, например, плагина хранения, от третьей стороны.
[0069]Согласно различным вариантам осуществления возможности SDK 112 для токенов могут обеспечивать пользователю мобильного устройства: (1) добавление расчетного счета (например, кредитной или дебетовой карты) на мобильное устройство; (2) использование расчетного счета для проведения транзакции на устройстве доступа (например, с использованием возможности NFC); (3) отмену платежной транзакции (например, при возврате купленного ранее товара); и (4) удаление токена, ранее предоставленного на мобильное устройство, без необходимости отмены и повторного выпуска платежного устройства. SDK 112 для токенов может использовать интерфейсы API 180 серверного компьютера токенов для управления этими вышеперечисленными операциями, относящимися к управлению приложением и токеном.
[0070]В некоторых вариантах осуществления способ проверки статуса может быть выполнен для проверки статуса токена. Данные о статусе могут быть извлечены и возвращены в SDK 112 для токенов, так что статусы токена могут быть сохранены локально. Статус токена может быть любым из активного, приостановленного, устаревшего, удаленного и/или не найденного. Статус токена может быть сохранен в базе данных статусов токена в памяти 113 для токенов. База данных статусов токена может периодически или постоянно обновляться с информацией о статусе токена. Например, если сообщается, что безопасность токена нарушена, база данных статусов токена может обновлять запись для указанного токена.
[0071]SDK 112 для токенов может периодически запрашивать информацию о статусе токена у серверного компьютера 160 токенов. SDK 112 для токенов может отправлять сообщение с запросом о статусе токена, включая один или более токенов или ключей токена, сохраненных в памяти 113 для токенов. Серверный компьютер 160 токенов может идентифицировать статус одного или более токенов в базе данных статусов токена и может предоставлять информацию о статусе токена на SDK 112 для токенов. SDK 112 для токенов может затем сохранять информацию о статусе токена в памяти 113 для токенов. Таким образом, мобильное устройство 110 может поддерживать обновленную информацию о статусе любых сохраненных токенов.
[0072]В некоторых вариантах осуществления SDK 112 для токенов может запрашивать обновления статуса токена после определенного, предварительно заданного периода времени (например, 1 недели или 2 месяцев). В некоторых вариантах осуществления SDK 112 для токенов может запрашивать обновления статуса токена по истечении срока действия токена или после определенного числа применений. В некоторых вариантах осуществления, если статус токена указывает на то, что токен приостановлен и находится на рассмотрении, SDK 112 для токенов может осуществлять проверку обновлений статуса с сервера 160 токенов чаще. В некоторых вариантах осуществления сервер 160 токенов может без запроса отправлять обновления статуса токена на мобильное устройство 110.
[0073]В некоторых вариантах осуществления срок действия токена может истекать после определенного периода времени или определенного числа применений, и SDK 112 для токенов может извлекать токен замены с сервера 160 токенов.
СПОСОБЫ ПРЕДОСТАВЛЕНИЯ ТОКЕНА (ТОКЕНОВ) НА МОБИЛЬНОМ УСТРОЙСТВЕ
[0074]Как предусмотрено выше, системы, проиллюстрированные на фиг. 1, могут быть использованы для предоставления токена (токенов) на мобильном устройстве 110. Согласно различным вариантам осуществления компьютер 140 MAP может предоставлять зашифрованные данные пользователя на мобильное устройство 110. Мобильное устройство 110 может запрашивать у серверного компьютера 160 токенов токен, представляющий зашифрованные данные пользователя. Мобильное устройство 110 может запрашивать токен у серверного компьютера 160 токенов через SDK 112 для токенов или компьютер 140 MAP. Токен может затем быть использован для проведения транзакций с использованием мобильного устройства 110. Соответственно, конфиденциальные данные пользователя никогда не предоставляются на мобильное устройство 110 в незашифрованном формате и/или не хранятся на нем. Таким образом, данные пользователя защищены от попыток несанкционированного доступа или при утере или краже мобильного устройства 110
[0075]На фиг. 2 показана функциональная схема способа предоставления зашифрованных данных пользователя мобильному устройству для предоставления токена на мобильное устройство и использования токена для выполнения транзакции согласно приведенному в качестве примера варианту осуществления настоящего изобретения. Функциональная схема, проиллюстрированная на фиг. 2, может быть разделена на три фазы: фаза 250 аутентификации пользователя, фаза 252 предоставления токена и фаза 254 проведения транзакции.
[0076]Фаза 250 аутентификации пользователя может начинаться на этапе 202, когда пользователь мобильного устройства 110 входит в мобильное приложение 111. Например, пользователь может предоставить удостоверяющие данные (например, имя пользователя и пароль) на мобильное приложение 111. Мобильное приложение 111 может отправлять удостоверяющие данные пользователя на компьютер 140 MAP для аутентификации. Компьютер 140 MAP может аутентифицировать удостоверяющие данные в отношении сохраненного набора удостоверяющих данных пользователя, который может быть создан, когда пользователь предварительно регистрируется с помощью компьютера 140 MAP.
[0077]Фаза 250 аутентификации пользователя может продолжаться на этапе 204, когда компьютер 140 MAP отправляет ответ на мобильное приложение 111 с подтверждением того, что пользователь был аутентифицирован. Например, компьютер 140 MAP может отправлять криптограмму (например, зашифрованную строку, идентификационный токен пользователя или веб-токен JSON (JWT токен)) на мобильное приложение 111, которая подтверждает личность пользователя 101. Компьютер 140 MAP может предоставить на мобильное приложение 111 множество криптограмм. Каждая криптограмма может быть связана с частью конфиденциальных данных пользователя, такой как номер счета, номер социального страхования, идентификационный номер и т. д.
[0078]На этапе 206 мобильное приложение 111 может отправлять запрос в SDK 112 для токенов на аутентификацию пользователя с помощью криптограммы. SDK 112 для токенов может затем отправлять криптограмму на серверный компьютер 160 токенов.
[0079]Фаза 250 аутентификации пользователя может завершаться на этапе 208, когда после успешной аутентификации криптограммы серверным компьютером 160 токенов серверный компьютер 160 токенов отвечает SDK 112 для токенов с помощью токена доступа. Токен доступа может отличаться от платежного токена. Токен доступа не может быть использован для проведения платежной транзакции. Вместо этого SDK 112 для токенов может управлять токеном доступа, и последний может предоставлять мобильному приложению 111 возможность осуществления доступа к серверному компьютеру 160 токенов в течение определенного периода времени (также называемого временем существования (TTL)). Токен доступа может связывать криптограмму (например, JWT), предоставленную компьютером 140 MAP, с мобильным приложением 111, запрашивающим системное взаимодействие с применением токена. Это связывание может предоставлять возможность компьютеру 140 MAP улучшать восприятие пользователя и контролировать его. Компьютер 140 MAP может также выбирать, когда производить аутентификацию потребителя (при истечении TTL для токена доступа) для продолжения использования серверного компьютера 160 токенов.
[0080]На фиг. 3 представлены снимки экранов мобильного приложения 111 для ряда этапов, описанных в связи с фиг. 2. А именно, на фиг. 3 представлен ряд снимков экрана, на которых показана конфигурация пользователя и процесс выполнения платежа с использованием мобильного приложения, выполненного с возможностью использования с системой обработки токена, согласно приведенному для примера варианту осуществления настоящего изобретения.
[0081]На первом снимке экрана, представленном на фиг. 3, показан экран 302 входа, соответствующий этапу 202, представленному на фиг. 2. На экране 302 входа пользователь может ввести свои удостоверяющие данные, такие как имя пользователя и пароль, для получения доступа/входа в мобильное приложение 111. Когда пользователь предоставляет свои удостоверяющие данные на экране 302 входа, этапы 204-208 фазы аутентификации, описанные выше, могут происходить в фоновом режиме, т. е. экран мобильного устройства может не отображать эти этапы.
[0082]После аутентификации токен доступа может быть создан SDK 112 для токенов на мобильном устройстве 110 для идентификации пользователя в других вызовах через SDK 112 для токенов. Применение токена доступа может быть видимым мобильному приложению 111. Однако мобильное приложение 111 может поддерживать существование токена доступа путем повторной аутентификации пользователя до истечения срока действия токена доступа.
[0083]Фаза 252 предоставления токена, представленная на фиг. 2, описана далее.
[0084] Фаза 252 предоставления токена может начинаться на этапе 210, на котором пользователь 101 выбирает данные пользователя, которые необходимо предоставить токеном (токенами), из списка доступных данных пользователя, отображаемого посредством мобильного приложения 111. Например, пользователь может захотеть предоставить один или несколько номеров счетов на мобильном устройстве 110. Мобильное приложение 111 может отображать список доступных номеров счетов для предоставления.
[0085]Приведенные в качестве примера снимки экрана выбора 304 расчетного счета и подтверждения 306 выбора расчетного счета представлены на фиг. 3. Снимок экрана 304 выбора расчетного счета отображает список доступных данные пользователя для предоставления в мобильном устройстве 110. В приведенном в качестве примера варианте осуществления, представленном на фиг. 3, пользователь может выбрать для предоставления последнюю кредитную карту, отображенную на экране. На снимке экрана 306 подтверждения выбора расчетного счета отображаются выбранные данные пользователя (например, выбранная кредитная карта) и вопрос пользователю, хочет ли пользователь установить данный счет для использования в транзакциях или выполнить другие действия со счетом (например, платежный баланс, посмотреть транзакции и т. п.). Снимок экрана 308 установки может предоставлять пользователю другие данные пользователя (например, другие расчетные счета), которые могут быть предоставлены наряду с выбранными данными пользователя. Пользователь может просто выбрать более чем одни отображенные данные пользователя для одновременного предоставления. В некоторых вариантах осуществления токены могут быть предварительно предоставлены для расчетных счетов, которые связанны с эмитентом, поддерживающим предоставление токенов, без выполнения пользователем запроса на предоставление каждого конкретного счета. Таким образом, выбор пользователем расчетного счета (-ов) может просто активировать предварительно предоставленный токен. Альтернативно, когда существует предварительно предоставленный токен, для предоставления информации о счете может не требоваться выполнение никакого выбора.
[0086] Фаза 252 предоставления токена может продолжаться на этапе 212, на котором мобильное приложение 111 запрашивает компьютер 140 MAP отправить данные пользователя (например, номер счета, идентификационный номер, и т. д.) для выбранного счета (-ов). В некоторых вариантах осуществления этап 212 может быть необязательным, и компьютер 140 MAP может отправлять зашифрованные данные пользователя на мобильное приложение 111 без запроса со стороны мобильного приложения 111.
[0087] На этапе 214 компьютер 140 MAP может использовать ключ шифрования, связанный с серверным компьютером 160 токенов (например, ключ шифрования, ранее предоставленный на компьютер 140 MAP серверным компьютером 160 токенов), для шифрования данных пользователя. Компьютер 140 MAP может безопасно сохранять ключ шифрования и данные пользователя. Например, компьютер 140 MAP может шифровать номер основного счета (PAN), дату завершения срока действия, CVV, имя, адрес, номер социального страхования, идентификационный номер или любую другую подходящую информацию, связанную с пользователем. В некоторых вариантах осуществления компьютер 140 MAP может шифровать и отправлять зашифрованную информацию о платеже для каждого расчетного счета, который настроен и/или имеет возможность для маркирования. Компьютер 140 MAP может отправлять зашифрованные данные пользователя на мобильное приложение 111. Мобильное устройство 110 принимает зашифрованные данные пользователя, отправленные с компьютера 140 MAP.
[0088] Например, в некоторых вариантах осуществления для шифрования конфиденциальной информации может использоваться веб-шифрование JSON. Соответственно, компьютер 140 MAP может упаковать данные пользователя в объект, подвергшийся веб-шифрованию JSON (JWE объект) и отправить объект, подвергшийся веб-шифрованию JSON (JWE объект), на мобильное устройство 110 для каждой части конфиденциальных данных пользователя. Как правило, зашифрованные входные параметры могут быть созданы на компьютере 140 MAP и отправлены на мобильное приложение 111. Конфиденциальные данные, применяемые при шифровании, не могут быть сохранены в самом мобильном приложении 111. Например, в некоторых вариантах осуществления ключи API, совместно используемые секретные ключи, информация о пользователе и/или информация о платеже (например, PAN) не могут быть переданы на мобильное устройство 110 незашифрованными. Согласно различным вариантам осуществления данные пользователя могут быть зашифрованы с помощью служебной программы для веб-токенов JSON (JWT).
[0089]Как часть фазы 252 предоставления токена, на этапе 216 мобильное приложение 111 может запрашивать, чтобы SDK 112 для токенов генерировал сообщение с запросом на предоставление токена для выбранных данных пользователя (например, выбранного номера (-ов) счета). Сообщение с запросом на предоставление токена может содержать зашифрованные данные пользователя, принятые с компьютера 140 MAP. Например, мобильное приложение 111 может запрашивать, чтобы SDK 112 для токенов получал или извлекал токены для принятых зашифрованных данных пользователя, связанных с одним или более счетами, открытыми эмитентом 150 и управляемыми сетью 170 обработки платежей. SDK 112 для токенов может затем генерировать сообщение с запросом на предоставление, содержащее зашифрованные данные пользователя.
[0090]SDK 112 для токенов может отправлять сообщение с запросом на предоставление на серверный компьютер 160 токенов с использованием интерфейсов API 180 серверного компьютера токенов. Например, SDK 112 для токенов может передавать сообщение с запросом на предоставление на серверный компьютер 160 токенов по безопасному каналу связи. В некоторых вариантах осуществления SDK 112 для токенов может отправлять сообщение с запросом на предоставление на серверный компьютер 160 токенов через программный интерфейс приложений (API) передачи состояния представления (REST-ful), соединяющий SDK 112 для токенов и серверный компьютер 160 токенов.
[0091]Серверный компьютер 160 токенов может использовать ключ шифрования для расшифровки данных пользователя, идентификации счета, связанного с расшифрованными данными пользователя, генерирования токена, связанного со счетом, сохранения токена и отправки токена на SDK 112 для токенов. Дополнительно в некоторых вариантах осуществления серверный компьютер 160 токенов может определять ранее сгенерированный токен, связанный с расшифрованными данными пользователя, получать информацию (например, ключ токена, идентифицирующий токен), связанную с токеном, и возвращать информацию токена на мобильное устройство 110 в ответ на запрос от мобильного приложения 111, использующего SDK 112 для токенов.
[0092]На этапе 218 SDK 112 для токенов может принимать токен, связанный с зашифрованными данными пользователя, с серверного компьютера 160 токенов. SDK для токенов может сохранять токен в памяти 113 для токенов, к которой не могут легко получить доступ другие приложения и/или стороны. В некоторых вариантах осуществления SDK 112 для токенов может связывать токен с ключом токена или другим ссылочным идентификатором токена для локально хранимых токенов на мобильном устройстве 110.
[0093]Фаза 252 предоставления токена может завершаться этапом 219, на котором ключ токена предоставляют на мобильное приложение 111. Ключ токена может быть использован SDK 112 для токенов, сохранен в памяти 113 для токенов и/или мобильным приложением 111 для идентификации токена. Ключ токена не может быть использован третьими сторонами для инициации транзакций, т. е. ключ токена не может заменять или действовать как токен. Но ключ токена может служить в качестве ссылочного идентификатора токена, идентифицирующего токен. Соответственно, ключ токена обеспечивает дополнительную безопасность и может быть совместно использован с мобильным приложением 111, поскольку ключ токена не является заменителем счета и не может быть использован для обработки транзакции вне приложения 111 мобильных платежей или SDK 112 для токенов на мобильном устройстве 110. В некоторых вариантах осуществления SDK 112 для токенов может генерировать ключ токена, тогда как в других вариантах осуществления серверный компьютер 160 токенов может предоставлять ключ токена на SDK 112 для токенов или мобильное приложение 111. Например, ключ токена может содержать случайным образом сгенерированное число, связанное с настоящим токеном, для идентификации токена и/или соответствующего счета, который является объектом изначального запроса на предоставление токена.
[0094]Пользователь может быть проинформирован об успешном завершении фазы 252 предоставления токена с помощью подтверждающего снимка экрана 310, представленного на фиг. 3.
[0095]Затем может быть вызван метод предоставления токена для создания запроса на предоставление токена. Запрос может быть обработан серверным компьютером 160 токенов, который создает токен и возвращает информацию о токене на SDK 112 для токенов. Эту информацию SDK 112 для токенов безопасно сохраняет в памяти 113 для токенов на мобильном устройстве 110. Ключ токена к токену может быть сделан доступным мобильному приложению 111. Ключ токена может быть использован мобильным приложением 111 в других вызовах SDK 112 для токенов для идентификации токена.
[0096]Фаза 254 проведения транзакции, представленная на фиг. 2, описана далее.
[0097]Этапы 220-226, представленные на фиг. 2, могут попадать в фазу 254 проведения транзакции. Более конкретно, фаза 254 проведения транзакции начинается на этапе 220, на котором пользователь для инициации транзакции выбирает счет через мобильное приложение 111. Например, пользователь может выбрать для использования в мобильной платежной транзакции расчетный счет. SDK 112 для токенов может быть уведомлен о выборе счета.
[0098]На этапе 222 для инициации транзакции с помощью мобильного приложения 111 пользователь может перенести мобильное устройство 110 в окрестность устройства 120 доступа с возможностью связи на близком расстоянии (например, POS-терминал продавца с возможностью NFC) для взаимодействия с устройством 120 доступа.
[0099]На этапе 224 устройство доступа 120 может отправлять сообщение с блоком данных протокола прикладного уровня (APDU) на мобильное приложение 111, начиная последовательность сообщений APDU, передаваемых между устройством 120 доступа и мобильным приложением 111.
[0100]На этапе 226 SDK 112 для токенов обрабатывает сообщение APDU, принятое мобильным приложением 111, с помощью приложения мобильных платежей (например, Visa™ PayWave™, и т. д.), выполненного с возможностью выполнения бесконтактного обмена по протоколу передачи данных и/или NFC транзакции. SDK 112 может отвечать устройству 120 доступа своими собственными сообщениями APDU. Мобильное приложение 111 может передавать запросы, принимаемые от устройства 120 доступа, на SDK 112 для токенов. Аналогично мобильное приложение 111 может принимать ответы от SDK 112 для токенов и передавать эти ответы на устройство доступа 120. Например, мобильное приложение 111 может отправлять ключ токена, связанный с выбранным счетом, на SDK 112 для токенов, и SDK 112 для токенов может извлекать токен, связанный с ключом токена, из памяти 113 токенов. Затем SDK 112 для токенов может отдавать команду компоненту связи на коротком расстоянии, находящемуся на мобильном устройстве 110 (например, NFC-передатчику), предоставить токен на устройство 120 доступа для транзакции. По существу токен может быть предоставлен на устройство 120 доступа с SDK 112 для токенов минуя мобильное приложение 111.
[0101] Во время выполнения фазы 254 транзакции может быть вызван метод выбора карты, с определением ключа токена, для выбора карты (например, расчетного счета) для NFC-транзакций с оплатой в одно касание.
[0102]После завершения интеграции с SDK для токенов мобильное приложение 111 может быть готово отвечать устройству доступа во время транзакции.
Конфигурации интеграции системы токенов
[0103]Согласно различным вариантам осуществления связь между мобильным устройством 110 и серверным компьютером 160 токенов для отправки запроса на предоставление токена и приема предоставленного токена может быть реализована двумя разными конфигурациями интеграции серверного компьютера токенов: в первом варианте интеграции, представленном на фиг. 4-8, SDK 112 серверного компьютера токенов осуществляет связь с серверным компьютером 160 токенов прямо; во втором варианте интеграции, представленном на фиг. 9-13, SDK 112 серверного компьютера токенов осуществляет связь с серверным компьютером 160 токенов через компьютер 140 MAP. Каждый из этих вариантов описан далее.
I. Вариант интеграции «SDK для токенов - Серверный компьютер токенов»
[0104]На фиг. 4 представлена интеграция SDK для токенов с серверным компьютером токенов, при которой мобильное приложение 111 взаимодействует с серверным компьютером 160 токенов через SDK 112 для токенов.
[0105]Как описано выше, мобильное приложение 111 может принимать зашифрованные данные пользователя (например, зашифрованные данные о платеже, такие как зашифрованный номер расчетного счета) с компьютера 140 поставщика мобильных приложений (MAP). Мобильное приложение 111 может передавать зашифрованные данные пользователя на SDK 112 для токенов для получения токена, представляющего счет, связанный с зашифрованными данными пользователя. Мобильное приложение 111 может отправлять на SDK 112 для токенов запрос на получение токена с серверного компьютера 160 токенов.
[0106]В этой первой приведенной для примера конфигурации интеграции SDK 112 для токенов прямо осуществляет связь с серверным компьютером 160 токенов с использованием интерфейсов API 180 серверного компьютера токенов. В вариантах интеграции SDK для токенов с серверным компьютером токенов SDK 112 для токенов скрывает сложность осуществления связи с серверным компьютером 160 токенов. SDK 112 для токенов производит все взаимодействие с серверным компьютером 160 токенов и предоставляет результат на мобильное приложение 111. Например, когда SDK 112 для токенов принимает запрос от мобильного приложения 111, SDK 112 для токенов отправляет сообщение с запросом токена на серверный компьютер 160 токенов. Сообщение с запросом токена может содержать зашифрованные данные пользователя, предоставленные на мобильное приложение компьютером 140 MAP. Когда SDK 112 для токенов принимает токен с серверного компьютера 160 токенов, SDK 112 для токенов может уведомлять мобильное приложение 111 о том, что токен был успешно принят, не передавая токен на мобильное приложение 111. В некоторых вариантах осуществления SDK 112 для токенов может генерировать ключ токена, представляющий токен. Альтернативно серверный компьютер 160 токенов может предоставлять на SDK 112 для токенов ключ токена наряду с токеном. SDK 112 для токенов может отправлять ключ токена на мобильное приложение 111, не передавая на мобильное приложение 111 токен.
[0107]Связь между мобильным приложением 111 и SDK 112 для токенов может быть произведена путем вызова методов. Метод запроса токена может принимать объект, содержащий входные параметры (например, зашифрованные данные пользователя), и объект обратного вызова (запрашивающий SDK 112 для токенов уведомлять мобильное приложение 111, когда/если токен получен). Например, в некоторых вариантах осуществления разработчик мобильного приложения может определить класс обратного вызова, из которого создают объект обратного вызова. Класс обратного вызова может определять два метода, успех (успешное получение токена) и неудача (токен не предоставлен на мобильное устройство), в которых разработчик мобильного приложения задает действия, которые необходимо предпринять для методов успеха и неудачи, соответственно. Для передачи информации с SDK 112 для токенов на мобильное приложение 111 объект обратного вызова может возвращать или объект ответа, или объект ошибки. Соответственно, интерфейсы API SDK для токенов могут реализовывать обратный вызов, информирующий мобильное приложение 111 об успехе или неудаче операции по запросу.
[0108]На фиг. 5-8 представлены функциональные схемы для различных процессов, выполняемых системой интеграции SDK для токенов с серверным компьютером токенов, представленной на фиг. 4. А именно, на фиг. 5 представлена функциональная схема приведенного в качестве примера способа аутентификации; на фиг. 6 представлена функциональная схема приведенного в качестве примера способа предоставления; на фиг. 7 представлена функциональная схема приведенного в качестве примера способа продления динамических параметров; и на фиг. 8 представлена функциональная схема приведенного в качестве примера способа приостановки системы, представленной на фиг. 4. Каждая схема обсуждается далее.
[0109]На фиг. 5 представлена функциональная схема приведенного в качестве примера способа 500 аутентификации для системы с первой приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции SDK для токенов с серверным компьютером токенов. На этапе 502 мобильное приложение может создавать экземпляр SDK для токенов, который будет шифровать конфиденциальные данные с модулем безопасности и сохранять их в хранилище данных SDK для токенов. Экземпляр SDK для токенов осуществляет связь с серверным компьютером токенов, чтобы запрашивать токен доступа и производить действия по регистрации мобильного устройства.
[0110]На этапе 504 приложение производит аутентификацию пользователя после предоставления пользователем своих удостоверяющих данных (таких как имя пользователя и пароль) для входа в приложение. На этапе 506 приложение может запрашивать веб-токен JSON (JWT), который подтверждает личность пользователя, с компьютера MAP. Компьютер MAP может составлять JWT путем заполнения параметров аутентификации и их шифрования с помощью прикладной среды веб-шифрования JSON (JWE). Компьютер MAP может предоставлять сгенерированный токен JWT аутентификации на мобильное приложение.
[0111]На этапе 508 мобильное приложение может создавать объект параметров аутентификации с токеном JWT аутентификации. Объект параметров аутентификации может быть отправлен на SDK для токенов для получения токена с серверного компьютера токенов с использованием токена JWT аутентификации. Мобильное приложение также может создавать объект обратного вызова ответа, определяющий методы успеха и неудачи, описанный выше. Методы успеха и неудачи могут быть использованы SDK для токенов для уведомления мобильного приложения о том, принят ли токен с серверного компьютера токенов.
[0112]Серверный компьютер токенов может принимать JWT посредством API токенов и предоставляет токен доступа на SDK для токенов посредством API токенов. Серверный компьютер токенов может также принимать информацию мобильного устройства посредством API регистрации устройств и возвращает идентификатор диалога на мобильное устройство посредством API регистрации устройств. Идентификатор диалога может указывать на то, что связь приходит от аутентифицированного устройства. Аутентификация может возвращать токен доступа и TTL для токена доступа. SDK для токенов безопасно сохраняет их для последующего использования.
[0113]На фиг. 6 представлена функциональная схема приведенного в качестве примера способа 600 предоставления для системы с первой приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции SDK для токенов с серверным компьютером токенов. Как проиллюстрировано на фиг. 6, метод предоставления токена может быть вызван мобильным приложением для извлечения и сохранения информации токена для конкретного счета и/или канала. Метод предоставления токена предоставляет токен, представляющий информацию, связанную со счетом. Обратный вызов на мобильное приложение может указывать на успешное выполнение метода предоставления токена и подавать на мобильное приложение ответ предоставления токена, который может содержать ключ токена, уникально идентифицирующий предоставленный токен. Мобильное приложение может сохранять ключ токена, чтобы совершать последующие вызовы, относящиеся к этому сохраненному токену. Эти этапы описаны ниже.
[0114]На этапе 602 мобильное приложение может запрашивать у пользователя предоставить данные пользователя (такие как информация о платеже), которые пользователь хотел бы поместить на мобильном устройстве. Однако данные пользователя не сохраняют на мобильном устройстве, как полагает пользователь. А именно, мобильное приложение отправляет компьютеру MAP запрос на шифрование данных пользователя. На этапе 604 удостоверяющие данные пользователя предоставляют на компьютер MAP для шифрования. Компьютер MAP предоставляет объект с зашифрованными данными пользователя на мобильное приложение.
[0115]На этапе 606 мобильное приложение может создавать объект с параметрами предоставления токена, содержащий зашифрованные данные пользователя, принятые с компьютера MAP. Мобильное приложение может также создавать объект обратного вызова ответа, определяющий методы успеха и неудачи. Объект обратного вызова ответа может быть использован для приема значений ответа от SDK для токенов. Как указано выше, когда SDK для токенов принимает токен с серверного компьютера токенов, SDK для токенов не предоставляет токен на мобильное приложение. Однако SDK для токенов может уведомлять мобильное приложение о том, токен принят (успех) или нет (неудача).
[0116]На этапе 608 SDK для токенов может осуществлять связь с серверным компьютером токенов, чтобы запрашивать токенизацию зашифрованных данных пользователя (таких как информация о платеже). Серверный компьютер токенов может принимать зашифрованные данные пользователя, идентифицировать счет, связанный с данными пользователя, создавать токен для представления счета, сохранять токен и отправлять токен на SDK для токенов. SDK для токенов может применять токен вместо данных пользователя, когда это необходимо. После приема токена с серверного компьютера токенов SDK для токенов может сохранять токен и уведомлять мобильное приложение об успешном приеме токена. В некоторых вариантах осуществления SDK для токенов может предоставлять на мобильное приложение ключ токена, идентифицирующий токен, на этапе 610.
[0117]На фиг. 7 представлена функциональная схема приведенного в качестве примера способа 700 продления динамических параметров для системы с первой приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции SDK для токенов с серверным компьютером токенов. Как проиллюстрировано на фиг. 7, метод продления динамических данных может быть вызван SDK для токенов для продления динамических данных для предоставленного токена, например, путем продления срока действия ключа ограниченного использования (LUK). Этот метод доступен для приложения, чтобы при необходимости подавать запрос на продления. SDK для токенов может устанавливать таймеры для отслеживания времени существования (TTL) LUK через компонент приложения мобильных платежей (например, payWave™). Поскольку SDK для токенов знает, когда происходит транзакция, SDK для токенов имеет возможность отслеживать количество транзакций в сравнении с заданным эмитентом токена значением порога риска количества транзакций. Соответственно, мобильному приложению нет необходимости отслеживать или предоставлять эту информацию на SDK для токенов. Для управления продлением ключа ограниченного использования SDK для токенов может предусматривать два метода: первый метод для периодической проверки (например, ежечасной), пройден ли порог времени существования ключа ограниченного использования, и для запуска события продления, когда время существования (TTL) истекает, и второй метод для перехвата события продления, запущенного первым методом.
[0118]На этапе 702 мобильное приложение может обнаруживать, что TTL токена приближается к завершению, и начинает составлять объекты, необходимые для запроса на продление токена. На этапе 704 мобильное приложение может создавать объект с параметрами продления, содержащий зашифрованные данные пользователя. Объект с параметрами продления может также содержать ключ токена, идентифицирующий токен. Мобильное приложение может также создавать объект обратного вызова ответа, определяющий методы успеха и неудачи.
[0119]На этапе 706 SDK для токенов может извлекать токен, идентифицируемый ключом токена, и осуществлять связь с серверным компьютером токенов, чтобы запрашивать продление динамических параметров токена. Серверный компьютер токенов может продлевать LUK токена и связанную информацию TTL. Серверный компьютер токенов может возвращать указанную информацию на SDK для токенов, который может, в свою очередь, информировать мобильное приложение о том, что процесс продления был или успешным, или неудачным.
[0120]Кроме того, в некоторых вариантах осуществления после каждой инициированной пользователем попытки транзакции с применением данного токена SDK для токенов может проверять, был ли превышен порог числа транзакций для продления LUK. Когда порог числа транзакций возрастает, SDK для токенов может инициировать обновление LUK.
[0121]Дополнительно может быть реализован метод проверки статуса, который может быть вызван SDK для токенов для получения статусов всех локально представленных токенов. Метод проверки статуса может проверять статус всех предоставленных для мобильного приложения токенов. Последующие действия могут происходить в результате найденных статусов. В некоторых вариантах осуществления мобильное приложение может вызывать метод проверки статуса для проверки статуса токенов, предоставленных в SDK для токенов, в сравнении со статусом тех же токенов в серверном компьютере токенов.
[0122]На фиг. 8 представлена функциональная схема приведенного в качестве примера способа 800 приостановки для системы с первой приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции SDK для токенов с серверным компьютером токенов. На этапе 802 платформа мобильного приложения может отправлять сообщение на мобильное приложение для приостановки токена, загруженного на мобильное устройство.
[0123]На этапе 804 мобильное приложение может делать запрос на приостановление токена (-ов), связанного со счетом. Мобильное приложение может генерировать объект приложения, содержащий ключ токена, идентифицирующий токен, который необходимо приостановить. Мобильное приложение может также генерировать объект обратного вызова ответа, определяющий методы успеха и неудачи. Мобильное приложение может передавать объект приложения и объект обратного вызова ответа на SDK для токенов.
[0124]На этапе 806 SDK для токенов может осуществлять связь с серверным компьютером токенов, чтобы отправлять на серверный компьютер токенов запрос на приостановку токена, связанного со счетом. После приема запроса (сообщения) серверный компьютер токенов может приостановить токен и возвращает приостановленный токен на SDK для токенов. SDK для токенов может сохранять приостановленный токен и уведомлять мобильное приложение.
[0125]Как представлено на фиг. 8, способ приостановки токена включает вызов управления временем существования для приостановки токена или нескольких токенов. Вызов осуществляют на серверный компьютер токенов и при получении успешного ответа, подтверждающего приостановку токена, в хранилище данных SDK для токенов состояние токена изменяют на новое состояние. Подобные потоки могут быть предусмотрены для метода возобновления токена для активации приостановленного токена на серверном компьютере токенов, за которой следует активация токена на устройстве пользователя, и метода удаления токена для удаления токена с серверного компьютера токенов, за которым следует удаление с устройства пользователя.
II. Вариант интеграции «Компьютер поставщика мобильных приложений - Серверный компьютер токенов»
[0126]В некоторых вариантах осуществления SDK для токенов может быть интегрирован с мобильным приложением и серверным компьютером токенов посредством компьютера поставщика мобильных приложений (MAP). При этом типе интеграции мобильное приложение может использовать SDK для токенов в основном для инициации доступа к серверному компьютеру токенов. Однако интеграция между мобильным приложением и серверным компьютером токенов происходит через компьютер MAP. То есть, SDK для токенов с серверным компьютером токенов прямо не взаимодействует.
[0127]На фиг. 9 представлена интеграция компьютера MAP с серверным компьютером токенов, при которой мобильное приложение 111 взаимодействует с серверным компьютером 160 токенов через компьютер 140 MAP.
[0128]Как описано выше, мобильное приложение 111 может принимать зашифрованные данные пользователя (например, зашифрованные данные о платеже, такие как зашифрованный номер расчетного счета) с компьютера 140 MAP. Мобильное приложение 111 может передавать зашифрованные данные пользователя на SDK 112 для токенов для получения токена, представляющего счет, связанный с зашифрованными данными пользователя. Мобильное приложение 111 может отправлять на SDK 112 для токенов запрос на получение токена с серверного компьютера 160 токенов путем отправки на SDK для токенов сообщения с запросом на предоставление токена (этап 901). SDK 112 для токенов может генерировать сообщение с запросом на предоставление токена и отправлять данное сообщение на серверный компьютер 160 токенов через компьютер 140 MAP (этапы 902, 903 и 904).
[0129]Эта схема интеграции может предоставлять разработчику приложения возможность соединения с серверным компьютером токенов через свое приложение, например, с применением компьютера MAP. В некоторых вариантах осуществления, для стандартизации процесса для разработчиков приложений, SDK для токенов может предоставлять интерфейс, называемый «поставщиком токена», для реализации множества разных методов.
[0130]Поставщик токена может реализовывать метод запроса токена для установления связи с серверным компьютером 160 токенов через его компьютер 140 MAP. SDK 112 для токенов может вызывать этот метод на объекте поставщика токена, переданном мобильным приложением 111 в сообщении с запросом предоставления (отправленном на этапе 901). А именно, на этапе 901 мобильное приложение 111 может вызвать метод SDK для токенов, задавая запрос, обратный вызов на мобильное приложение и объект, который соединяется с поставщиком токена, который, как правило, представляет сервер на компьютере 140 MAP. Объект поставщика токена задает ответ, который необходимо заполнить, и другой обратный вызов, называемый обратным вызовом SDK, который может быть использован для обратного вызова на SDK 112 для токенов из метода запроса токена.
[0131]На этапе 902 SDK 112 для токенов может подготавливать запрос и предоставлять запрос на мобильное приложение 111. А именно, SDK 112 для токенов может вызывать метод запроса токена объекта поставщика токена, задавая параметры запроса и ссылку на обратный вызов SDK.
[0132]На этапе 903 мобильное приложение 111 может подавать запрос на компьютер 140 MAP. То есть, метод запроса токена выполняет действия, заданные мобильным приложением 111, для соединения с компьютером 140 MAP и для получения информации (например, токена) с серверного компьютера 160 токенов на этапе 904. Компьютер 140 MAP может взаимодействовать с серверным компьютером 160 токенов через интерфейсы API 180 серверного компьютера токенов, чтобы запрашивать и принимать токен (этап 904).
[0133]Когда компьютер 140 MAP принимает ответ с серверного компьютера 160 токенов, компьютер 140 MAP может направлять принятое сообщение на мобильное приложение 111 (этап 905). Мобильное приложение может преобразовывать ответ в формат, который может быть прочитан и использован SDK 112 для токенов. Например, ответ может изначально быть принят в формате JSON и может быть преобразован в формат объекта Java, заданный SDK 112 для токенов. На этапе 906 мобильное приложение 111 может направлять отформатированный ответ от серверного компьютера 160 токенов на SDK 112 для токенов.
[0134]На этапе 906 мобильное приложение 111 может наполнять объект ответа (заданный в обратном вызове поставщика токена) ответом, принятым от компьютера 140 MAP. Мобильное приложение возвращает объект ответа в метод запроса токена. Мобильное приложение 111 вызывает метод успеха или метод неудачи на обратном вызове поставщика и передает объект ответа в этих методах. Мобильное приложение 111 может делать это из метода запроса токена.
[0135]Может быть по меньшей мере два обратных вызова, реализованных мобильным приложением 111. Один обратный вызов может быть для мобильного приложения 111, чтобы уведомлять SDK 112 для токенов об успехе или неудаче метода запроса токена, описанного выше. Когда мобильное приложение 111 получает успешный ответ на свой запрос на компьютер 140 MAP (например, метод запроса токена), то мобильное приложение 111 может предоставить объект ответа, содержащий данные, которые необходимо сохранить в SDK 112 для токенов (этап 906). Если метод запроса токена терпит неудачу, то приложение вызывает функцию неудачи на обратном вызове. Дополнительно, когда мобильное приложение 111 уведомило SDK 112 для токенов об успехе или неудаче запроса, сделанного на компьютер 140 MAP, SDK 112 для токенов может затем вызвать второй обратный вызов, чтобы дать возможность мобильному приложению 111 узнать об успехе/неудаче запроса на предоставление (этап 907). А именно, обратный вызов SDK 112 для токенов может вызвать метод успеха или метод неудачи обратного вызова мобильного приложения, чтобы вернуть ответ на мобильное приложение 111. Обратный вызов мобильного приложения представляет собой стандартный обратный вызов, заданный мобильным приложением 111 при отправке запроса на этапе 901.
[0136]В этой второй приведенной в качестве примера конфигурации интеграции мобильное приложение 111 осуществляет связь с компьютером 140 MAP (этап 903), и компьютер 140 MAP осуществляет взаимодействие с серверным компьютером 160 токенов (этап 904). Компьютер 140 MAP затем предоставляет данные ответа, принятые с серверного компьютера 160 токенов, на мобильное приложение 111 (этап 905). Мобильное приложение 111 предоставляет ответ от компьютера 140 MAP на SDK 112 для токенов (этап 906). Подобно первой приведенной в качестве примера конфигурации интеграции, SDK 112 для токенов предоставляет результат (указывающий, успешно ли предоставлен токен) на мобильное приложение 111 с применением обратного вызова (этап 907).
[0137]На фиг. 10-13 представлены функциональные схемы для различных процессов, выполняемых системой интеграции компьютера MAP с серверным компьютером токенов, представленной на фиг. 9. А именно, на фиг. 10 представлена функциональная схема приведенного в качестве примера способа аутентификации; на фиг. 11 представлена функциональная схема приведенного в качестве примера способа предоставления; на фиг. 12 представлена функциональная схема приведенного в качестве примера способа продления динамических параметров; и на фиг. 13 представлена функциональная схема приведенного в качестве примера способа приостановки системы, представленной на фиг. 9. Каждая схема обсуждается далее.
[0138]На фиг. 10 представлена функциональная схема приведенного в качестве примера способа 1000 аутентификации для системы со второй приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции компьютера MAP с серверным компьютером токенов. На этапе 1002 мобильное приложение может создавать экземпляр SDK для токенов, который будет шифровать конфиденциальные данные с модулем безопасности и сохранять их в хранилище данных SDK для токенов.
[0139]На этапе 1004, мобильное приложение производит аутентификацию пользователя после предоставления пользователем своих удостоверяющих данных (таких как имя пользователя и пароль) для входа в приложение. На этапе 1006 мобильное приложение принимает данные устройства, необходимые для аутентификации, от SDK для токенов. Мобильное приложение затем вызывает компьютер MAP для аутентификации с серверным компьютером токенов. Компьютер MAP может составлять необходимую информацию для аутентификации. Например, компьютер MAP может составлять JWT для метода аутентификации токеном доступа. Для получения токена доступа может требоваться вызов API токенов. Серверный компьютер токенов может принимать JWT и предоставлять токен доступа. Серверный компьютер токенов может также регистрировать устройство и возвращать идентификатор диалога в ответ на подробные данные об устройстве.
[0140]На этапе 1008 мобильное приложение может принимать указание о том, что аутентификация завершена.
[0141]На фиг. 11 представлена функциональная схема приведенного в качестве примера способа 1100 предоставления для системы со второй приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции компьютера MAP с серверным компьютером токенов. На этапе 1102 мобильное приложение может создавать объекты, необходимые для запроса на предоставление токена (например, метод предоставления токена). Мобильное приложение может создавать объект с параметрами предоставления токена, содержащий зашифрованные данные пользователя. Мобильное приложение также создает объект поставщика токена, обладающий функциональной возможностью осуществлять связь с компьютером MAP для предоставления токена. Мобильное приложение может также создавать объект обратного вызова ответа, определяющий методы успеха и неудачи. Мобильное приложение может передавать объекты с параметрами предоставления токена, поставщика токена и обратного вызова ответа в метод предоставления токена. Как проиллюстрировано на фиг. 11, метод предоставления токена может быть вызван мобильным приложением для извлечения и сохранения информации токена для конкретного счета и/или канала.
[0142]На этапе 1104, метод предоставления токена может вызывать метод SDK для токенов для осуществления связи с серверным компьютером токенов, чтобы запрашивать токенизацию зашифрованной информации пользователя. Этот вызов может быть передан на компьютер MAP на этапе 1106. Этот вызов может предоставлять возможность компьютеру MAP реализовывать метод поставщика токена, позволяя компьютеру MAP реализовывать свой собственный сетевой вызов для сборки токена. А именно, компьютер MAP может взаимодействовать с серверным компьютером токенов. Серверный компьютер токенов может принимать зашифрованные данные пользователя, идентифицировать счет, связанный с зашифрованными данными пользователя, генерировать токен, представляющий счет, сохранять токен и отправлять токен на компьютер MAP. Компьютер MAP может передавать токен на SDK для токенов в обратном вызове. SDK 112 для токенов может затем сохранять токен.
[0143]На этапе 1108 внешний обратный вызов может затем возвращать успех на мобильное приложение, возвращая ответ на запрос на предоставление токена, который может содержать ключ токена, уникально идентифицирующий предоставленный токен. Мобильное приложение может сохранять ключ токена, чтобы совершать последующие вызовы, относящиеся к связанному токену. Мобильное приложение не имеет доступа к самому токену.
[0144]В этой модели интеграции от мобильного приложения не требуется предоставлять данные пользователя (например, информацию о расчетном счете, такую как PAN или ссылочный идентификатор PAN). Компьютер MAP предоставляет данные токена с серверного компьютера токенов в ответ на подачу запроса, сделанного компьютером MAP. Компьютер MAP предоставляет токен на SDK для токенов через внутренний обратный вызов.
[0145]На фиг. 12 представлена функциональная схема приведенного в качестве примера способа 1200 продления динамических параметров для системы со второй приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции компьютера MAP с серверным компьютером токенов. Метод продления динамических данных может быть вызван мобильным приложением с помощью специализированного поставщика продления (например, сетевой вызывающей процедуры), для продления динамических данных для токена. Например, SDK для токенов может предусматривать два метода для управления продлением ключа ограниченного использования: первый метод для периодической проверки (например, ежечасной), пройден ли порог времени существования ключа ограниченного использования, и для запуска события продления, когда время существования (TTL) истекает, и второй метод для перехвата события продления, запущенного первым методом.
[0146]На этапе 1202 мобильное приложение может обнаруживать, что TTL токена приближается к завершению, и начинает составлять объекты, необходимые для запроса на продление токена. Мобильное приложение может создавать объект с параметрами продления, содержащий зашифрованные данные пользователя. Объект с параметрами продления может также содержать ключ токена, идентифицирующий токен. Мобильное приложение также создает объект поставщика продления, обладающий функциональной возможностью осуществлять связь с компьютером MAP для продления токена. Мобильное приложение может также создавать объект обратного вызова ответа, определяющий методы успеха и неудачи. Мобильное приложение может передавать объекты с параметрами продления, поставщика продления и обратного вызова ответа в метод продления динамических данных.
[0147]На этапе 1204 метод продления динамических данных может вызывать метод SDK для токенов для осуществления связи с серверным компьютером токенов, чтобы запрашивать продление динамических параметров токена и предоставлять связанные данные токена. Этот вызов может быть передан на компьютер MAP на этапе 1206. Этот вызов может предоставлять возможность компьютеру MAP реализовывать метод поставщика продления, позволяя компьютеру MAP реализовывать свой собственный сетевой вызов для сборки ответа продления токена. А именно, компьютер MAP может взаимодействовать с серверным компьютером токенов. Серверный компьютер токенов может принимать запрос на продление, продлевает LUK токена и связанную информацию TTL. Компьютер MAP может передавать продленный LUK токена и связанную информацию TTL на SDK 112 для токенов в обратном вызове. SDK 112 для токенов может затем сохранять информацию.
[0148]На этапе 1208 внешний обратный вызов может затем возвращать успех на мобильное приложение, возвращая ответ на запрос на предоставление токена, который может содержать ключ токена, уникально идентифицирующий предоставленный токен. Мобильное приложение может сохранять ключ токена, чтобы совершать последующие вызовы, относящиеся к связанному токену. Мобильное приложение не имеет доступа к самому токену.
[0149]На фиг. 13 представлена функциональная схема приведенного в качестве примера способа 1300 приостановления для системы со второй приведенной в качестве примера конфигурацией интеграции, соответствующей конфигурации интеграции компьютера MAP с серверным компьютером токенов. На этапе 1302 платформа мобильного приложения может отправлять сообщение на мобильное приложение для приостановки токена, загруженного на мобильное устройство.
[0150]На этапе 1304 мобильное приложение может делать запрос на приостановление токена (-ов), связанного со счетом. Мобильное приложение может генерировать объект с параметрами приложения, содержащий ключ токена, идентифицирующий токен, который необходимо приостановить, и, если уместно, - код причины, указывающий, почему следует приостановить токен, наряду с описанием причины. Мобильное приложение также создает объект приостановки токена, обладающий функциональной возможностью осуществлять связь с компьютером MAP для запроса на приостановку. Мобильное приложение может также создавать объект обратного вызова ответа, определяющий методы успеха и неудачи. Мобильное приложение может передавать объекты с параметрами, исполнителя приостановки токена и обратного вызова ответа в метод приостановления токена.
[0151]На этапе 1306 метод приостановления токена может вызывать SDK для токенов для осуществления связи с серверным компьютером токенов, чтобы запрашивать приостановление токена. Метод приостановления токена может приостанавливать токен в серверном компьютере токенов, после чего следует приостановление токена на устройстве пользователя. Вызов на SDK для токенов может быть передан на компьютер MAP на этапе 1308. Этот вызов может предоставлять возможность компьютеру MAP реализовывать свой собственный сетевой вызов для сборки ответа о статусе токена. А именно, компьютер MAP может взаимодействовать с серверным компьютером токенов. Серверный компьютер токенов может принимать запрос на приостановку токена, приостанавливает токен и отправляет обновленный статус токена (т. е., приостановленный) на компьютер MAP. Компьютер MAP может передавать обновленный статус токена на SDK 112 для токенов в обратном вызове. SDK 112 для токенов может затем сохранять статус токена в памяти для токенов.
[0152]На этапе 1310 внешний обратный вызов может затем возвращать успех на мобильное приложение.
[0153]Метод приостановления токена, представленный на фиг. 13 может включать вызов управления временем существования для приостановки токена или приостановки нескольких токенов. Вызов может быть сделан на серверный компьютер токенов, и при получении успешного ответа, подтверждающего приостановку токена, в хранилище данных SDK для токенов состояние токена может быть изменено. В некоторых вариантах осуществления в один момент времени может быть приостановлен один токен.
Компьютерная система, приведенная в качестве примера
[0154]Различные участники и элементы, представленные на фиг. 1A-1B, могут применять одно или более вычислительных устройств (например, серверный компьютер) для обеспечения функций, описанных в данном документе. Любые из элементов, представленных на фиг. 1A-1B, могут применять любое подходящее количество подсистем для обеспечения функций, описанных в данном документе. Примеры таких подсистем или компонентов представлены на фиг. 14. Показаны подсистемы, такие как принтер 1408, клавиатура 1416, несъемный диск 1418 (или другое запоминающее устройство, содержащее машиночитаемый носитель), монитор 1412, который соединен с адаптером 1410 дисплея, и другие. Периферийные устройства и устройства ввода/вывода (I/O), которые соединяются с I/O контроллером 1402, могут быть соединены с компьютерной системой с помощью любого количества средств, известных в данной области техники, таких как последовательный порт 1414. Например, последовательный порт 1414 или внешний интерфейс 1420 могут быть использованы для соединения вычислительного устройства с глобальной сетью, такой как Интернет, устройством ввода типа мышь или сканером. Соединение по системной шине позволяет центральному процессору 1406 осуществлять связь с каждой подсистемой и управлять выполнением команд из системной памяти 1404 или несъемного диска 1418, а также обмен информацией между подсистемами.
[0155]Ниже представлены характерные детали, касающиеся некоторых описанных выше аспектов. Характерные детали конкретных аспектов могут сочетаться любым подходящим образом, не отходя от идеи и объема вариантов осуществления настоящего изобретения.
[0156]Запоминающие носители и машиночитаемые носители для хранения кода или частей кода могут включать любые соответствующие носители, известные или используемые в данной области техники, включая запоминающие носители и средства связи, такие как, но без ограничения, энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией для хранения и/или передачи информации, такой как машиночитаемые команды, структуры данных, программные модули или другие данные, включая ОЗУ, ПЗУ, ЭСППЗУ (электрически стираемое программируемое постоянное запоминающее устройство), флеш-память или другую запоминающую технологию, CD-ROM, цифровой универсальный диск (DVD) или другой оптический носитель, магнитные кассеты, магнитную ленту, запоминающее устройство на магнитных дисках или другие магнитные запоминающие устройства, сигналы данных, передачи данных или любые другие носители, которые могут быть использованы для хранения или передачи желаемой информации и к которым может осуществить доступ компьютер. На основании описания и указаний, представленных в данном документе, для специалиста в данной области техники будут очевидны другие пути и/или способы для реализации разных вариантов осуществления.
[0157]Следует понимать, что настоящее изобретение, как описано выше, может быть исполнено в форме управляющей логики, использующей компьютерное программное обеспечение в модульном или целостном режиме. На основании описания и указаний, представленных в данном документе, специалисту в данной области техники могут быть понятны и очевидны другие пути и/или способы реализации настоящего изобретения с помощью аппаратного обеспечения и сочетания аппаратного и программного обеспечения.
[0158]Следует понимать, что настоящее изобретение, как описано выше, может быть исполнено в форме управляющей логики, использующей компьютерное программное обеспечение в модульном или целостном режиме. На основании описания и указаний, представленных в данном документе, специалисту в данной области техники могут быть понятны и очевидны другие пути и/или способы реализации настоящего изобретения с помощью аппаратного обеспечения и сочетания аппаратного и программного обеспечения.
[0159]Любые из программных компонентов или функций, описанных в данной заявке, могут быть реализованы в виде программного кода, который должен быть исполнен процессором, с использованием любого подходящего компьютерного языка, такого как, например, Java, C++ или Perl, с использованием, например, традиционных или объектно-ориентированных подходов. Программный код может быть сохранен в виде последовательности инструкций или команд на машиночитаемом носителе, таком как оперативное запоминающее устройство (ОЗУ), постоянное запоминающее устройство (ПЗУ), магнитный носитель, например, жесткий диск или гибкий диск, или оптический носитель, например, CD-ROM. Любой такой машиночитаемый носитель может находиться на или в одном вычислительном устройстве и может присутствовать на или в разных вычислительных устройствах в пределах системы или сети.
[0160]Описание выше является иллюстративным и не является ограничительным. Многие варианты настоящего изобретения могут стать очевидными специалистам в данной области техники по прочтении данного описания. Следовательно, объем настоящего изобретения следует определять не со ссылкой на вышеприведенное описание, но вместо этого следует определять со ссылкой на рассматриваемые пункты формулы изобретения, наряду с их полным объемом или эквивалентами.
[0161]Один или более признаков из любого варианта осуществления можно сочетать с одним или более признаками любого другого варианта осуществления без отхода от объема настоящего изобретения.
[0162]Формы единственного числа обозначают «один или более», если иное не указано отдельно.
| название | год | авторы | номер документа |
|---|---|---|---|
| ЗАЩИЩЕННАЯ ОБРАБОТКА УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ, ВКЛЮЧАЮЩАЯ В СЕБЯ АУТЕНТИФИКАЦИЮ ПОТРЕБИТЕЛЕЙ | 2014 |
|
RU2663476C2 |
| ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ | 2014 |
|
RU2674329C2 |
| СИНХРОНИЗАЦИЯ СОСТОЯНИЯ МАРКЕРА | 2019 |
|
RU2792695C2 |
| СИСТЕМА И СПОСОБ НАДЕЖНОЙ ПРОВЕРКИ ДОСТОВЕРНОСТИ ТРАНЗАКЦИЙ | 2011 |
|
RU2580086C2 |
| СИСТЕМЫ И СПОСОБЫ ДЛЯ СООБЩЕНИЯ РИСКОВ С ИСПОЛЬЗОВАНИЕМ ДАННЫХ ДОСТОВЕРНОСТИ МАРКЕРА | 2014 |
|
RU2681366C2 |
| ВЗАИМНАЯ АУТЕНТИФИКАЦИЯ ПРОГРАММНЫХ УРОВНЕЙ | 2016 |
|
RU2715032C2 |
| СИСТЕМЫ И СПОСОБЫ ДЛЯ КРИПТОГРАФИЧЕСКОЙ БЕЗОПАСНОСТИ КАК СЕРВИС | 2014 |
|
RU2630751C2 |
| СПОСОБЫ И СИСТЕМЫ ОБЛАЧНЫХ ТРАНЗАКЦИЙ | 2014 |
|
RU2686014C1 |
| СПОСОБ ОБНАРУЖЕНИЯ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ И ОПОВЕЩЕНИЯ О НЕМ | 2015 |
|
RU2705019C2 |
| ЗАБЛАГОВРЕМЕННАЯ АВТОРИЗАЦИЯ ЦИФРОВЫХ ЗАПРОСОВ | 2016 |
|
RU2713703C2 |
Изобретение относится к области вычислительной техники. Техническим результатом является обеспечение предоставления защищенных данных пользователя. Раскрыт способ предоставления защищенных данных пользователя, включающий: прием мобильным приложением, сохраненным на мобильном устройстве, с удаленного сервера мобильных приложений зашифрованных данных пользователя, связанных с пользователем мобильного устройства, при этом зашифрованные данные пользователя генерируют с применением ключа шифрования, связанного с серверным компьютером токенов; генерирование мобильным приложением сообщения с запросом токена, при этом сообщение с запросом токена содержит зашифрованные данные пользователя; отправку модулем токенов, сохраненным на мобильном устройстве, сообщения с запросом токена на серверный компьютер токенов, при этом серверный компьютер токенов расшифровывает зашифрованные данные пользователя с использованием ключа шифрования, идентифицирует счет, связанный с расшифрованными данными пользователя, генерирует токен, связанный со счетом, сохраняет токен и отправляет токен на модуль токенов; прием модулем токенов токена, связанного с зашифрованными данными пользователя, с серверного компьютера токенов; и сохранение модулем токенов токена в памяти для токенов; взаимодействие посредством мобильного приложения с устройством доступа для инициирования транзакции; и предоставление модулем токенов токена на устройство доступа, при этом токен предоставляется на устройство доступа, минуя мобильное приложение. 2 н. и 11 з.п. ф-лы, 14 ил.
1. Способ предоставления защищенных данных пользователя, включающий:
прием мобильным приложением, сохраненным на мобильном устройстве, с удаленного сервера мобильных приложений зашифрованных данных пользователя, связанных с пользователем мобильного устройства, при этом зашифрованные данные пользователя генерируют с применением ключа шифрования, связанного с серверным компьютером токенов;
генерирование мобильным приложением сообщения с запросом токена, при этом сообщение с запросом токена содержит зашифрованные данные пользователя;
отправку модулем токенов, сохраненным на мобильном устройстве, сообщения с запросом токена на серверный компьютер токенов, при этом серверный компьютер токенов расшифровывает зашифрованные данные пользователя с использованием ключа шифрования, идентифицирует счет, связанный с расшифрованными данными пользователя, генерирует токен, связанный со счетом, сохраняет токен и отправляет токен на модуль токенов;
прием модулем токенов токена, связанного с зашифрованными данными пользователя, с серверного компьютера токенов; и
сохранение модулем токенов токена в памяти для токенов;
взаимодействие посредством мобильного приложения с устройством доступа для инициирования транзакции; и
предоставление модулем токенов токена на устройство доступа, при этом токен предоставляется на устройство доступа, минуя мобильное приложение.
2. Способ по п. 1, отличающийся тем, что сохранение токена в памяти для токенов включает:
определение модулем токенов ключа токена, связанного с сохраненным токеном, и
предоставление модулем токенов ключа токена мобильному приложению на мобильном устройстве для использования в качестве ссылочного идентификатора токена для токена.
3. Способ по п. 1, отличающийся тем, что дополнительно включает:
запрос мобильным устройством статуса токена;
прием мобильным устройством ответа о статусе токена с серверного компьютера токенов; и
сохранение мобильным устройством статуса, связанного с токеном, в памяти для токенов.
4. Способ по п. 1, отличающийся тем, что ключ шифрования и данные пользователя, связанные с пользователем мобильного устройства, сохраняет удаленный сервер мобильных приложений.
5. Способ по п. 1, отличающийся тем, что памятью для токенов управляет модуль токенов, предусмотренный на мобильном устройстве, при этом модуль токенов связан с серверным компьютером токенов так, что мобильное устройство сопрягается с серверным компьютером токенов через модуль токенов.
6. Способ по п. 5, отличающийся тем, что модуль токенов сопрягается с программным интерфейсом приложений (API) серверного компьютера токенов.
7. Способ по п. 1, отличающийся тем, что сообщение с запросом токена отправляют на серверный компьютер токенов через удаленный сервер мобильных приложений, и токен, связанный с зашифрованными данными пользователя, принимают с серверного компьютера токенов через удаленный сервер мобильных приложений.
8. Мобильное устройство, содержащее:
процессор; и
элемент памяти, содержащий код, исполняемый процессором, для осуществления способа, включающего:
прием мобильным приложением, сохраненным на мобильном устройстве, с удаленного сервера мобильных приложений зашифрованных данных пользователя, связанных с пользователем мобильного устройства, при этом зашифрованные данные пользователя генерируют с применением ключа шифрования, связанного с серверным компьютером токенов;
генерирование мобильным приложением сообщения с запросом токена, при этом сообщение с запросом токена содержит зашифрованные данные пользователя;
отправку модулем токенов, сохраненным на мобильном устройстве, сообщения с запросом токена на серверный компьютер токенов, при этом серверный компьютер токенов расшифровывает зашифрованные данные пользователя с использованием ключа шифрования, идентифицирует счет, связанный с расшифрованными данными пользователя, генерирует токен, связанный со счетом, сохраняет токен и отправляет токен на модуль токенов;
прием модулем токенов токена, связанного с зашифрованными данными пользователя, с серверного компьютера токенов; и
сохранение модулем токенов токена в памяти для токенов;
взаимодействие посредством мобильного приложения с устройством доступа для инициирования транзакции; и
предоставление модулем токенов токена на устройство доступа, при этом токен предоставляется на устройство доступа, минуя мобильное приложение.
9. Мобильное устройство по п. 8, отличающееся тем, что сохранение токена в памяти для токенов включает:
определение модулем токенов ключа токена, связанного с сохраненным токеном, и
предоставление модулем токенов ключа токена мобильному приложению на мобильном устройстве для использования в качестве ссылочного идентификатора токена для токена.
10. Мобильное устройство по п. 8, отличающееся тем, что сообщение с запросом токена отправляют на серверный компьютер токенов через удаленный сервер мобильных приложений, и токен, связанный с зашифрованными данными пользователя, принимают с серверного компьютера токенов через удаленный сервер мобильных приложений.
11. Мобильное устройство по п. 8, отличающееся тем, что способ дополнительно включает:
запрос мобильным устройством статуса токена;
прием мобильным устройством ответа о статусе токена с серверного компьютера токенов; и
сохранение мобильным устройством статуса, связанного с токеном, в памяти для токенов.
12. Мобильное устройство по п. 8, отличающееся тем, что памятью для токенов управляет модуль токенов, предусмотренный на мобильном устройстве, при этом модуль токенов связан с серверным компьютером токенов так, что мобильное устройство сопрягается с серверным компьютером токенов через модуль токенов.
13. Мобильное устройство по п. 12, отличающееся тем, что модуль токенов сопрягается с программным интерфейсом приложений (API) серверного компьютера токенов.
| Способ защиты переносных электрических установок от опасностей, связанных с заземлением одной из фаз | 1924 |
|
SU2014A1 |
| Изложница с суживающимся книзу сечением и с вертикально перемещающимся днищем | 1924 |
|
SU2012A1 |
| Способ защиты переносных электрических установок от опасностей, связанных с заземлением одной из фаз | 1924 |
|
SU2014A1 |
| СПОСОБ ДОСТУПА К ПЕРСОНАЛЬНЫМ ДАННЫМ, ТАКИМ КАК ИНДИВИДУАЛЬНЫЙ МЕДИЦИНСКИЙ ФАЙЛ, С ИСПОЛЬЗОВАНИЕМ ЛОКАЛЬНОГО ФОРМИРУЮЩЕГО КОМПОНЕНТА | 2009 |
|
RU2510968C2 |
