Настоящее изобретение относится к способу мобильной бесконтактной покупки билетов/обработки платежей с помощью приложения на мобильном телефоне. Настоящее изобретение также относится к системе, серверу и мобильному телефону, подходящему для реализации такого способа.
УРОВЕНЬ ТЕХНИКИ
За последнее десятилетие на многих рынках происходила разработка решений по покупке билетов с помощью смарт-карт. Переход от контактных к бесконтактным смарт-картам для приложений по покупке билетов начался много лет назад, при этом использование мобильных телефонов с технологией ББС (ближняя бесконтактная связь) для покупки билетов в настоящее время находится на раннем этапе.
В основном инициативы по использованию ББС в мире направлены на совершение платежей, но все еще сохраняется неопределенность относительно сроков, когда кассовые терминалы станут широко распространены в торговых точках.
Растущее количество имеющихся телефонов с технологией ББС заставляет поставщиков услуг и участников экосистемы ББС разрабатывать перспективные направления и каналы покупки билетов/обработки платежей. Несомненно, мобильный телефон предлагает пользователю, по сравнению с бесконтактными смарт-картами, более совершенный способ с точки зрения пользовательского интерфейса и удаленного оказания услуг.
Наиболее популярные мобильные бесконтактные решения по покупке билетов/обработке платежей подразумевают использование SIM-карты, что означает, что транспортное/платежное приложение и учетные данные пользователя хранятся на SIM-карте, принадлежащей соответствующему оператору связи; и в таком случае поставщики транспортных/платежных услуг должны прийти к соглашению с оператором связи относительно оказания услуг по покупке билетов/обработке платежей с использованием технологии ББС; тогда поставщики транспортных/платежных услуг могут быть в какой-то мере ограничены при оказании собственных услуг через мобильный телефон, так как при использовании такого решения часть услуг оказывается в сфере компетенции оператора связи.
Поэтому поставщики могут быть заинтересованы в получении доступа к новым надежным решениям, которые могут быть полностью реализованы в сфере компетенции самой компании, оказывающей транспортные/платежные услуги, и при этом все равно наделены всеми преимуществами бесконтактной покупки билетов/обработки платежей на основании использования мобильных телефонов с технологией ББС.
РАСКРЫТИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
Цель изобретения заключается в том, чтобы предоставить поставщикам транспортных/платежных услуг надежный способ, который может быть полностью реализован в пределах их собственной сферы компетенции, что позволит им в полной мере контролировать брендирование своих услуг, свою деятельность и обеспечение покупки билетов/обработки платежей с помощью технологии ББС, избегая ограничений со стороны третьих лиц.
Данная цель достигается в соответствии с пунктом формулы 1 благодаря созданию способа, который позволяет осуществлять бесконтактную покупку билетов/совершать платежи через приложение мобильного телефона и содержит следующие этапы:
(a) Пользователь платит поставщику услуг за определенные услуги покупки билетов/обработки платежей.
(b) В связи с платежом и с соответствующим предоставленным правом на использование услуг покупки билетов/обработки платежей модуль сервера покупки билетов/обработки платежей готовит идентификационные данные покупки билетов/обработки платежей для использования зарегистрированным пользователем и отправляет их на мобильный телефон зарегистрированного пользователя.
(с) Мобильный телефон пользователя получает идентификационные данные и сохраняет их для использования в транспортной системе бесконтактной покупки билетов, если речь идет об идентификационных данных для покупки билетов, или для использования при мобильных бесконтактных платежах, если речь идет об идентификационных данных для обработки платежей.
Указанный способ отличается тем, что каждый элемент идентификационных данных однозначно связан с мобильным телефоном зарегистрированного пользователя и с кодом активации и частично адаптирует мобильный телефон для доступа к бесконтактной покупке билетов, если речь идет об идентификационных данных для покупки билетов, или для мобильных бесконтактных платежей, если речь идет об идентификационных данных для совершения платежей; при этом адаптация мобильного телефона при каждом доступе к бесконтактной покупке билетов (или мобильному бесконтактному совершению платежей) также требует от пользователя ввода персонального идентификационного номера (ПИН) в приложении мобильного телефона для покупки билетов/обработки платежей; а модуль сервера покупки билетов/обработки платежей отправляет идентификационные данные на мобильный телефон зарегистрированного пользователя после успешного подтверждения одноразового пароля (ОРП) от приложения мобильного телефона по покупке билетов/обработке платежей.
Согласно настоящему изобретению только зарегистрированные пользователи могут получить идентификационные данные для покупки билетов/обработки платежей после оплаты, и использование таких идентификационных данных связано с мобильным телефоном, выбранным при регистрации (и с кодом активации), и с персональным идентификационным номером, выбранным пользователем, поэтому необходима аутентификация с использованием двух факторов. Кроме того, идентификационные данные отправляются на приложение мобильного телефона зарегистрированного пользователя только после подтверждения ОРП, сформированного таким приложением мобильного телефона после взаимодействия с пользователем, поэтому процесс загрузки идентификационных данных надлежащим образом контролируется пользователем и поставщиком транспортных/платежных услуг.
Модуль сервера покупки билетов/обработки платежей может быть по меньшей мере частично включен в средства обработки данных поставщика услуг. Все такие средства или их часть могут обслуживаться надежным внешним партнером поставщика услуг. Например, несколько поставщиков транспортных услуг могут использовать один общий модуль сервера покупки билетов на основании соглашения между ними, что позволит избежать сложности решений, основанных на использовании SIM-карт и требующих заключения дополнительных соглашений с операторами связи.
В конкретном варианте реализации модуль сервера покупки билетов/обработки платежей разделяет предоставленное право покупки билетов/обработки платежей на несколько порций и формирует отдельный элемент идентификационных данных для каждой из этих порций.
В конкретном варианте реализации первый набор идентификационных данных отправляется на приложение мобильного телефона, и новые идентификационные данные отправляются на приложение мобильного телефона при последовательном запросе с мобильного устройства пользователя до достижения лимита предоставленного права на использование бесконтактных услуг по покупке билетов/обработке платежей. Таким образом, система может контролировать и в любое время ограничивать объем идентификационных данных, доступных на мобильном телефоне для покупки билетов/обработки платежей.
В конкретном варианте реализации по меньшей мере один элемент идентификационных данных в приложении мобильного телефона отключают или удаляют из него посредством отправки отключающего или удаляющего сообщения с модуля сервера покупки билетов/обработки платежей на приложение мобильного телефона пользователя.
В другом конкретном варианте реализации право использования услуг покупки билетов/обработки платежей может быть продлено пользователем, оплатившим его, так что на модуле сервера покупки билетов/обработки платежей могут динамически генерироваться новые порции права на покупку билетов/обработку платежей.
В другом конкретном варианте реализации приложение мобильного телефона ограничивает запрос новых идентификационных данных на основании информации о том, что идентификационные данные уже сохранены в мобильном телефоне. Поэтому если объем идентификационных данных ниже определенного порога, пользователю напоминают о том, что необходимо подключение к данным для обновления идентификационных данных.
В конкретном варианте реализации идентификационные данные для покупки билетов/обработки платежей блокируются приложением мобильного телефона после нескольких неправильных попыток ввода персонального идентификационного номера, и уведомление направляется на модуль сервера покупки билетов/обработки платежей.
В конкретном варианте реализации модуль сервера покупки билетов/обработки платежей блокирует предоставленное право покупки билетов/обработки платежей после нескольких попыток ввода неверного пароля ОРП, полученного от приложения мобильного телефона, и сообщение о блокировке идентификационных данных передается на приложение мобильного телефона.
Таким образом, транспортная/платежная компания может контролировать ввод неправильного ПИН сразу до попытки доступа к покупке билетов/обработке платежей или в процессе обновления идентификационных данных.
В конкретном варианте реализации для онлайн-транзакций мобильных бесконтактных платежей самим приложением мобильного телефона рассчитывается вторая часть элемента идентификационных данных, причем рассчитывается она с использованием значения транзакции и ПИН пользователя в качестве вводных данных для формирования результирующего ОРП (второй части элемента идентификационных данных). Первая и вторая части элемента идентификационных данных используются для транзакции мобильного бесконтактного платежа, и требуется проверка такого ОРП модулем платежного сервера, чтобы принять или отклонить транзакцию. Если воспользоваться тем фактом, что значение транзакции известно банку-эмитенту в процессе онлайн-транзакции, запрос ОРП может этим воспользоваться при проверке в рамках онлайн-процесса авторизации.
В другом конкретном варианте реализации для транзакций бесконтактных мобильных онлайн-платежей самим приложением мобильного телефона рассчитывается вторая часть элемента идентификационных данных, причем рассчитывается она с использованием ПИН пользователя в качестве вводных данных для формирования результирующего ОРП как второй части элемента идентификационных данных, при этом первая и вторая части элемента идентификационных данных используются для транзакции мобильного бесконтактного платежа, и требуется проверка такого ОРП модулем платежного сервера, чтобы принять или отклонить транзакцию. Данный вариант реализации требует от пользователя ввода ПИН (но не значения транзакции) для расчета ОРП, поэтому процесс подготовки платежа через приложение мобильного телефона проще, чем в предыдущем варианте реализации.
В конкретном варианте реализации транзакция мобильного бесконтактного онлайн-платежа, которая использует первую и вторую часть элемента идентификационных данных, уже была принята («первая транзакция»), и по меньшей мере одна дополнительная транзакция, которая впоследствии использует по меньшей мере те же самые первую и вторую части элемента идентификационных данных («последующие транзакции») принимается на основании проверки ОРП первой транзакции.
В качестве конкретного примера, помимо первоначального мобильного бесконтактного онлайн-платежа (или предварительной авторизации платежа), компании, например, отели, компании по аренде автомобилей и т.д. могут иногда позднее взыскать с пользователя некоторые дополнительные расходы (например, компания по аренде автомобиля списывает плату за потраченный бензин с пользователя). Такая реализация позволяет модулю платежного сервера обеспечивать прием последующих транзакций на основании электронной подписи первой транзакции (успешная проверка ОРП в связи с первой транзакцией).
В конкретном варианте реализации каждая из последующих транзакций сопоставляется с первой транзакцией на основании использования указанной по меньшей мере части первой и второй части элемента идентификационных данных.
В другом конкретном варианте реализации каждая из последующих транзакций сопоставляется с первой транзакцией на основании использования, по меньшей мере частично, первой и второй части элемента идентификационных данных и использования по меньшей мере одного дополнительного параметра, и такой параметр включается в транзакционный поток первой и последующих транзакций. В конкретном примере одним дополнительным параметром является код торговой точки.
В конкретном варианте реализации задан максимальный объем идентификационных данных, хранящихся в мобильном телефоне в определенное время, и приложение мобильного телефона ограничивает мобильные бесконтактные офлайн-платежи с применением таких идентификационных данных до максимального значения совокупных платежных офлайн-транзакций. Поэтому совершение офлайн-платежей на совокупную большую сумму требует от пользователя правильного ввода ПИН, чтобы модуль платежного сервера отправил новые идентификационные данные на мобильный телефон зарегистрированного пользователя, и платежное приложение мобильного телефона снова установит максимальное значение совокупных платежных офлайн-транзакций.
В конкретном примере максимальный объем идентификационных данных - x, а максимальное значение совокупных офлайн-транзакций, использующих такие идентификационные данные, - yy евро. Если пользователь совершает мобильный бесконтактный офлайн-платеж на сумму z евро, максимальная сумма офлайн-платежей с использованием остающегося (x-1) объема идентификационных данных составляет (yy-z) евро. Платежное приложение мобильного телефона запрашивает новые идентификационные данные; если проверка ОРП на модуле платежного сервера пройдена, новый элемент идентификационных данных отправляются на платежное приложение мобильного телефона, и максимальное значение совокупных платежных офлайн-транзакций снова устанавливается как yy евро.
В конфетном варианте реализации пользователь выбирает через свое платежное приложение мобильного телефона Интернет-платеж, и вторая часть элемента идентификационных данных по меньшей мере с частью первой части элемента идентификационных данных используется для выполнения такого платежа. Таким образом, пользователь может выбирать через свое платежное приложение мобильного телефона подраздел частично рассчитанных идентификационных данных, чтобы совершить Интернет-платеж.
В конкретном варианте реализации Интернет-транзакция, которая использует по меньшей мере часть первой и второй частей элемента идентификационных данных, уже была принята («первая транзакция»), и по меньшей мере одна дополнительная транзакция, которая впоследствии использует по меньшей мере часть первой и второй частей идентификационных данных («последующие транзакции»), принимается на основании проверки ОРП первой транзакции.
В конкретном варианте реализации каждая из последующих транзакций связана с первой транзакцией на основании использования указанной по меньшей мере части первой части элемента идентификационных данных и второй части элемента идентификационных данных.
В конкретном варианте реализации каждая из последующих транзакций связана с первой транзакцией на основании использования по меньшей мере части первой и второй части элемента идентификационных данных и использования по меньшей мере одного дополнительного параметра, и такой параметр включается в транзакционный поток первой и последующих транзакций.
В конкретном варианте реализации пользователь платит за определенные товары и/или услуги в одной или нескольких связанных торговых точках, и, по меньшей мере, одна торговая точка передает часть сумм таких транзакций поставщику услуг покупки билетов/обработки платежей, чтобы он предложил услуги покупки билетов/обработки платежей пользователю. Поэтому в таком варианте реализации, по меньшей мере, одна торговая точка управляет выплатой сумм таких транзакций от имени пользователя в рамках программы лояльности, предлагаемой торговой точкой (точками).
Как правило, программы лояльности, предлагаемые торговыми точками, начисляют пользователю баллы после каждой покупки, и их можно использовать только в ограниченном числе связанных торговых точек. Предыдущий вариант реализации позволяет, по меньшей мере, одной торговой точке предлагать своему клиенту (в рамках инструмента лояльности) услуги покупки билетов/обработки платежей, объем использования которых значительно выше, чем объем, предлагаемый ограниченным числом торговых точек.
В конкретном варианте реализации пользователь может использовать свое платежное приложение мобильного телефона для оплаты торговым точкам в рамках лимита сумм транзакций, сформировавшегося в результате различных покупок, по меньшей мере, в одной торговой точке. Обратите внимание, что такие платежи могут совершаться у множества торговых точек без необходимости какого-либо соглашения между указанной по меньшей мере одной торговой точкой, где имели место первоначальные покупки, и торговыми точками, где совершаются платежи с помощью таких совокупных сумм транзакций.
В другом конкретном варианте реализации совокупные суммы транзакций используются для предоставления пользователю определенных прав на использование услуг покупки билетов. Поэтому пользователь сможет использовать свое приложение мобильного телефона по покупке билетов для доступа к услугам покупки билетов в разных точках доступа (например, для посадки на любой городской автобус).
В конкретном варианте реализации одна или несколько торговых точек платят поставщику услуг покупки билетов/обработки платежей за определенные услуги покупки билетов/обработки платежей для пользователя, в рамках программы лояльности, предлагаемой торговой точкой (точками). Таким же образом, когда пользователь платит за определенные товары и/или услуги, по меньшей мере, одной торговой точке, по меньшей мере, одна торговая точка передает часть сумм таких транзакций поставщику услуг покупки билетов/обработки платежей, чтобы последний предложил определенные услуги покупки билетов/обработки платежей пользователю. Аналогично предыдущему варианту реализации, в данном варианте реализации, по меньшей мере, одна торговая точка управляет оплатой таких услуг и суммами таких транзакций от имени пользователя в рамках программы лояльности, предлагаемой торговой точкой (точками).
В конкретном варианте реализации существует максимальное заранее определенное число первой части набора идентификационных данных для мобильных бесконтактных офлайн-платежей, которые могут храниться в мобильном телефоне в заданный момент времени, и, после того как истечет срок действия первой части всех идентификационных данных, платежное приложение мобильного телефона ограничивает мобильные бесконтактные офлайн-платежи, которые используют первую часть каждого из этих идентификационных данных. Поэтому, чтобы выполнить мобильные бесконтактные офлайн-платежи после того, как срок действия первой части набора идентификационных данных для мобильных бесконтактных офлайн-платежей истечет, пользователь должен правильно ввести ПИН, чтобы модуль платежного сервера отправил новые действительные первые части идентификационных данных для мобильных бесконтактных офлайн-платежей на мобильный телефон зарегистрированного пользователя.
Патент WO 03/038719 описывает способ, когда виртуальная финансовая карта разового использования формируется в офлайн-режиме для Интернет-платежа или бесконтактной транзакции типа EMV-MSD (данные магнитной полосы). Но такое решение не может использоваться для формирования виртуальной финансовой карты разового использования для транзакции с бесконтактным чипом EMV и ПИН, так как полученный ключ должен рассчитываться со стороны сервера и отправляться на приложение мобильного телефона до попытки совершения платежа (чтобы избежать хранения ключа эмитента в мобильном телефоне); поэтому формирование виртуальной финансовой карты разового использования для транзакции с бесконтактным чипом EMV и ПИН требует обработки онлайн-/офлайн-процесса для каждой сформированной карты. Последний вариант реализации соответствует требованию онлайн-обновления, но также преимущественно соотносит мобильную вторую часть элемента идентификационных данных, сформированную в офлайн-режиме, со значением транзакции и ПИН пользователя, создавая таким образом удобное и весьма надежное платежное решение.
Согласно настоящему изобретению дополнительно предложена система, обеспечивающая мобильную бесконтактную покупку билетов/обработку платежей через приложение мобильного телефона, включающая:
- средства регистрации для регистрации пользователей услуг покупки билетов/обработки платежей,
- средства оплаты, позволяющие пользователю оплатить услуги покупки билетов/обработки платежей,
- средства формирования идентификационных данных для формирования на модуле сервера покупки билетов/обработки платежей на основании предоставленных прав покупки билетов/обработки платежей идентификационных данных покупки билетов/обработки платежей для использования зарегистрированным пользователем; средства передачи для их отправки на мобильный телефон зарегистрированного пользователя; и средства приема и хранения для получения идентификационных данных на мобильном телефоне и их хранения для использования в транспортной бесконтактной системе покупки билетов (или для использования при мобильных бесконтактных платежах, в случае идентификационных данных для платежей),
отличающаяся тем, что указанная мобильная система содержит средства обработки для однозначной привязки каждого элемента идентификационных данных, который частично адаптирует мобильный телефон для доступа к бесконтактной покупке билетов (или мобильным бесконтактным платежам), к мобильному телефону зарегистрированного пользователя и коду активации; средства обработки и проверки для обеспечения адаптации мобильного телефона для каждого доступа к бесконтактной покупке билетов (или мобильным бесконтактным платежам), что также основано на вводе пользователем персонального идентификационного номера (ПИН) в приложении мобильного телефона для покупки билетов/обработки платежей; средства обработки и передачи в приложении мобильного телефона для покупки билетов/обработки платежей для расчета ОРП и его отправки на модуль сервера покупки билетов/обработки платежей; и средства обработки и проверки на модуле сервера покупки билетов/обработки платежей для подтверждения полученного ОРП.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
В следующем подробном описании представлены некоторые возможные варианты реализации, прочие характеристики и преимущества изобретения, притом что каждое описание относится к следующим чертежам:
Фиг. 1.а представляет собой схему, которая в общем иллюстрирует основные функциональные блоки изобретения в качестве дополнения к традиционной транспортной системе;
Фиг. 1.b представляет собой схему, которая иллюстрирует вариант реализации системы покупки билетов согласно изобретению;
Фиг. 1.с представляет собой схему, которая иллюстрирует другой вариант реализации системы покупки билетов согласно изобретению;
Фиг. 2.а представляет собой схему, которая в общем иллюстрирует основные функциональные блоки изобретения в качестве дополнения к традиционной платежной системе;
Фиг. 2.b представляет собой схему, которая иллюстрирует вариант реализации платежной системы согласно изобретению;
Фиг. 2.с представляет собой блок-схему, частично иллюстрирующую вариант реализации способа согласно изобретению;
Фиг. 2.d представляет собой блок-схему, частично иллюстрирующую вариант реализации способа согласно изобретению;
Фиг. 2.е представляет собой блок-схему, частично иллюстрирующую вариант реализации способа согласно изобретению;
Фиг. 2.f представляет собой блок-схему, частично иллюстрирующую вариант реализации способа согласно изобретению;
Фиг. 2.g представляет собой блок-схему, частично иллюстрирующую вариант реализации способа согласно изобретению.
ПОДРОБНОЕ ОПИСАНИЕ
Фиг. 1.а представляет собой схему, которая в общем иллюстрирует основные функциональные блоки изобретения в качестве дополнения к традиционной транспортной системе; на данном чертеже представлена традиционная транспортная система 300а от поставщика услуг, поддерживающего бесконтактные смарт-карты (поэтому у пользователя этой системы может быть в наличии бесконтактная смарт-карта для доступа к транспортным услугам через устройства контроля доступа к покупке билетов 400а). С помощью канала веб-дистрибуции 200а пользователи 100а могут совершить необходимые приготовления для заключения договора, по меньшей мере, по одной услуге для получения, по меньшей мере, одного транспортного титра (профиля), связанного с такой, по меньшей мере, одной услугой, и для загрузки/перегрузки, по меньшей мере, одного транспортного титра. В данном общем примере канал веб-дистрибуции принадлежит банку-партнеру, и пользователь также является клиентом этого банка, поэтому он может совершать платежи через веб-страницу с помощью электронной подписи, предоставленной банком.
Когда пользователь запрашивает через канал веб-дистрибуции услуги мобильной покупки билетов, связанные с настоящим изобретением (и платит за них в соответствии с согласованным способом между, например, указанным банком и поставщиком услуг покупки билетов), традиционная транспортная система передает запрос на модуль сервера покупки билетов 500а изобретения. Основные функциональные блоки настоящего модуля показаны на данном чертеже.
Фиг. 1.b содержит дополнительные данные о функциональных блоках, представленных на фиг. 1.а, и представляет собой схему, которая иллюстрирует вариант реализации системы покупки билетов согласно изобретению, чтобы обеспечить мобильную бесконтактную покупку билетов через приложение мобильного телефона; Фиг. 1.b показывает процесс от регистрации пользователя услуг мобильной покупки билетов до оказания таких услуг.
На этапе (1) пользователь загружает приложение мобильного телефона для покупки билетов из магазина приложений 700 на свой мобильный телефон с бесконтактной технологией.
В контексте изобретения пользователь платит за определенные услуги покупки билетов, которые он запрашивает от поставщика услуг. На этапе (2) данного варианта реализации пользователь запрашивает услуги покупки билетов через канал веб-дистрибуции и подтверждает платеж с помощью данных средств (например, тот же сценарий, что и на фиг. 1.а: канал веб-дистрибуции принадлежит банку-партнеру). На этапе (3) запрос отправляется в традиционную транспортную систему, а затем на модуль сервера покупки билетов. В данном варианте реализации модуль регистрации модуля сервера покупки билетов получает на этапе (3) справку о клиенте и справку о транспортном праве. После соотнесения с платежом и с соответствующим предоставленным правом для использования сопутствующих услуг покупки билетов модуль сервера покупки билетов готовит идентификационные данные для покупки билетов зарегистрированным пользователем и отправляет их на мобильный телефон зарегистрированного пользователя, как указано ниже.
На этапе (4) модуль регистрации модуля сервера покупки билетов присваивает транспортное право пользователю (представленному на рис. 1.b как карта «А» на модуле сервера) на основании полученной справки о транспортном праве, и данная информация хранится в базе данных модуля сервера покупки билетов (справка о клиенте о А). Затем модуль регистрации отправляет запрос на модуль идентификационных данных пользователя для формирования одного элемента идентификационных данных (представленного на рис. 1.b как карта «VMC(A)» на модуле сервера), который связывается со справкой о транспортном клиенте и транспорным правом в базе данных модуля сервера покупки билетов (справка о клиенте о А о VMC(A)). У сформированного элемента идентификационных данных есть срок годности, поэтому после его истечения они не могут быть использованы.
На этапе (5) модуль идентификационных данных пользователя запрашивает у модуля безопасности код активации; формируется код активации с заданным сроком годности посредством модуля безопасности и сохраняется в базе данных модуля сервера покупки билетов (справка о клиенте ⇔ A ⇔ VMC(A) ⇔ АС). Код активации не может быть использован после истечения срока годности. На этапе (6) код активации отправляется с модуля регистрации в традиционную транспортную систему в канал веб-дистрибуции и отображается у пользователя.
На этапе (7) пользователь вводит код активации в приложение мобильного телефона для покупки билетов, а на этапе (8) мобильный телефон отправляет на модуль безопасности модуля сервера покупки билетов, например, через https, [код активации и hash(идентификационный номер мобильного телефона и код активации)].
На этапе (9) модуль безопасности проверяет правильность кода активации; затем модуль безопасности сохраняет хеш-значение в базе данных модуля сервера покупки билетов, и теперь ссылки выглядят следующим образом: справка о клиенте ⇔ А ⇔ VMC(A) ⇔ АС ⇔ hash(ID&AC).
На этапе (10) карта «А» подвергается предварительной персонализации в приложении мобильного телефона.
Предварительная персонализация относится к этапу, предшествующему персонализации; и предварительная персонализация/персонализация карты «А» относится к предварительной персонализации/персонализации приложения мобильной бесконтактной покупки билетов из изобретения для работы в «режиме имитации карты» для услуг мобильной бесконтактной покупки билетов, что аналогично работе приложения для покупки билетов на основе SIM-карты в «режиме имитации карты» для услуг мобильной бесконтактной покупки билетов (например, имитация базовой технологии карт mifare DESFIRE). Полная персонализация карты «А» в приложении мобильного телефона для покупки билетов требует загрузки идентификационных данных с модуля сервера покупки билетов на приложение мобильного телефона для покупки билетов, как описано ниже.
По окончании этапа (10) пользователь уже зарегистрирован в системе изобретения, но идентификационные данные пока еще не были получены приложением мобильного телефона для покупки билетов. На этом этапе каждый элемент идентификационных данных однозначно связан с мобильным телефоном зарегистрированного пользователя и с кодом активации и частично адаптирует мобильный телефон для бесконтактного доступа для покупки билетов.
На этапе (11) пользователю предлагается выбрать персональный идентификационный номер (ПИН) для услуг мобильной бесконтактной покупки билетов. Значение ПИН не хранится в приложении мобильного телефона для покупки билетов, а безопасным образом отправляется на этапе (12) в модуль безопасности модуля сервера покупки билетов, наряду с одноразовым паролем (ОРП), рассчитанным с помощью значения ПИН (и кода активации и значений hash(AC&ID), чтобы присвоить на модуле сервера покупки билетов выбранный ПИН и результат ОРП правильной справке о клиенте).
На этапе (13) модуль безопасности хранит ПИН в базе данных модуля сервера покупки билетов, наряду с ключами и параметрами для расчета ОРП на основе ПИН. Все такие сохраненные данные обозначены в базе данных фиг. 1.b как данные «ОРП(ПИН)». Теперь в базе данных хранятся следующие ссылки и данные: справка о клиенте ⇔ А ⇔ VMC(A) ⇔ АС о hash(ID&AC) ⇔ ΟΡΠ(ΡΙΝ).
Все еще на этапе (13) модуль сервера покупки билетов рассчитывает результат ОРП с помощью сохраненного пользовательского ПИН и ключей и параметров ОРП и сравнивает результат с тем, что получен в модуле безопасности от приложения мобильного телефона для покупки билетов. Если подтверждение прошло успешно, идентификационные данные для покупки билетов могут быть отправлены с модуля пользовательских идентификационных данных на приложение мобильного телефона для покупки билетов. Поэтому модуль сервера для покупки билетов отправляет идентификационные данные на мобильный телефон зарегистрированного пользователя после успешной проверки одноразового пароля (ОРП), полученного от приложения мобильного телефона для покупки билетов.
На этапе (14) идентификационные данные для покупки билетов отправляются на приложение мобильного телефона для покупки билетов; мобильный телефон пользователя получает идентификационные данные и сохраняет их для использования в транспортной бесконтактной системе покупки билетов (и затем завершается процесс персонализации карты «А»). В одном варианте реализации идентификационные данные были закодированы в модуле безопасности с помощью ПИН, поэтому чтобы приложение мобильного телефона для покупки билетов могло использовать полученный и сохраненный элемент идентификационных данных, необходимо, чтобы пользователь ввел свой ПИН-код.
Зарегистрированный пользователь может на этапе (15) использовать мобильный телефон для доступа к транспортным услугам. На этапе (15) пользователь вводит свой ПИН-код в приложение мобильного телефона для покупки билетов перед попыткой доступа к системе контроля доступа для покупки билетов 400; поэтому адаптация мобильного телефона для каждого бесконтактного доступа для покупки билетов также требует ввода персонального идентификационного кода (ПИН) пользователем в приложении мобильного телефона для покупки билетов.
На этапе (16) модуль идентификационных данных пользователя в модуле сервера покупки билетов понимает, что идентификационные данные покупки билетов были успешно получены и сохранены в приложении мобильного телефона для покупки билетов (успех на этапе 14), и подтверждение отправляется веб-дистрибьютору, который совершает последнее списание платежа и уведомляет пользователя (например, через SMS или посредством уведомления веб-страницы дистрибьютора).
Фиг. 1.с представляет собой схему, которая иллюстрирует другой вариант реализации системы покупки билетов согласно изобретению, чтобы обеспечить мобильную бесконтактную покупку билетов через приложение мобильного телефона; Фиг. 1.с показывает процесс от регистрации пользователя услуг мобильной покупки билетов до оказания таких услуг.
Данный вариант реализации берет в качестве примера фиг. 1.b с некоторыми изменениями, которые описаны ниже. Этапы (1), (2) и (3) такие же, как на фиг. 1.b.
В связи с платежом и с соответствующим предоставленным правом на использование услуг покупки билетов модуль сервера покупки билетов готовит идентификационные данные покупки билетов для использования зарегистрированным пользователем и отправляет их на мобильный телефон зарегистрированного пользователя, как описано ниже. Но в данном варианте реализации модуль сервера покупки билетов разделяет предоставленное право покупки билетов на несколько порций и формирует отдельный элемент идентификационных данных для каждой из этих порций.
Поэтому на этапе (4) модуль сервера покупки билетов присваивает транспортное право пользователю (представленному на рис. 1.с как карта «А» на модуле сервера), связанное с набором идентификационных данных (представленным на рис. 1.с как карты «VMC(A)i» - «VMC(A)n» на модуле сервера) и справкой о транспортном клиенте, и сохраняет эти связи в базе данных модуля сервера покупки билетов (справка о клиенте ⇔ А ⇔ VMC(A)i, i=1…n).
На этапе (5) формируется код активации, который сохраняется в базе данных модуля сервера покупки билетов (справка о клиенте ⇔ А ⇔ VMC(A)i, i=1…no АС). На этапе (6) код активации отправляется с модуля регистрации в традиционную транспортную систему в канал веб-дистрибуции и отображается у пользователя.
Этапы (7), (8) и (9) такие же, как на фиг. 1.b, и ссылки после этапа (9) представлены следующим образом: справка о клиенте ⇔ А ⇔ VMC(A)i, i=1…n ⇔ AC ⇔ hash(ID&AC).
На этапе (10) карта «А» подвергается предварительной персонализации в приложении мобильного телефона.
Как в варианте реализации 1.b, предварительная персонализация относится к этапу, предшествующему персонализации; и предварительная персонализация/персонализация карты «А» относится к предварительной персонализации/персонализации приложения мобильной бесконтактной покупки билетов из изобретения для работы в «режиме имитации карты» для услуг мобильной бесконтактной покупки билетов, что аналогично работе приложения для покупки билетов на основе SIM-карты в «режиме имитации карты» для услуг мобильной бесконтактной покупки билетов. Полная персонализация карты «А» в приложении мобильного телефона для покупки билетов требует загрузки идентификационных данных с модуля сервера покупки билетов на приложение мобильного телефона для покупки билетов, как описано ниже.
По окончании этапа (10) пользователь уже зарегистрирован в системе изобретения, но идентификационные данные пока еще не были получены приложением мобильного телефона для покупки билетов. На этом этапе каждый элемент идентификационных данных однозначно связан с мобильным телефоном зарегистрированного пользователя и с кодом активации и частично адаптирует мобильный телефон для бесконтактного доступа для покупки билетов.
На этапе (11) пользователю предлагается выбрать персональный идентификационный номер (ПИН) для услуг мобильной бесконтактной покупки билетов. Значение ПИН не хранится в приложении мобильного телефона для покупки билетов, а безопасным образом отправляется на этапе (12) в модуль сервера покупки билетов наряду с одноразовым паролем (ОРП), рассчитанным с помощью значения ПИН (и кода активации и значений hash(AC&ID), чтобы присвоить на модуле сервера покупки билетов выбранный ПИН и результат ОРП правильной справке о клиенте).
На этапе (13) ПИН сохраняется в базе данных модуля сервера покупки билетов, наряду с ключами и параметрами для расчета ОРП на основе ПИН. Все такие сохраненные данные обозначены в базе данных фиг. 1.с как данные «ОРП(ПИН)». Теперь в базе данных хранятся следующие ссылки и данные: справка о клиенте ⇔ А ⇔ VMC(A)i, i=1…n ⇔ АС ⇔ hash(ID&AC) ⇔ ОРП(PIN).
Все еще на этапе (13) модуль сервера покупки билетов рассчитывает результат ОРП с помощью сохраненного пользовательского ПИН и ключей и параметров ОРП и сравнивает результат с тем, что получен от приложения мобильного телефона для покупки билетов. Если подтверждение прошло успешно, идентификационные данные для покупки билетов могут быть отправлены на приложение мобильного телефона для покупки билетов. Поэтому модуль сервера для покупки билетов отправляет идентификационные данные на мобильный телефон зарегистрированного пользователя после успешной проверки одноразового пароля (ОРП), полученного от приложения мобильного телефона для покупки билетов.
На этапе (14) первый набор идентификационных данных (например, идентификационные данные с i=1 по i=j, j<n) отправляются на приложение мобильного телефона для покупки билетов; мобильный телефон пользователя получает идентификационные данные и сохраняет их для использования в транспортной системе бесконтактной покупки билетов (и процесс персонализации карты «А» затем завершается для использования идентификационных данных с i=1 по i=j).
Зарегистрированный пользователь может на этапе (15) использовать мобильный телефон для доступа к транспортным услугам. На этапе (15) пользователь вводит свой ПИН-код в приложение мобильного телефона для покупки билетов перед попыткой доступа к системе контроля доступа для покупки билетов 400; поэтому адаптация мобильного телефона для каждого бесконтактного доступа для покупки билетов также требует ввода персонального идентификационного кода (ПИН) пользователем в приложении мобильного телефона для покупки билетов.
На этапе (16) модуль сервера покупки билетов понимает, что первый набор идентификационных данных для покупки билетов был успешно получен и сохранен в приложении мобильного телефона для покупки билетов (успех на этапе 14), и подтверждение отправляется веб-дистрибьютору, который совершает последнее списание платежа и уведомляет пользователя (например, через SMS или посредством уведомления веб-страницы дистрибьютора).
Новые идентификационные данные отправляются на приложение мобильного телефона при последующем запросе с мобильного устройства пользователя до достижения лимита предоставленного права на использование бесконтактных услуг покупки билетов.
На этапе (17) модуль идентификационных данных приложения мобильного телефона для покупки билетов обнаруживает, что требуются новые идентификационные данные, и отправляет сообщение request_credentials на модуль сервера покупки билетов. Данное сообщение содержит результат одноразового пароля (ОРП), рассчитанного с помощью значения ПИН (и код активации и значения hash(AC&ID), чтобы результат ОРП в модуле сервера покупки билетов был присвоен правильной справке о клиенте. В одном варианте реализации приложение рассчитывает ОРП, используя ввод пользователем ПИН-кода при попытке доступа к транспортной системе покупки билетов. В другом варианте реализации пользователю предлагается ввести ПИН-код, чтобы рассчитать результат ОРП.
Как во второй части этапа (13) модуль сервера покупки билетов рассчитывает результат ОРП с помощью сохраненного пользовательского ПИН и ключей и параметров ОРП, и сравнивает результат с тем, что получен от приложения мобильного телефона для покупки билетов. Если подтверждение прошло успешно, дополнительные идентификационные данные для покупки билетов могут быть отправлены на приложение мобильного телефона для покупки билетов. Поэтому модуль сервера для покупки билетов отправляет дополнительные идентификационные данные на мобильный телефон зарегистрированного пользователя после успешной проверки одноразового пароля (ОРП), полученного от приложения мобильного телефона для покупки билетов.
На этапе (18) новый набор идентификационных данных (например, идентификационные данные с i=j+1 по i=k, k<n) отправляется на приложение мобильного телефона для покупки билетов; мобильный телефон пользователя получает идентификационные данные и сохраняет их для использования в транспортной системе бесконтактной покупки билетов (и процесс персонализации карты «А» затем завершается для использования идентификационных данных с i=j+1 по i=k).
В данном варианте реализации этапы (17), (13) и (18) повторяются до тех пор, пока идентификационные данные до элемента идентификационных данных i=n отправляются на мобильный телефон, где они будут получены и сохранены приложением мобильного телефона для покупки билетов для использования в транспортной системе бесконтактной покупки билетов.
Все эти идентификационные данные до n-ного элемента идентификационных данных могут использоваться на этапе (15) зарегистрированным пользователем для доступа к транспортным услугам. На этапе (15) пользователь вводит свой ПИН-код в приложение мобильного телефона для покупки билетов перед попыткой доступа к системе контроля доступа для покупки билетов 400; поэтому адаптация мобильного телефона для каждого бесконтактного доступа для покупки билетов также требует ввода персонального идентификационного кода (ПИН) пользователем в приложении мобильного телефона для покупки билетов.
Право использования услуг покупки билетов может быть продлено пользователем, оплатившим его, и новые порции права на покупку билетов могут динамически генерироваться на модуле сервера покупки билетов. Поэтому, например, после новой реализации этапов (2) и (3), порции с i=n+1 по i=m могут генерироваться при новой реализации процесса этапа (4), и элемент идентификационных данных с i=n+1 по i=m может далее быть успешно отправлен на мобильный телефон и получен и сохранен приложением мобильного телефона для покупки билетов в соответствии с повторяемыми этапами (17), (13) и (18) для использования в транспортной системе бесконтактной покупки билетов.
В конкретном примере пользователь платит 50€ через канал веб-дистрибуции, и предоставленное транспортное право позволяет ему получить доступ к услугам покупки билетов на автобус в зоне А в течение апреля (30 дней). Модуль сервера покупки билетов готовит элемент 1 идентификационных данных для использования в первый день месяца… и элемент 30 идентификационных данных для использования в последний день месяца. Первые пять наборов идентификационных данных отправляются на приложение мобильного телефона перед началом месяца, после получения правильного значения ОРП; если все еще остаются идентификационные данные в мобильном телефоне для оставшихся четырех дней, сообщение request_credentials отправляется для запроса идентификационных данных для 1 дополнительного дня, используя ввод ПИН пользователем для доступа к услугам мобильной покупки билетов; если остаются идентификационные данные для оставшихся трех дней, запрос направляется для 2 дополнительных дней, используя ввод ПИН пользователем для доступа к услугам мобильной покупки билетов; если есть идентификационные данные для 2 дней или только 1 дня, пользователю предлагается ввести ПИН-код в приложении мобильного телефона для покупки билетов для запроса новых идентификационных данных, их получения и хранения (до достижения лимита идентификационных данных в 5 дней на мобильном телефоне).
В другом конкретном примере пользователь платит 40€ через канал веб-дистрибуции, и предоставленное транспортное право позволяет ему совершить 40 поездок на автобусе в зоне А.
Первые пять наборов идентификационных данных, по одному на каждую поездку, отправляются на приложение мобильного телефона после получения правильного значения ОРП; если все еще остаются идентификационные данные в мобильном телефоне для оставшихся четырех поездок, сообщение request_credentials отправляется для запроса идентификационных данных для 1 дополнительной поездки, используя ввод ПИН пользователем для доступа к услугам мобильной покупки билетов; если остаются идентификационные данные для оставшихся трех поездок, запрос направляется для 2 дополнительных поездок, используя ввод ПИН пользователем для доступа к услугам мобильной покупки билетов; если есть идентификационные данные для 2 поездок или только 1 поездки, пользователю предлагается ввести ПИН-код в приложении мобильного телефона для покупки билетов для запроса новых идентификационных данных, их получения и хранения (до достижения лимита идентификационных данных поездок на мобильном телефоне).
Поэтому приложение мобильного телефона ограничивает запрос новых идентификационных данных на основании информации о том, что идентификационные данные уже сохранены на мобильном телефоне. Преимущественно данная функция позволяет поставщику услуг покупки билетов контролировать объем доступных идентификационных данных на мобильном телефоне пользователя и управлять им, тем самым оставляя часть предоставленного права на модуле сервера покупки билетов.
Модуль транзакций или безопасности на модуле сервера покупки билетов может потребовать отключения (или удаления) по меньшей мере одного элемента идентификационных данных в приложении мобильного телефона посредством отправки отключающего (или удаляющего) сообщения с модуля сервера покупки билетов на приложение мобильного телефона пользователя. Так поставщик услуг покупки билетов все еще может управлять идентификационными данными в онлайн-режиме при их наличии в приложении мобильного телефона.
В варианте реализации идентификационные данные покупки билетов блокируются в приложении мобильного телефона после нескольких попыток ввода неправильного персонального идентификационного номера, и на модуль сервера покупки билетов отправляется уведомление. В другом варианте реализации модуль сервера покупки билетов блокирует предоставленное право покупки билетов после нескольких попыток ввода неверного пароля ОРП, полученного от приложения мобильного телефона, и сообщение о блокировке идентификационных данных передается на приложение мобильного телефона. Так, у поставщика услуг покупки билетов есть ПИН и инструменты управления безопасностью и в приложении, и со стороны модуля сервера покупки билетов.
Модуль безопасности периодически проверяет действительность кодов активации и идентификационных данных, чтобы их нельзя было использовать после истечения их срока годности. В одном примере, если код активации или элемент идентификационных данных используется после истечения срока годности, сообщение отправляется в действующую транспортную систему для уведомления о таком событии.
Фиг. 2.а представляет собой схему, которая в общем иллюстрирует основные функциональные блоки изобретения в качестве дополнения к традиционной платежной системе; на данном чертеже представлена традиционная платежная система 3000а от поставщика услуг банка (/компании платежных средств), поддерживающего контактные и бесконтактные смарт-карты для платежей (поэтому у пользователя этой системы может быть в наличии контактная/бесконтактная финансовая смарт-карта для оплаты в торговых точках, оснащенных контактными/бесконтактными кассовыми терминалами 4000а). Пользователи 1000а могут запрашивать через канал веб-дистрибуции 2000а финансовые смарт-карты для дебетовых/кредитных/авансовых платежей. В данном примере канал веб-дистрибуции принадлежит банку, который является собственником традиционной платежной системы, и пользователь также является клиентом в этом банке, поэтому он может подтвердить платеж по запрошенным финансовым картам и позднее активировать их через веб-страницу, используя электронную подпись, предоставленную банком.
После запроса пользователем через канал веб-дистрибуции мобильных платежных услуг по настоящему изобретению (это возможность использования, по меньшей мере, одной финансовой мобильной карты для мобильных бесконтактных платежей) и их оплаты (пользователь платит за запрашиваемую возможность) с помощью электронной подписи банка, традиционная платежная система направляет запрос на модуль платежного сервера 5000а по изобретению. Основные функциональные блоки настоящего модуля показаны на данном чертеже.
Фиг. 2.b содержит дополнительные данные о функциональных блоках фиг. 2.а и представляет собой схему, которая иллюстрирует вариант реализации платежной системы согласно изобретению, чтобы обеспечить мобильные бесконтактные платежи через приложение мобильного телефона; Фиг. 2.b показывает процесс от регистрации пользователя услуг мобильных платежей до оказания таких услуг.
На этапе (1) пользователь загружает приложение мобильного телефона для мобильных платежей из магазина приложений 7000 на свой мобильный телефон с бесконтактной технологией.
В контексте изобретения пользователь платит за определенные услуги совершения платежей, которые он запрашивает от поставщика услуг. На этапе (2) настоящего варианта реализации пользователь запрашивает платежные услуги (запрос возможности использования, по меньшей мере, одной финансовой мобильной карты для мобильных бесконтактных платежей) через канал веб-дистрибуции и подтверждает платеж через этот канал (пользователь платит за запрашиваемую возможность). В данном варианте реализации применяется тот же самый сценарий, что описан на фиг. 2.а: канал веб-дистрибуции принадлежит банку. На этапе (3) запрос отправляется в традиционную платежную систему, а затем на модуль платежного сервера.
В связи с платежом и с соответствующим предоставленным правом на использование услуг обработки платежей модуль платежного сервера готовит идентификационные данные платежей для использования зарегистрированным пользователем и отправляет их на мобильный телефон зарегистрированного пользователя, как описано ниже. В данном варианте реализации модуль платежного сервера разделяет предоставленное право совершения платежей на несколько порций и формирует отдельный элемент идентификационных данных для каждой из этих порций.
На этапе (4) модуль платежного сервера присваивает платежное право пользователю (представленному на рис. 2.b как карта «А» на модуле сервера), связанное с набором идентификационных данных (представленным на рис. 2.b как карты «VMC(A)i» - «VMC(A)n» на модуле сервера) и с платежной справкой о клиенте, и сохраняет эти связи в базе данных модуля платежного сервера (справка о клиенте ⇔ А ⇔ 5 VMC(A)i, i=1…n).
На этапе (5) формируется код активации, который сохраняется в базе данных модуля платежного сервера (справка о клиенте ⇔ А ⇔ VMC(A)i, i=1…n ⇔ AC). На этапе (6) код активации отправляется в традиционную платежную систему в канал веб-дистрибуции и отображается у пользователя.
На этапе (7) пользователь вводит код активации в приложение мобильного телефона для совершения платежей, а на этапе (8) мобильный телефон отправляет на модуль платежного сервера, например, через https, [код активации и hash(идентификационный номер мобильного телефона и код активации)].
На этапе (9) хеш-значение сохраняется на модуле платежного сервера, и теперь ссылки выглядят следующим образом: справка о клиенте о А о VMC(A)i, i=1…n о АС о hash(ID&AC).
На этапе (10) карта «А» подвергается предварительной персонализации в приложении мобильного телефона.
Предварительная персонализация относится к этапу, предшествующему персонализации; и предварительная персонализация/персонализация карты «А» относится к предварительной персонализации/персонализации приложения мобильных бесконтактных платежей из изобретения для работы в «режиме имитации карты» для услуг мобильных бесконтактных платежей, что аналогично работе приложения для обработки платежей на основе SIM-карты в «режиме имитации карты» для услуг мобильных бесконтактных платежей (например, платежи с чипом EMV и ПИН). Полная персонализация карты «А» в приложении мобильного телефона для обработки платежей требует загрузки идентификационных данных с модуля платежного сервера на приложение мобильного телефона для обработки платежей, как описано ниже. По окончании этапа (10) пользователь уже зарегистрирован в системе изобретения, но идентификационные данные пока еще не были получены приложением мобильного телефона для обработки платежей. На этом этапе каждый элемент идентификационных данных однозначно связан с мобильным телефоном зарегистрированного пользователя и с кодом активации и частично адаптирует мобильный телефон для доступа к услугам бесконтактных платежей в торговых точках.
На этапе (11) пользователю предлагается выбрать персональный идентификационный номер (ПИН) для услуг мобильных бесконтактных платежей. Значение ПИН не хранится в приложении мобильного телефона для обработки платежей, а безопасным образом отправляется на этапе (12) в модуль платежного сервера, наряду с одноразовым паролем (ОРП), рассчитанным с помощью значения ПИН (и кода активации и значений hash(AC&ID), чтобы присвоить на модуле платежного сервера выбранный ПИН и результат ОРП правильной справке о клиенте).
На этапе (13) ПИН сохраняется в базе данных модуля платежного сервера наряду с ключами и параметрами для расчета ОРП на основе ПИН. Все такие сохраненные данные обозначены в базе данных фиг. 1.с как данные «ОРП(ПИН)». Теперь в базе данных хранятся следующие ссылки и данные: справка о клиенте ⇔ А ⇔ VMC(A)i, i=1…n о АС ⇔ hash(ID&AC) ⇔ ОРП(ПИН).
Все еще на этапе (13) модуль платежного сервера рассчитывает результат ОРП с помощью сохраненного пользовательского ПИН и ключей и параметров ОРП и сравнивает результат с тем, что получен от приложения мобильного телефона для обработки платежей. Если подтверждение прошло успешно, идентификационные данные для обработки платежей могут быть отправлены на приложение мобильного телефона для обработки платежей. Поэтому модуль платежного сервера отправляет идентификационные данные на мобильный телефон зарегистрированного пользователя после успешной проверки одноразового пароля (ОРП), полученного от приложения мобильного телефона для покупки билетов.
На этапе (14) первый набор идентификационных данных (например, идентификационные данные с i=1 по i=j, j<n) отправляются на приложение мобильного телефона для обработки платежей; мобильный телефон пользователя получает идентификационные данные и сохраняет их для использования в торговых точках, оснащенных бесконтактными кассовыми терминалами (и процесс персонализации карты «А» затем завершается для использования идентификационных данных с i=1 по i=j). Зарегистрированный пользователь может на этапе (15) использовать мобильный телефон для платежей в торговых точках, оснащенных бесконтактными кассовыми терминалами. На этапе (15) пользователь вводит свой ПИН-код в приложение мобильного телефона для обработки платежей перед попыткой доступа для оплаты в бесконтактном кассовом терминале 4000; поэтому адаптация мобильного телефона для каждого бесконтактного мобильного платежа также требует ввода персонального идентификационного кода (ПИН) пользователем в приложении мобильного телефона для обработки платежей.
На этапе (16) модуль платежного сервера понимает, что первый набор идентификационных данных для обработки платежей был успешно получен и сохранен в приложении мобильного телефона для обработки платежей (успех на этапе 14), и подтверждение отправляется веб-дистрибьютору, который совершает последнее списание платежа и уведомляет пользователя (например, через SMS или посредством уведомления веб-страницы дистрибьютора).
Новые идентификационные данные отправляются на приложение мобильного телефона при последующем запросе с мобильного устройства пользователя до достижения лимита предоставленного права на использование услуг бесконтактных платежей.
На этапе (17) приложение мобильного телефона для обработки платежей обнаруживает, что требуются новые идентификационные данные, и отправляет сообщение request_credentials на модуль платежного сервера. Данное сообщение содержит результат одноразового пароля (ОРП), рассчитанного с помощью значения ПИН (и код активации и значения hash(AC&ID), чтобы результат ОРП в модуле платежного сервера был присвоен правильной справке о клиенте). В одном варианте реализации приложение рассчитывает ОРП, используя ввод пользователем ПИН-кода при попытке совершения мобильного бесконтактного платежа в торговой точке. В другом варианте реализации пользователю предлагается ввести ПИН-код, чтобы рассчитать результат ОРП.
Как во второй части этапа (13) модуль платежного сервера рассчитывает результат ОРП с помощью сохраненного пользовательского ПИН и ключей и параметров ОРП и сравнивает результат с тем, что получен от приложения мобильного телефона для обработки платежей. Если подтверждение прошло успешно, дополнительные идентификационные данные для обработки платежей могут быть отправлены на приложение мобильного телефона для обработки платежей. Поэтому модуль платежного сервера отправляет дополнительные идентификационные данные на мобильный телефон зарегистрированного пользователя после успешной проверки одноразового пароля (ОРП), полученного от приложения мобильного телефона для обработки платежей.
На этапе (18) новый набор идентификационных данных (например, идентификационные данные с i=j+1 по i=k, k<n) отправляются на приложение мобильного телефона для обработки платежей; мобильный телефон пользователя получает идентификационные данные и сохраняет их для использования в системе бесконтактных платежей (и процесс персонализации карты «А» затем завершается для использования идентификационных данных с i=j+1 по i=k).
В данном варианте реализации этапы (17), (13) и (18) повторяются до тех пор, пока элемент идентификационных данных до i=n будет отправлен на мобильный телефон и получен и сохранен приложением мобильного телефона для обработки платежей для использования в системе бесконтактных мобильных платежей.
Все эти идентификационные данные до элемента n идентификационных данных могут использоваться на этапе (15) зарегистрированным пользователем для доступа к бесконтактным мобильным платежам. На этапе (15) пользователь вводит свой ПИН-код в приложение мобильного телефона для обработки платежей перед попыткой оплаты в бесконтактном кассовом терминале; поэтому адаптация мобильного телефона для каждого бесконтактного мобильного платежа также требует ввода персонального идентификационного кода (ПИН) пользователем в приложении мобильного телефона для обработки платежей.
Право использования услуг платежей может быть продлено пользователем, оплатившим его, и новые порции права на обработку платежей могут динамически генерироваться на модуле платежного сервера. Поэтому, например, после новой реализации этапов (2) и (3), порции с i=n+1 по i=m могут генерироваться при новой реализации процесса этапа (4), и элемент идентификационных данных с i=n+1 по i=m могут далее быть успешно отправлены на мобильный телефон и получены и сохранены приложением мобильного телефона для обработки платежей в соответствии с повторяемыми этапами (17), (13) и (18) для использования при мобильных бесконтактных платежах.
В конкретном примере пользователь платит 20€ через канал веб-дистрибуции, и предоставленное право платежей разрешает ему выполнить транзакции бесконтактных платежей через свое приложение мобильных бесконтактных платежей и, в соответствии с традиционной схемой кредитного продукта, в бесконтактных кассовых терминалах в течение 1 года. Модуль платежного сервера готовит идентификационные данные для использования в течение года, и каждый набор идентификационных данных действителен только для одной попытки платежа. Первые пять наборов идентификационных данных отправляются на приложение мобильного телефона перед началом периода после получения правильного значения ОРП; если все еще остаются идентификационные данные в мобильном телефоне для оставшихся четырех платежей, сообщение request_credentials отправляется для запроса идентификационных данных для 1 дополнительного платежа, используя ввод ПИН пользователем для попытки мобильного бесконтактного платежа в торговой точке; если остаются идентификационные данные для оставшихся трех платежных транзакций, запрос направляется для 2 дополнительных платежей, используя ввод ПИН пользователем для попытки мобильного бесконтактного платежа в торговой точке; если есть идентификационные данные для 2 платежных транзакций или только 1 платежной транзакции, пользователю предлагается ввести ПИН-код в приложении мобильного телефона для обработки платежей для запроса новых идентификационных данных, их получения и хранения (до достижения лимита платежных идентификационных данных на мобильном телефоне).
Таким образом, приложение мобильного телефона ограничивает запрос новых идентификационных данных на основании информации об идентификационных данных, которые уже хранятся на мобильном телефоне. Преимущественно данная функция позволяет поставщику платежных услуг контролировать объем доступных идентификационных данных на мобильном телефоне пользователя и управлять им, тем самым оставляя часть предоставленного права на модуле платежного сервера.
Модуль транзакций или безопасности на модуле платежного сервера может потребовать отключения (или удаления) по меньшей мере одного элемента идентификационных данных в приложении мобильного телефона посредством отправки отключающего (или удаляющего) сообщения с модуля платежного сервера на приложение мобильного телефона пользователя. Так поставщик платежных услуг все еще может управлять идентификационными данными в онлайн-режиме при их наличии в приложении мобильного телефона.
В варианте реализации идентификационные данные платежей блокируются в приложении мобильного телефона после нескольких попыток ввода неправильного персонального идентификационного номера, и на модуль платежного сервера отправляется уведомление. В другом варианте реализации модуль платежного сервера блокирует предоставленное право на совершение платежей после нескольких попыток ввода неверного пароля ОРП, полученного от приложения мобильного телефона, и сообщение о блокировке идентификационных данных передается на приложение мобильного телефона. Так, у поставщика платежных услуг есть ПИН и инструменты управления безопасностью и в приложении, и со стороны модуля платежного сервера.
Фиг. 2.с представляет собой блок-схему, частично иллюстрирующую вариант реализации способа согласно изобретению.
В этом варианте реализации для онлайн-транзакций мобильных бесконтактных платежей самим приложением мобильного телефона рассчитывается вторая часть платежного элемента идентификационных данных, причем рассчитывается она с использованием значения транзакции и ПИН пользователя в качестве вводных данных для формирования результирующего ОРП (второй части элемента идентификационных данных). Первая и вторая части элемента идентификационных данных используются для транзакции мобильного бесконтактного платежа, и требуется проверка такого ОРП модулем платежного сервера, чтобы принять или отклонить транзакцию.
В другом варианте реализации для онлайн-транзакций мобильных бесконтактных платежей самим приложением мобильного телефона рассчитывается вторая часть элемента идентификационных данных, причем рассчитывается она с использованием ПИН пользователя в качестве вводных данных для формирования результирующего ОРП как второй части элемента идентификационных данных. Первая и вторая части элемента идентификационных данных используются для транзакции мобильного бесконтактного платежа, и требуется проверка такого ОРП модулем платежного сервера, чтобы принять или отклонить транзакцию.
В среде чипа EMV и ПИН номер PAN присваивается карте EMV, предоставленной пользователю (карта (А)). Данная карта включает другой набор данных, которые являются частью самого элемента идентификационных данных: дата истечения срока действия (CD), CVV и производный ключ для расчета криптограммы.
В данном варианте реализации платежный элемент идентификационных данных для карты VMC(A)i сначала формируется на модуле платежного сервера, таким образом PAN, CD, CVV и производный ключ рассчитываются со стороны сервера и отправляются вместе с BIN на приложение мобильных платежей. В конкретном примере номер PAN формируется с использованием hash(ID&AC) и справки о клиенте в качестве вводных данных.
В ходе онлайн-процесса платежей, который использует данный платежный элемент идентификационных данных VMC(A)i, ПИН вводится в приложении мобильного телефона для обработки платежей. В настоящем варианте реализации значение транзакции (сумма платежа) также вводится пользователем в приложении мобильного телефона для обработки платежей, так что и значение транзакции и ПИН пользователя используются в качестве вводных данных для формирования результирующего ОРП (второй части элемента идентификационных данных). В конкретном примере ОРП представляет собой результат из 7 цифр, CD' (4 цифры) и CVV' (3 цифры). CD' представляет собой действительный срок годности в системе платежных средств.
Попытка совершения транзакции бесконтактного платежа выполняется с помощью BIN/PAN/CD'/CVV' и криптограммы в качестве идентификационных данных, так что первая часть элемента идентификационных данных рассчитана на сервере, а вторая часть - в приложении мобильного телефона для обработки платежей с использованием ПИН и значения транзакции в качестве вводных данных. Модуль платежного сервера обрабатывает полученный PAN и получает справочные данные клиента и устройств, чтобы присвоить транзакцию конкретному счету (ПИН, ключи ОРП и т.д.). В контексте онлайн-транзакции значение транзакции является известным со стороны сервера, а ПИН сохраняется в модуле платежного сервера, чтобы ОРП мог быть проверен модулем платежного сервера. Если проверка ОРП является успешной, идентификационные данные подтверждаются, и транзакция может быть санкционирована со стороны банка как транзакция по карте (А). Ответные сообщения в банк-получатель тем не менее относятся к транзакции VMC(A)i.
Преимущественно расчет части элемента идентификационных данных в приложении мобильного телефона для обработки платежей предоставляет пользователю и системе более высокий уровень безопасности в онлайн-режиме платежных идентификационных данных.
Фиг. 2.d представляет собой блок-схему, частично иллюстрирующую вариант реализации способа согласно изобретению. Первая часть схемы показывает мобильный бесконтактный онлайн-платеж (1), наподобие представленного на фиг. 2.с, где первая часть элемента идентификационных данных представлена BIN/PAN/CS/CD/CVV и производным ключом, а вторая часть относится к значениям CD' и CVV', рассчитанным в мобильном телефоне (криптограмма рассчитывается на основании производного ключа).
В контексте настоящего варианта реализации такая транзакция мобильного бесконтактного онлайн-платежа (1), которая использует первую и вторую часть элемента идентификационных данных, уже была принята («первая транзакция»), и по меньшей мере одна дополнительная транзакция (2), которая впоследствии использует по меньшей мере часть тех же самых первой и второй части элемента идентификационных данных («последующие транзакции») принимается на основании проверки ОРП первой транзакции.
На фиг. 2.d также представлено значение DDBB значений PAN/CD'/CVV' предварительно принятых транзакций мобильных бесконтактных онлайн-платежей, которое позволяет отслеживать, является ли конкретная транзакция последующей или нет. Так, каждая из последующих транзакций сопоставляется с первой транзакцией на основании использования, по меньшей мере, частично первой и второй части элемента идентификационных данных.
В другом конкретном варианте реализации каждая из последующих транзакций сопоставляется с первой транзакцией на основании использования указанной по меньшей мере части первой и второй части элемента идентификационных данных и использования по меньшей мере одного дополнительного параметра, включаемого в транзакционный поток первой и последующих транзакций. В конкретном примере одним дополнительным параметром является код торговой точки. Так, в данном варианте реализации значение DDBB ранее принятых транзакций MVC также должно включать, по меньшей мере, один указанный дополнительный параметр.
Иногда элемент идентификационных данных для Интернет-платежа представляет собой подмножество элемента идентификационных данных для мобильного бесконтактного платежа, чтобы была возможность выполнить Интернет-платеж с помощью такого подмножества. В варианте реализации пользователь выбирает через свое приложение мобильного телефона для обработки платежей Интернет-платеж, и вторая часть элемента идентификационных данных (значения CD' и CVV' на фиг. 2.d.1) наряду по меньшей мере с частью первой части идентификационных данных (BIN/PAN/CS на фиг. 2.d.1) используется для выполнения такого платежа.
Та же самая логика, уже описанная на фиг. 2.d для мобильных бесконтактных онлайн-платежей, относящаяся к приему последующих транзакций на основании проверенной электронной подписи первой транзакции, может также применяться для Интернет-платежей. В варианте реализации Интернет-транзакция, которая использует по меньшей мере часть первой части элемента идентификационных данных и второй части элемента идентификационных данных, уже была принята («первая транзакция»), и по меньшей мере одна дополнительная транзакция, которая впоследствии использует по меньшей мере часть первой и второй части элемента идентификационных данных («последующие транзакции») принимается на основании проверки ОРП первой транзакции.
В конкретном варианте реализации каждая из последующих транзакций сопоставляется с первой транзакцией на основании использования по меньшей мере части первой и второй части элемента идентификационных данных. В другом варианте реализации по меньшей мере дополнительный параметр может быть добавлен для повышения эффективности процесса сопоставления, при включении такого параметра в транзакционный поток первой и последующих транзакций.
Фиг. 2.е представляет собой блок-схему, частично иллюстрирующую вариант реализации способа для мобильных бесконтактных офлайн-платежей согласно изобретению.
Схема показывает заданный максимальный объем (10) идентификационных данных, хранящихся в мобильном телефоне в определенное время, и приложение мобильного телефона ограничивает мобильные бесконтактные офлайн-платежи с применением таких идентификационных данных до максимального значения совокупных платежных офлайн-транзакций. Поэтому совершение офлайн-платежей при совокупной высокой стоимости требует от пользователя правильного ввода значения ПИН, чтобы модуль платежного сервера отправил новые идентификационные данные на мобильный телефон зарегистрированного пользователя, и приложение мобильного телефона по обработке платежей снова установит совокупное значение транзакций офлайн-платежей в максимальном размере. Этапы (1) и (Г) показывают, как пользователь совершает мобильный бесконтактный офлайн-платеж, а авторизация отправляется на модуль платежного сервера в режиме пакетной обработки. Так, для мобильных бесконтактных офлайн-транзакций модуль платежного сервера проверяет ОРП на основании уже имеющихся данных.
На этапе (2) может быть выполнен процесс обновления идентификационных данных, в связи с тем, что пользователь ввел значение ПИН для платежа. Если значение ПИН не является правильным, процесс обновления идентификационных данных не выполняется.
Доступные идентификационные данные при Т=0 относятся к максимальной сумме мобильных бесконтактных офлайн-платежей. Этап (3) показывает, как максимальная сумма мобильных бесконтактных офлайн-платежей снижается до (XX-Y) евро после платежей при Τ=1, и как доступное значение суммы офлайн-платежей обновляется до максимального значения X евро после успешного процесса обновления идентификационных данных (результат правильного ввода ПИН пользователем на мобильном телефоне).
Фиг. 2.f представляет собой блок-схему, частично иллюстрирующую другой вариант реализации способа для мобильных бесконтактных офлайн-платежей согласно изобретению.
В данном варианте реализации существует максимальное заранее определенное число первой части набора идентификационных данных для мобильных бесконтактных офлайн-платежей, которые могут храниться в мобильном телефоне в заданный момент времени, и, после того, как истечет срок действия первой части всех идентификационных данных, платежное приложение мобильного телефона ограничивает мобильные бесконтактные офлайн-платежи, которые используют первую часть всех идентификационных данных. Поэтому, чтобы выполнить мобильные бесконтактные офлайн-платежи после того, как срок действия первой части набора идентификационных данных для мобильных бесконтактных офлайн-платежей истечет, пользователь должен правильно ввести ПИН, чтобы модуль платежного сервера отправил новые действительные первые части идентификационных данных для мобильных бесконтактных офлайн-платежей на мобильный телефон зарегистрированного пользователя.
Шаг (1) показывает, как пользователь вводит ПИН для запроса первой части набора идентификационных данных для мобильных бесконтактных офлайн-платежей. Значение ОРП(ПИН) проверяется, и, если оно правильное, такие частично рассчитанные идентификационные данные загружаются в мобильный телефон. В конфетном примере загружается только один элемент идентификационных данных, действительный в течение нескольких минут.
Процесс (2) показывает мобильный бесконтактный офлайн-платеж. Пользователь вводит ПИН через приложение мобильных платежей и проводит мобильный телефон рядом с кассовым терминалом торговой точки (POS). Приложение мобильных платежей затем получает от кассового терминала сумму и тип транзакции (офлайн), выбирает частично рассчитанный элемент идентификационных данных для офлайн-платежей и рассчитывает ОРП (сумму транзакции, ПИН) и криптограмму для офлайн-платежа.
На этапе (3) мобильные бесконтактные офлайн-транзакции отправляются на модуль платежного сервера в режиме пакетной обработки. Как только пользователю предлагается снова ввести ПИН в процессе (2), модуль платежного сервера сможет проверить ПИН на основании уже имеющихся данных.
На фиг. 2.g представлена блок-схема, частично иллюстрирующая вариант реализации способа, согласно изобретению, с альтернативным способом для пользователя по оплате определенных услуг покупки билетов/обработки платежей поставщику услуг.
Фиг. 2.g.1 немного изменяет процесс, описанный в связи с фиг. 1.b, и теперь этап (2) разделяется на этапы (2.а)-(2.d). На этапе (2.а) одна или несколько торговых точек платят «от имени пользователя» поставщику услуг покупки билетов за определенные услуги покупки билетов для пользователя, в контексте программы лояльности, предлагаемой торговой точкой (точками). В конкретном примере торговая точка (точки) платят за транспортное право, представленное в виде карты «А» на модуле сервера, и элемент идентификационных данных VMC(A) затем формируется модулем сервера покупки билетов.
На этапе (2.b) пользователь запрашивает (уже оплаченные) услуги покупки билетов через канал веб-дистрибуции, и процесс продолжается согласно описанию в связи с фиг. 1.b.
Далее пользователь платит за определенные товары и/или услуги в одной или нескольких связанных торговых точках (этап (2.с)), и, по меньшей мере, одна торговая точка передает часть сумм таких транзакций поставщику услуг покупки билетов (шаг (2.d)), чтобы он предложил определенные услуги покупки билетов пользователю. В конфетном варианте реализации совокупные суммы транзакций используются для предоставления пользователю определенных прав на новые идентификационные данные VMC(A). Поэтому благодаря программе лояльности, к которой обращаются для оплаты прав покупки билетов от имени пользователя, пользователь сможет использовать свое приложение мобильного телефона по покупке билетов для доступа к услугам покупки билетов в разных точках доступа (например, для посадки на любой городской автобус).
Аналогично, фиг. 2.g.2 изменяет процесс, описанный в связи с фиг. 2.b, и теперь этап (2) разделяется на этапы (2.а)-(2.d). На этапе (2.а) одна или несколько торговых точек платят «от имени пользователя» поставщику платежных услуг за определенные услуги обработки платежей для пользователя, в контексте программы лояльности, предлагаемой торговой точкой (точками). В конкретном примере торговая точка (точки) платят за платежное право, представленное в виде карты «А» на модуле сервера, и идентификационные данные VMC(A) затем формируются модулем платежного сервера.
На этапе (2.b) пользователь запрашивает (уже оплаченные) услуги обработки платежей через канал веб-дистрибуции, и процесс продолжается согласно описанию в связи с фиг. 2.b.
Далее пользователь платит за определенные товары и/или услуги в одной или нескольких связанных торговых точках (этап (2.с)), и, по меньшей мере, одна торговая точка передает часть сумм таких транзакций поставщику платежных услуг (шаг (2.d)), чтобы он предложил определенные услуги обработки платежей пользователю. В конкретном варианте реализации пользователь может использовать свое приложение мобильного телефона для обработки платежей, чтобы платить в торговых точках до достижения лимита сумм транзакций, сформированных в результате различных покупок, по меньшей мере, в одной торговой точке. Так, в рамках такого варианта реализации пользователь может совершать платежи в любой торговой точке, которая поддерживает мобильные бесконтактные платежи (вместо использования терминала лояльности с закрытым контуром в ограниченном количестве соответствующих торговых точек).
Хотя настоящее изобретение было подробно описано в целях наглядности, известно, что подробное описание предназначено исключительно для этой цели, и могут вноситься изменения при наличии соответствующей квалификации в данной сфере без уклонения от предмета изобретения. Кроме того, несмотря на то что были описаны предпочтительные варианты реализации способа и мобильной системы в отношении той среды, где они разрабатывались, они исключительно предназначены для наглядности принципов изобретения. Прочие варианты реализации и конфигурации могут разрабатываться без уклонения от предмета прилагаемой формулы.
Кроме того, несмотря на то что варианты реализации изобретения, описанные по чертежам, включают компьютерные средства и процессы, выполняемые в компьютерных средствах, изобретение также распространяется на компьютерные программы, в частности, компьютерные программы на носителе, приспособленные для воплощения изобретения в жизнь. Программа может быть выполнена в виде исходного кода, объектного кода, кода промежуточного источника и объектного кода в частично компилированной форме, или в иной форме, подходящей для использования при реализации процессов по изобретению. Носитель может представлять собой любое средство или устройство для хранения программы. Например, носитель может представлять собой носитель данных, например, ROM, CD ROM или полупроводниковую ROM, или магнитный записывающий носитель, например, дискету или жесткий диск.
Кроме того, носитель может представлять собой передающийся носитель, например, электрический или оптический сигнал, который может передаваться через электрический или оптический кабель, или по радио, или иным каналам. Если программа содержится в сигнале, который может быть передан непосредственно по кабелю или иным устройством или средством, носитель может быть представлен таким кабелем или иным устройством или средством. В качестве альтернативного варианта носитель может представлять собой интегральную схему, куда встроена программа, и такая интегральная схема приспособлена для выполнения или использования при выполнении соответствующих процессов.
| название | год | авторы | номер документа |
|---|---|---|---|
| СПОСОБ И СИСТЕМА ЭЛЕКТРОННЫХ ПЛАТЕЖЕЙ, В ЧАСТНОСТИ С ИСПОЛЬЗОВАНИЕМ БЕСКОНТАКТНЫХ ПЛАТЕЖНЫХ СРЕДСТВ | 2010 |
|
RU2543938C2 |
| СИСТЕМЫ И СПОСОБЫ МОБИЛЬНЫХ РАСЧЕТОВ | 2015 |
|
RU2672132C2 |
| ДОВЕРЕННЫЙ ВНУТРЕННИЙ ИНТЕРФЕЙС | 2011 |
|
RU2589373C2 |
| СИСТЕМЫ И СПОСОБЫ МОБИЛЬНЫХ РАСЧЕТОВ | 2016 |
|
RU2679550C2 |
| СИСТЕМА И СПОСОБ ОБЕСПЕЧЕНИЯ АУТЕНТИФИКАЦИИ ДЛЯ ТРАНЗАКЦИЙ БЕЗ НАЛИЧИЯ КАРТЫ С ИСПОЛЬЗОВАНИЕМ МОБИЛЬНОГО УСТРОЙСТВА | 2010 |
|
RU2556453C2 |
| АРХИТЕКТУРА ПРИЛОЖЕНИЯ МОБИЛЬНЫХ ПЛАТЕЖЕЙ | 2010 |
|
RU2505857C2 |
| РАСШИРЕННОЕ ВЗАИМОДЕЙСТВИЕ УСТРОЙСТВ | 2017 |
|
RU2718972C1 |
| ВЗАИМНАЯ МОБИЛЬНАЯ АУТЕНТИФИКАЦИЯ С ИСПОЛЬЗОВАНИЕМ ЦЕНТРА УПРАВЛЕНИЯ КЛЮЧАМИ | 2011 |
|
RU2580809C2 |
| ПЛАТЕЖНЫЙ ТЕРМИНАЛ С ИСПОЛЬЗОВАНИЕМ МОБИЛЬНОГО КОММУНИКАЦИОННОГО УСТРОЙСТВА, ТАКОГО КАК МОБИЛЬНЫЙ ТЕЛЕФОН, И СПОСОБ БЕЗНАЛИЧНЫХ ПЛАТЕЖЕЙ | 2010 |
|
RU2543935C2 |
| Способ обеспечения доступа пользователя к услугам локального оператора услуг, оконечное устройство пользователя и сервер системы для реализации способа | 2018 |
|
RU2686618C1 |
Изобретение относится к способам и системе обеспечения мобильной бесконтактной покупки билетов/обработки платежей. Технический результат заключается в обеспечении безопасности покупок билетов/обработки платежей. В способе с помощью мобильного телефона пользователя выполняют регистрацию для услуг покупки билетов/обработки платежей, получение элемента идентификационных данных покупки билетов/обработки платежей, подготовленного сервером, однозначно связанного с мобильным телефоном зарегистрированного пользователя и частично адаптирующего мобильный телефон для доступа к бесконтактной покупке билетов или для мобильных бесконтактных платежей, сохранение идентификационных данных для использования в транспортной бесконтактной системе покупки билетов или для использования при мобильных бесконтактных платежах, требование, чтобы пользователь ввел персональный идентификационный номер ПИН в приложении мобильного телефона при каждом доступе к бесконтактной покупке билетов или мобильному бесконтактному совершению платежей, получение идентификационных данных на приложении мобильного телефона до достижения лимита предоставленного права на использование бесконтактных услуг по покупке билетов/обработке платежей. 3 н. и 39 з.п. ф-лы, 10 ил.
1. Способ обеспечения мобильной бесконтактной покупки билетов/обработки платежей через приложение мобильного телефона, содержащий следующие этапы, согласно которым:
a) пользователь платит поставщику услуг за услуги покупки билетов/обработки платежей;
b) в связи с платежом и с соответствующим предоставленным правом на использование услуг покупки билетов/обработки платежей модуль сервера покупки билетов/обработки платежей готовит по меньшей мере один элемент идентификационных данных покупки билетов/обработки платежей для использования пользователем и отправляет по меньшей мере один элемент идентификационных данных покупки билетов/обработки платежей на мобильный телефон пользователя;
c) мобильный телефон пользователя получает указанный по меньшей мере один элемент идентификационных данных и сохраняет их для использования в транспортной системе бесконтактной покупки билетов, если речь идет об идентификационных данных для покупки билетов, или для использования в системе мобильных бесконтактных платежей, если речь идет об идентификационных данных для обработки платежей;
отличающийся тем, что каждый подготовленный элемент идентификационных данных однозначно связан с мобильным телефоном зарегистрированного пользователя и частично адаптирует мобильный телефон для доступа к бесконтактной покупке билетов, если речь идет об идентификационных данных для покупки билетов, или для мобильных бесконтактных платежей, если речь идет об идентификационных данных для совершения платежей; при этом адаптация мобильного телефона при каждом доступе к бесконтактной покупке билетов или мобильному бесконтактному совершению платежей также требует от пользователя ввода персонального идентификационного номера ПИН в приложении мобильного телефона для покупки билетов/обработки платежей; а идентификационные данные отправляют на приложение мобильного телефона до достижения лимита предоставленного права на использование бесконтактных услуг по покупке билетов/обработке платежей.
2. Способ по п. 1, согласно которому ПИН, введенный пользователем, используют для вычисления по меньшей мере части указанного элемента идентификационных данных покупки билетов/обработки платежей, используемого в контексте данного мобильного бесконтактного доступа к покупке билетов/обработке платежей.
3. Способ по п. 1, согласно которому по меньшей мере часть идентификационных данных покупки билетов/обработки платежей, полученная на мобильный телефон и сохраненная в нем, содержит ключ, который впоследствии используют для вычисления по меньшей мере части указанного элемента идентификационных данных покупки билетов/обработки платежей, используемого в контексте данного мобильного бесконтактного доступа к покупке билетов/обработке платежей.
4. Способ по п. 1, согласно которому по меньшей мере один элемент идентификационных данных однозначно связан с кодом активации.
5. Способ по п. 1, согласно которому идентификационные данные отправляют на приложение мобильного телефона после их запроса с мобильного устройства пользователя.
6. Способ по п. 1, согласно которому пользователю предлагают ввести в приложении мобильного телефона ПИН-код для запроса новых идентификационных данных на модуле сервера покупки билетов/обработки платежей и их последующего получения мобильным телефоном и хранения в нем.
7. Способ по п. 1, согласно которому модуль сервера покупки билетов/обработки платежей отправляет идентификационные данные на мобильный телефон зарегистрированного пользователя после успешной проверки ПИН, введенного пользователем на мобильном телефоне.
8. Способ по п. 1, согласно которому модуль сервера покупки билетов/обработки платежей отправляет идентификационные данные на мобильный телефон зарегистрированного пользователя после успешного подтверждения разового пароля ОРП, полученного от приложения мобильного телефона по покупке билетов/обработке платежей.
9. Способ по п. 1, согласно которому модуль сервера покупки билетов/обработки платежей разделяет предоставленное право покупки билетов/обработки платежей на несколько порций и формирует отдельный элемент идентификационных данных для каждой из этих порций.
10. Способ по п. 1, согласно которому первый набор идентификационных данных отправляют на приложение мобильного телефона, а новые идентификационные данные отправляют на приложение мобильного телефона при последующем запросе с мобильного устройства пользователя до достижения лимита предоставленного права на использование бесконтактных услуг покупки билетов/обработки платежей.
11. Способ по п. 1, согласно которому по меньшей мере один элемент идентификационных данных отключают в приложении мобильного телефона или удаляют из этого приложения мобильного телефона путем отправки отключающего или удаляющего сообщения с модуля сервера покупки билетов/обработки платежей на приложение мобильного телефона пользователя.
12. Способ по п. 1, согласно которому обеспечивают возможность продления права использования услуг покупки билетов/обработки платежей пользователем, оплатившим его, с обеспечением динамической генерации новых порций права на покупку билетов/обработку платежей на модуле сервера покупки билетов/обработки платежей.
13. Способ по п. 6, согласно которому приложение мобильного телефона ограничивает запрос новых идентификационных данных на основании информации о том, что идентификационные данные уже сохранены в мобильном телефоне.
14. Способ по п. 1, согласно которому идентификационные данные покупки билетов/обработки платежей блокируют в приложении мобильного телефона после нескольких попыток ввода неправильного персонального идентификационного номера, при этом на модуль сервера покупки билетов/обработки платежей отправляют уведомление.
15. Способ по п. 1, согласно которому модуль сервера покупки билетов/обработки платежей блокирует предоставленное право покупки билетов/обработки платежей после нескольких попыток ввода неверного пароля ОРП, полученного от приложения мобильного телефона, при этом на приложение мобильного телефона передают сообщение о блокировке идентификационных данных.
16. Способ по п. 1, согласно которому для онлайн-транзакций мобильных бесконтактных платежей с помощью самого приложения мобильного телефона рассчитывают вторую часть указанного элемента идентификационных данных, причем рассчитывают ее с использованием значения транзакции и ПИН пользователя в качестве входных данных для формирования результирующего ОРП как указанной второй части элемента идентификационных данных, при этом первую и вторую части элемента идентификационных данных используют для транзакции мобильного бесконтактного платежа, а для принятия или отклонения указанной транзакции осуществляют необходимую проверку такого ОРП модулем платежного сервера.
17. Способ по п. 1, согласно которому для онлайн-транзакций мобильных бесконтактных платежей с помощью самого приложения мобильного телефона рассчитывают вторую часть указанного элемента идентификационных данных, причем рассчитывают ее с использованием ПИН пользователя в качестве входных данных для формирования результирующего ОРП как указанной второй части элемента идентификационных данных, при этом первую и вторую части элемента идентификационных данных используют для транзакции мобильного бесконтактного платежа, а для принятия или отклонения указанной транзакции осуществляют необходимую проверку такого ОРП модулем платежного сервера.
18. Способ по п. 1 или 17, согласно которому идентификационные данные шифруют в модуле сервера покупки билетов/обработки платежей с использованием ПИН, так что адаптация мобильного телефона для доступа к бесконтактной покупке билетов или для мобильных бесконтактных платежей также требует ввода пользователем ПИН в приложении мобильного телефона для покупки билетов/обработки платежей.
19. Способ по п. 17, согласно которому транзакция мобильного бесконтактного онлайн-платежа («первая транзакция»), которая использует первую и вторую часть элемента идентификационных данных, уже была принята, при этом по меньшей мере одну дополнительную транзакцию («последующие транзакции»), которая впоследствии использует по меньшей мере часть тех же самых первой и второй частей элемента идентификационных данных, принимают на основании проверки ОРП указанной первой транзакции.
20. Способ по п. 19, согласно которому каждую из последующих транзакций сопоставляют с первой транзакцией на основании использования указанной по меньшей мере части первой и второй частей элемента идентификационных данных.
21. Способ по п. 19, согласно которому каждую из последующих транзакций сопоставляют с первой транзакцией на основании использования указанной по меньшей мере части первой и второй частей элемента идентификационных данных и использования по меньшей мере одного дополнительного параметра, включаемого в транзакционный поток первой и последующих транзакций.
22. Способ по п. 1, согласно которому задают максимальный объем идентификационных данных, хранящихся в мобильном телефоне в заданный момент времени, и приложение мобильного телефона ограничивает мобильные бесконтактные офлайн-платежи с применением таких идентификационных данных до максимального значения совокупных платежных офлайн-транзакций.
23. Способ по п. 17, согласно которому пользователь выбирает через свое платежное приложение мобильного телефона Интернет-платеж, при этом вторую часть элемента идентификационных данных вместе по меньшей мере с частью первой части элемента идентификационных данных используют для выполнения такого платежа.
24. Способ по п. 23, согласно которому Интернет-транзакция («первая транзакция»), которая использует по меньшей мере часть первой части элемента идентификационных данных и второй части элемента идентификационных данных, уже была принята, при этом по меньшей мере одну дополнительную транзакцию («последующие транзакции»), которая впоследствии использует по меньшей мере части первой части элемента идентификационных данных и второй части элемента идентификационных данных, принимают на основании проверки ОРП указанной первой транзакции.
25. Способ по п. 24, согласно которому каждая из последующих транзакций связана с первой транзакцией на основании использования указанной по меньшей мере части первой части элемента идентификационных данных и второй части элемента идентификационных данных.
26. Способ по п. 24, согласно которому каждая из последующих транзакций связана с первой транзакцией на основании использования по меньшей мере части первой части элемента идентификационных данных и второй части элемента идентификационных данных и использования по меньшей мере одного дополнительного параметра, включаемого в транзакционный поток первой и последующих транзакций.
27. Способ по п. 1, согласно которому задают максимальный объем первой части набора идентификационных данных для мобильных бесконтактных офлайн-платежей, хранящихся в мобильном телефоне в заданный момент времени, при этом по истечению срока действия первой части всех идентификационных данных платежное приложение мобильного телефона ограничивает мобильные бесконтактные офлайн-платежи, использующие первую часть каждого из этих идентификационных данных.
28. Система, обеспечивающая мобильную бесконтактную покупку билетов/обработку платежей через приложение мобильного телефона, включающая:
средства регистрации для регистрации пользователей услуг покупки билетов/обработки платежей,
средства оплаты, позволяющие пользователю оплатить услуги покупки билетов/обработки платежей,
средства формирования идентификационных данных для формирования на модуле сервера покупки билетов/обработки платежей на основании предоставленных прав покупки билетов/обработки платежей по меньшей мере одного элемента идентификационных данных покупки билетов/обработки платежей для использования зарегистрированным пользователем;
средства передачи для отправки по меньшей мере одного элемента идентификационных данных на мобильный телефон зарегистрированного пользователя; и
средства приема и хранения для получения по меньшей мере одного элемента идентификационных данных на мобильном телефоне и их хранения для использования в транспортной бесконтактной системе покупки билетов в случае идентификационных данных для покупки билетов или для использования при мобильных бесконтактных платежах в случае идентификационных данных для совершения платежей,
отличающаяся тем, что указанная система содержит средства обработки для однозначной привязки каждого элемента идентификационных данных, который частично адаптирует мобильный телефон для доступа к бесконтактной покупке билетов в случае идентификационных данных для покупки билетов или к мобильным бесконтактным платежам в случае идентификационных данных для совершения платежей, к мобильному телефону зарегистрированного пользователя; средства обработки и проверки для обеспечения адаптации мобильного телефона для каждого доступа к бесконтактной покупке билетов (или мобильным бесконтактным платежам), который также основан на персональном идентификационном номере (ПИН), введенном пользователем в приложении мобильного телефона для покупки билетов/обработки платежей; а с использованием средств передачи обеспечена возможность отправки идентификационных данных на приложение мобильного телефона до достижения лимита предоставленного права на использование бесконтактных услуг по покупке билетов/обработке платежей.
29. Система по п. 28, в которой приложение мобильного телефона для покупки билетов/обработки платежей дополнительно содержит средства обработки и передачи для вычисления запроса идентификационных данных и его отправки на модуль сервера покупки билетов/обработки платежей, который содержит средства обработки и проверки для подтверждения запроса идентификационных данных.
30. Система по п. 29, в которой запрос идентификационных данных содержит значение ОРП, а модуль сервера покупки билетов/обработки платежей подтверждает полученный ОРП.
31. Система по пп. 28, 29 или 30, в которой обеспечена возможность выполнения способа по п. 1.
32. Способ, связанный с использованием мобильного телефона пользователя для обеспечения мобильной бесконтактной покупки билетов/обработки платежей через приложение мобильного телефона, включающий:
регистрацию мобильного телефона пользователя для услуг покупки билетов/обработки платежей;
получение на мобильный телефон по меньшей мере одного элемента идентификационных данных покупки билетов/обработки платежей, подготовленного модулем сервера покупки билетов/обработки платежей, причем подготовка идентификационных данных связана с платежом пользователя поставщику услуг за услуги покупки билетов/обработки платежей и с соответствующим предоставленным правом на использование услуг покупки билетов/обработки платежей, при этом каждый подготовленный элемент идентификационных данных однозначно связан с мобильным телефоном зарегистрированного пользователя и частично адаптирует мобильный телефон для доступа к бесконтактной покупке билетов, в случае идентификационных данных для покупки билетов, или для мобильных бесконтактных платежей, в случае идентификационных данных для совершения платежей;
сохранение полученных идентификационных данных в мобильном телефоне пользователя для использования в транспортной бесконтактной системе покупки билетов в случае идентификационных данных для покупки билетов или для использования при мобильных бесконтактных платежах в случае идентификационных данных для совершения платежей;
требование, чтобы пользователь ввел персональный идентификационный номер ПИН в приложении мобильного телефона для покупки билетов/обработки платежей при каждом доступе к бесконтактной покупке билетов или мобильному бесконтактному совершению платежей;
получение идентификационных данных на приложении мобильного телефона до достижения лимита предоставленного права на использование бесконтактных услуг по покупке билетов/обработке платежей.
33. Способ по п. 32, согласно которому ПИН, введенный пользователем, используют для вычисления по меньшей мере части указанного элемента идентификационных данных покупки билетов/обработки платежей, используемого в контексте данного мобильного бесконтактного доступа к покупке билетов/обработке платежей.
34. Способ по п. 32, согласно которому по меньшей мере часть идентификационных данных покупки билетов/обработки платежей, полученная на мобильный телефон и сохраненная в нем, содержит ключ, который впоследствии используют для вычисления по меньшей мере части указанного элемента идентификационных данных покупки билетов/обработки платежей, используемого в контексте данного мобильного бесконтактного доступа к покупке билетов/обработке платежей.
35. Способ по п. 32, согласно которому идентификационные данные получают на приложение мобильного телефона после их запроса с мобильного устройства пользователя у модуля сервера покупки билетов/обработки платежей.
36. Способ по п. 32, согласно которому пользователю предлагают ввести в приложении мобильного телефона ПИН-код для запроса новых идентификационных данных у модуля сервера покупки билетов/обработки платежей и для их последующего получения мобильным телефоном и хранения в этом мобильном телефоне.
37. Способ по п. 32, согласно которому мобильный телефон зарегистрированного пользователя получает идентификационные данные от модуля сервера покупки билетов/обработки платежей после успешной проверки ПИН модулем сервера покупки билетов/обработки платежей.
38. Способ по п. 32, согласно которому первый набор идентификационных данных получают на приложение мобильного телефона, а новые идентификационные данные получают на приложение мобильного телефона при последующем запросе с мобильного устройства пользователя, обращенном к модулю сервера покупки билетов/обработки платежей, до достижения лимита предоставленного права на использование бесконтактных услуг покупки билетов/обработки платежей.
39. Способ по п. 35, согласно которому приложение мобильного телефона ограничивает запрос новых идентификационных данных на основании информации о том, что идентификационные данные уже сохранены в мобильном телефоне.
40. Способ по п. 32, согласно которому для онлайн-транзакций мобильных бесконтактных платежей с помощью самого приложения мобильного телефона рассчитывают вторую часть указанного элемента идентификационных данных, причем рассчитывают ее с использованием значения транзакции и ПИН пользователя в качестве входных данных для формирования результирующего ОРП как указанной второй части элемента идентификационных данных, при этом первую и вторую части элемента идентификационных данных используют для транзакции мобильного бесконтактного платежа, а для принятия или отклонения указанной транзакции осуществляют необходимую проверку такого ОРП модулем платежного сервера.
41. Способ по п. 32, согласно которому для онлайн-транзакций мобильных бесконтактных платежей с помощью самого приложения мобильного телефона рассчитывают вторую часть указанного элемента идентификационных данных, причем рассчитывают ее с использованием ПИН пользователя в качестве входных данных для формирования результирующего ОРП как указанной второй части элемента идентификационных данных, при этом первую и вторую части элемента идентификационных данных используют для транзакции мобильного бесконтактного платежа, а для принятия или отклонения указанной транзакции осуществляют необходимую проверку такого ОРП модулем платежного сервера.
42. Способ по п. 32 или 41, согласно которому идентификационные данные в модуле сервера покупки билетов/обработки платежей шифруют с использованием ПИН, так что адаптация мобильного телефона для доступа к бесконтактной покупке билетов или для мобильных бесконтактных платежей также требует ввода пользователем ПИН в приложении мобильного телефона для покупки билетов/обработки платежей.
| Станок для изготовления деревянных ниточных катушек из цилиндрических, снабженных осевым отверстием, заготовок | 1923 |
|
SU2008A1 |
| US 20120019379 A1, 26.01.2012 | |||
| US 8200582 B1, 12.06.2012 | |||
| EP 1980985 A2, 15.10.2008 | |||
| Колосоуборка | 1923 |
|
SU2009A1 |
| СПОСОБ И УСТРОЙСТВО ДЛЯ ПРОВЕРКИ ПОДЛИННОСТИ ИЛИ ПРАВА С ИСПОЛЬЗОВАНИЕМ РАЗОВЫХ КОДОВ ТРАНЗАКЦИЙ | 2006 |
|
RU2414001C2 |
| Лабораторная планетарная мельница | 1958 |
|
SU117671A1 |
