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

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

Иллюстрации

Показать все

Реферат

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

Настоящая заявка испрашивает приоритет патентной заявки США № 61/185,924 (реестровый номер 016222-049000US), поданной 10 июня 2009 года, которая включена в настоящий документ по ссылке во всей своей полноте во всех целях.

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

Ключи активации, как подразумевается по названию, используются для активации чего-либо. Например, часть программного обеспечения может быть установлена на компьютере, но программное обеспечение может быть недействующим, пока оно не активировано с использованием ключа активации. Поставщик программного обеспечения может предоставлять ключ активации только тем, кто был авторизован использовать программное обеспечение. Ключи активации также могут использоваться для проверки, что человек, регистрирующийся на услугу, действительно авторизован для этого действия. Например, человек может зарегистрироваться в системе местной энергетической компании, чтобы просматривать свой домашний счет потребления энергии интерактивно через веб-сайт энергетической компании. Перед предоставлением доступа энергетическая компания может отправить по почте письмо, содержащее ключ активации, на домашний адрес абонентов. Если абонент сможет ввести ключ активации, то доступ будет предоставлен. Эта схема позволяет энергетической компании с определенной степенью уверенности делать вывод, что абонент действительно живет по этому адресу, поскольку у него есть доступ к почте, отправленной на этот адрес.

Ключи активации также могут использоваться для ограничения предложения выбранной группе. Например, продавец может отправить своим лучшим клиентам рекламу, которая включает в себя промо-код, который даст клиентам право на скидку при покупке. Промо-код представляет собой ключ активации, который активирует скидку. Продавец может не захотеть предлагать скидку каждому клиенту, таким образом, посредством использования ключа активации предложение может быть ограничено только теми, кто выбран для участия в акции.

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

Раскрыты системы и способы для активации услуги с использованием алгоритмически заданных ключей. Потребитель, который имеет отношение с первой стороной, может пожелать подписаться на услугу, предоставляемую третьей стороной. Первая сторона может обеспечить управление такой подпиской с помощью алгоритмически заданных ключей. Алгоритмически заданные ключи также позволяют стороннему поставщику услуг проверять данные, предоставленные потребителем, как соответствующие данным, хранящимся первой стороной. Третья сторона может управлять подпиской, ограничивая подписку только теми, кто обеспечивает данные, которые соответствуют данным, использованным для формирования алгоритмически заданных ключей. Проверка обеспечивает синхронизацию данных без требования, чтобы третья сторона имела доступ к системам обработки данных первой стороны.

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

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

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

Эти и другие варианты осуществления изобретения более подробно описаны ниже.

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

Фиг.1 изображает одну иллюстративную систему настоящего раскрытия.

Фиг.2 изображает активацию услуги на высоком уровне.

Фиг.3 изображает активацию услуги на более низком уровне.

Фиг.4 изображает блок-схему формирования ключей активации на высоком уровне.

Фиг.5 изображает блок-схему подписки на услугу с использованием ключа активации на высоком уровне.

Фиг.6 изображает блок-схему подписки на услугу.

Фиг.7 изображает другую иллюстративную систему настоящего раскрытия.

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

Фиг.9 изображает блок-схему мобильного устройства.

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

Все приведенные выше примеры использования ключа активации услуги имеют одну общую черту. Объект, который желает управлять доступом к услуге, также является тем же самым объектом, который предоставляет услугу. Варианты осуществления настоящего раскрытия предусматривают выгодное использование ключей активации услуги, когда объект, управляющий доступом к услуге, отличается от объекта, предоставляющего услугу. Управляющий объект выгодным образом поддерживает управление, посредством которого абонентам дается возможность подписаться на услугу посредством поддержки управления распределением ключей активации. Поставщик услуг в свою очередь выгодным образом может проверить, что подписывающиеся на услугу авторизованы для подписки на услугу. Кроме того, варианты осуществления раскрытия выгодным образом дают возможность объекту управления и поставщику услуг гарантировать проверенную синхронизацию данных между базами данных объекта управления и базами данных поставщика услуг. Эта синхронизация выгодным образом достигается без требования, чтобы какая-либо сторона имела прямой доступ к системам хранения данных других сторон. Изоляция систем хранения данных выгодным образом предотвращает нарушение безопасности системы обработки данных любой стороны от каскадного эффекта нарушения систем обработки данных партнеров.

Может возникнуть много ситуаций, в которых человек, ассоциированный с организацией, может запросить или быть приглашен подписаться на услугу, предоставляемую поставщиком услуг, который отличается от организации. Например, человек может иметь кредитную карту, которая была выпущена банком. Банк может пригласить клиента подписаться на услугу денежных переводов (MT), которая предоставляется третьей стороной. Услуга денежных переводов может позволить клиенту, который также может упоминаться как держатель карты, переводить средства со счета своей кредитной карты на некоторый другой счет. Хотя кредитная карта предоставлена банком, который также может упоминаться как эмитент, сам эмитент не является поставщиком услуги денежных переводов.

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

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

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

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

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

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

Фиг.1 изображает одну иллюстративную систему настоящего раскрытия. Пример, представленный относительно системы 100, дан с точки зрения организации, которая может являться банком, выпускающим кредитные карты, и, таким образом, организация упоминается как эмитент 102. Однако следует понимать, что варианты осуществления раскрытия применимы в любых ситуациях и не ограничены эмитентом кредитной карты. Эмитент 102 может иметь данные относительно своих клиентов, сохраненные в базе 104 данных клиентов. Примеры таких данных изображены в таблице 106. Эмитент может хранить данные об имени клиента, его адресе, его номере счета или любые другие данные, которые требуются эмитенту для ведения бизнеса.

Поставщик 108 услуг может предоставлять любую из нескольких услуг, таких как услуга денежных переводов, клиенту 110 эмитента 102. С точки зрения данного примера клиент 110 эмитента 102 будет человеком, держащим кредитную карту, выпущенную эмитентом 102, и будет упоминаться как держатель 110 карты. Это вновь сделано только ради объяснения, поскольку любой клиент любой организации также может использовать варианты осуществления настоящего раскрытия.

В начальной установке системы эмитент 102 может обмениваться 120 данными пароля с поставщиком 108 услуг. Пароль также может упоминаться как фраза-пароль. Следует понимать, что пароль является информацией, обычно строкой алфавитно-цифровых символов, которая известна только эмитенту 102 и поставщику 108 услуг. Эмитент 102 может сохранить пароль в репозитарии 112 данных паролей. Аналогичным образом поставщик 108 услуг также может сохранить пароль в репозитарии 114 данных паролей. Обычно пароль сохраняется в некотором зашифрованном формате, и таким образом предотвращается, чтобы сотрудники эмитента 102 или поставщика 108 непосредственно видели пароль. Пароль расшифровывается системой только при использовании.

Как было бы понятно любому, кто знаком с безопасностью электронных систем, обычно требуется периодически изменять пароль. Например, соглашение между поставщиком 108 услуг и эмитентом 102 может требовать, чтобы пароль изменялся каждые 3 месяца. Таким образом, если пароль взломан, он будет допустим только в течение определенного периода времени, что ограничивает потенциальный вред, который может причинить злоумышленник, владеющий паролем. В качестве дополнительной меры безопасности пароль может быть обязан иметь некоторую длину, например, больше 6, 8 или 12 символов. Пароль может быть обязан содержать буквы, буквы и числа или буквы, числа и специальные символы. Такие меры безопасности могут ограничить возможность злоумышленника случайным образом угадать пароль, поскольку количество потенциальных паролей увеличивается с помощью длины и типов используемых символов.

Системе может требоваться поддерживать более одного пароля в любой момент времени, поскольку более старые пароли могут быть необходимы для правильного функционирования системы, как будет объяснено более подробно в отношении фиг.2. Пока достаточно сказать, что эмитент 102 и поставщик 108 услуг могут хранить несколько паролей. Чтобы различить пароли, эмитент 102 и поставщик 108 услуг могут хранить идентификатор, ассоциированный с каждым паролем, как изображено в таблице 116 и таблице 118. Следует понимать, что обмен паролем происходит независимо от держателя 110 карты, пытающегося подписаться на услугу, предоставляемую поставщиком 108 услуг. Также следует понимать, что обмен паролем может произойти через любые подходящие средства. Например, либо эмитент 102, либо поставщик услуг 108 может обеспечить веб-страницу или другой электронный интерфейс, где пароль может быть введен. В качестве альтернативы пароль может быть передан между эмитентом 102 и поставщиком 108 услуг с использованием телефона, электронной почты или обычного бумажного письма. Следует понимать, что и эмитент 102, и поставщик 108 услуг имеют доступ к паролю и механизму идентификации конкретной версии пароля.

Кроме того, как часть начальной установки системы 100 эмитент 102 и поставщик услуг 108 будут должны договориться, какие части данных держателя 106 карты будут использоваться для формирования кода активации. Конкретные части данных держателя карты, используемые для формирования кода активации, определяют данные, которые поставщик 108 услуг может подтвердить как являющийся такими же, как данные, которые хранятся в данных 104 о клиентах эмитента. Причина этого станет более понятна со ссылкой на фиг.2.

Фиг.2 изображает активацию услуги на высоком уровне. Когда система 100 установлена так, что был выполнен обмен паролем, держатель 110 карты может быть приглашен эмитентом 102 подписаться на услугу, предоставляемую поставщиком 108 услуг. Эмитент 102 может выбрать держателя 110 карты для приглашения подписаться на услугу. Как часть приглашения эмитент 102 может сформировать код активации, который основан на данных 106 держателя карты. Как будет объяснено более подробно в отношении фиг.3, код активации тесно привязан к данным 106 держателя карты. Затем эмитент может отправить 122 код активации держателю 110 карты. Код активации можно отправить держателю 110 карты через любой подходящий канал связи. Например, код активации можно отправить держателю 110 карты в бумажном письме, приглашающем его подписаться на услугу. В качестве альтернативы код активации можно отправить в электронной почте держателю 110 карты. Достаточно сказать, что код активации принимается держателем 110 карты.

Хотя приведенное выше описание дано с точки зрения эмитента 102, выбирающего 110 держателя карты для приглашения подписаться на услугу, это сделано только в целях объяснения. В некоторых вариантах осуществления сам держатель 110 карты может сделать запрос на подписку на услугу посредством запроса кода активации от эмитента 102. Например, эмитент может обеспечить веб-сайт, куда держатель 110 карты может пойти для запроса кода активации. В качестве альтернативы держатель 110 карты может сделать телефонный звонок представителю по обслуживанию клиентов эмитента 102 для приема кода активации. Отправка 122 кода активации от эмитента 102 держателю 110 карты подразумевает указание, что эмитент 102 фактически формирует код активации и, таким образом, имеет заключительное определение, от какого держателя 110 карты можно принять код активации. Как станет понятно по мере продолжения примера, это выгодным образом дает возможность эмитенту 102 определять, какие держатели карты могут подписаться на услугу, поскольку эмитент 102 может просто отказаться дать держателю 110 карты код активации.

Когда держатель 110 карты принял код активации от эмитента 102, он может продолжить подписку на услугу, предоставляемую поставщиком 108 услуг. Поставщик 108 услуг может обеспечить веб-сайт, куда держатель 110 карты может пойти для подписки, хотя варианты осуществления раскрытия не ограничены подпиской по сети. Подписка также может быть выполнена через другие интерфейсы, такие как бумажные формы для подписки или телефонный звонок представителю по обслуживанию клиентов поставщика 108 услуг. Как часть процесса подписки держатель 110 карты может предоставить 124 поставщику 108 услуг информацию о держателе 110 карты. Как минимум, эта информация будет включать в себя код активации, который отправлен держателю 110 карты от эмитента 102. Дополнительно информация будет включать в себя любую информацию держателя карты, которая использовалась эмитентом 102 для формирования кода активации. Как объяснено выше, это информация, которая была согласована эмитентом 102 и поставщиком 108 услуг. Наконец, информация может включать в себя любую другую информацию, которую поставщик 108 услуг запрашивает для подписки держателя 110 карты на услугу.

Например, поставщик 108 услуг может обеспечить веб-сайт подписки для держателя 110 карты, чтобы подписаться на услугу. Веб-сайт может пригласить держателя 110 карты ввести свой код активации. Веб-сайт также может пригласить держателя 110 карты ввести данные, которые были согласованы эмитентом 102 и поставщиком 108 услуг. Веб-сайт также может пригласить держателя карты ввести информацию, которая необходима только поставщику 108 услуг в других целях, таких как дополнительная проверка держателя карты. Например, держателя карты можно пригласить ввести значение для проверки держателя карты (CVV) из трех цифр, которое напечатано на обратной стороне его кредитной карты. Это может позволить поставщику услуг проверить, что держатель карты фактически обладает кредитной картой.

Поставщик 108 услуг затем может использовать информацию, предоставленную держателем 110 карты, чтобы регенерировать код активации. Регенерированный код активации также может упоминаться как код активации подтверждения. Если регенерированный код активации соответствует коду активации, предоставленному держателем 110 карты, поставщик 108 услуг может быть уверен, что держатель 110 карты был авторизован эмитентом 102 для подписки на услугу. Это справедливо потому, что у держателя 110 карты не было бы допустимого кода активации, если бы он не был принят от эмитента 102. Кроме того, поставщик 108 услуг может быть уверен, что, по меньшей мере, для сведений, согласованных первоначально и использованных для формирования кода активации, информация предоставленной держателем 110 карты является точно такой же, которая содержится в данных 104 о клиентах эмитента. Причины этого будут объяснены более подробно в отношении фиг.3. Поставщик 108 услуг затем может подписать держателя 110 карты на услугу. Как часть подписки информация держателя карты может быть сохранена в базе 126 данных подписчиков, ассоциированной с поставщиком 108 услуг.

Фиг.3 изображает активацию услуги на более низком уровне. Процесс может начаться с извлечения эмитентом 102 информации, согласованной эмитентом 102 и поставщиком 108 услуг, из данных 104 о клиентах эмитента. Например, согласованные данные могут содержать имя владельца счета, его адрес и его номер счета. Это не должно подразумевать, что эти сведения представляют собой всю информацию, хранимую эмитентом 102 в данных 104 о клиентах, а они представляют собой информацию, которая была первоначально согласована. Эмитент 102 может хранить любую другую информацию, которая ему требуется, в данных 104 о клиентах.

Эмитент 102 затем может поместить согласованную информацию в блок 130 данных. Эмитент затем может вставить в блок 130 данных пароль, который является действительным в настоящий момент. В настоящем примере согласованная информация включает в себя имя клиента, адрес и номер счета. Пароль 'qwerty' может являться паролем, который является действительным в настоящий момент. Тогда блок 130 данных может быть обработан алгоритмом 132 хеширования. Иллюстративный алгоритм 132 хеширования представляет собой безопасный алгоритм хеширования -1 (SHA1), однако также может использоваться любой другой алгоритм хеширования.

Как известно специалисту в области безопасности данных, алгоритм хеширования, такой как SHA1, берет, в качестве своих входных данных, блок данных, который может содержать последовательность алфавитно-цифровых символов. Исходя из этих входных данных алгоритм произведет профиль сообщения (свертку сообщения) фиксированной длины. Обычно профиль будет представлен числом, которое составляет 128 битов или больше. Числовое значение, сформированное алгоритмом SHA1, может быть представлено последовательностью алфавитно-цифровых символов 134. Хорошо разработанный алгоритм хеширования, такой как SHA1, гарантирует, что если блок данных любым образом изменен, хотя бы даже изменен единственный символ, полученный в результате профиль сообщения будет содержать другое значение. Возможность того, что два разных блока данных сформируют один и тот же профиль сообщения, выходит за рамки статистической вероятности.

Эмитент 102 может добавить идентификатор 136 версии пароля к профилю 134 сообщения, что может дать в результате код 138 активации. Как объяснено выше, может существовать несколько версий пароля, и корректная версия пароля должна быть идентифицирована позже в процессе, как станет более понятно по мере продолжения примера. В альтернативном варианте осуществления перед добавлением идентификатора версии пароля профиль сообщения может быть усечен. Например, если профиль сообщения представлен 16 алфавитно-цифровыми символами, он может быть усечен до только 6, 8 или 10 алфавитно-цифровых символов. Это усечение может быть сделано для удобства держателя 110 карты, которому придется вводить код активации. Чем длиннее код, тем больше вероятность, что держатель 110 карты может неправильно ввести код активации. Хотя усечение профиля сообщения может уменьшить безопасность, вероятность двух блоков данных, хешированных до одного и того же усеченного профиля сообщения, может быть достаточно низкой, чтобы поставщик 108 услуг и эмитент 102 готовы были пойти на риск ради удобства держателя 110 карты.

Код 138 активации можно затем отправить 140 держателю 110 карты через любой из механизмов, которые были обсуждены выше. Держатель 110 карты может затем продолжить 142 подписку на услугу, предоставляемую поставщиком 108 услуг. Как часть этой подписки держатель 110 карты может предоставить 146 поставщику 108 услуг код активации и по меньшей мере всю информацию 144 о держателе 110 карты, которая была использована в процессе формирования кода активации. Как должно быть понятно, помимо кода активации данные, предоставленные держателем 110 карты, являются информацией, которую держатель 110 карты, как ожидается, будет знать (например, его домашний адрес). Кроме того, поставщик 108 услуг также может принять любую другую информацию от держателя 110 карты, которая необходима для подписки, хотя проверены могут быть только данные, которые использовались при формировании кода активации. Держатель 110 карты может подписаться на услугу через любой из механизмов, которые были описаны выше.

Поставщик 108 услуг может принять 146 код активации и данные 144, предоставленные держателем карты. Поставщик услуг может исследовать код активации, чтобы определить идентификатор версии пароля, который использовался для формирования кода активации. С использованием идентификатора версии поставщик услуг может получить соответствующий пароль из хранилища 114 данных паролей. Поставщик услуг может затем создать блок 148 данных, который включает в себя элементы данных, предоставленные держателем карты 144 и являющиеся также элементами данных, которые были согласованы эмитентом 102 и поставщиком 108 услуг. Извлеченный пароль 114 также может быть добавлен к блоку 144 данных. Блок данных затем может быть обработан 150 тем же самым алгоритмом 132 хеширования, таким как SHA1, который использовался для формирования профиля 134 сообщения. Обработка даст в результате новый профиль 152 сообщения. Код активации с удаленным идентификатором версии пароля может тогда быть сравнен с новым сформированным профилем 152 сообщения. В вариантах осуществления, в которых код активации усечен перед отправкой держателю 110 карты, сформированный код активации будет усечен перед сравнением.

Если новый сформированный профиль 152 сообщения соответствует коду активации без идентификатора версии пароля, поставщик 108 услуг может быть удостоверен в нескольких вопросах. Во-первых, поставщик 108 услуг может быть уверен в том, что код активации был действительно сформирован эмитентом 102. Это справедливо потому, что злоумышленнику было бы почти невозможно сформировать код активации, который соответствовал бы профилю 152 сообщения, если злоумышленник не знал пароля. Поскольку пароль должен быть известен только эмитенту 102 и поставщику 108 услуг, очень маловероятно, что это произойдет. Таким образом, поставщик 108 услуг выгодным образом удостоверяется, что держатель 110 карты был одобрен эмитентом 102 для подписки на услугу, поскольку в ином случае эмитент 102 просто отказался бы предоставить держателю 110 карты код активации.

Во-вторых, поставщик 108 услуг также удостоверяется, что информация, по меньшей мере согласованная информация, предоставленная держателем 110 карты, соответствует той, которая хранится в данных 104 о клиентах эмитента 102. Поскольку эмитент 102 формирует код активации на основе данных, хранящихся в данных 104 о клиентах, если держатель карты не предоставит точно ту же самую информацию, то сформированный профиль 152 сообщения не будет соответствовать коду активации. Это выгодным образом позволяет поставщику 108 услуг знать, что его данные соответствуют данным эмитента 102, но не требуют, чтобы поставщик 108 услуг имел доступ к данным 104 о клиентах эмитента 102. Поставщик 108 услуг затем может сохранить предоставленную точную информацию в хранилище 126 данных подписчиков. Данные держателя карты, которые хранятся в хранилище 126 данных подписывающихся, выгодным образом синхронизируются с данными, хранящимися в данных 104 о клиентах эмитента, без требования к поставщику услуг 208 иметь прямой доступ к данным 104 о клиентах эмитента.

Выше был описан вариант осуществления раскрытия, который использует совместно используемый пароль для выполнения хеширования над блоком данных. Альтернативные варианты осуществления могут использовать другие механизмы в зависимости от уровня безопасности, требуемого между эмитентом 102 и поставщиком 108 услуг. Например, совместно используемый пароль может вообще не использоваться при формировании профиля сообщения. Такой вариант осуществления избавляет от необходимости установления обмена информацией о пароле между эмитентом 102 и поставщиком 108 услуг, однако уменьшает безопасность, поскольку любой, кто знает используемый алгоритм хеширования, может сформировать код аутентификации.

В еще одном варианте осуществления вместо того, чтобы использовать совместно используемые данные пароля, может использоваться платформа шифрования с открытыми/закрытыми ключами. Как известно специалисту в области техники, в системе шифрования с парными открытыми/закрытыми ключами данные, которые были зашифрованы с использованием закрытого ключа, могут быть дешифрованы только с использованием соответствующего открытого ключа. Открытый ключ может быть выдан любому, не принимая во внимание его безопасность, тогда как закрытый ключ надежно хранится в тайне. Таким образом, гарантируется, что данные, дешифрованные с использованием открытого ключа, были зашифрованы с использованием закрытого ключа, которым должен обладать только авторизованный пользователь. Блок данных, используемый для формирования профиля сообщения, может исключить совместно используемый пароль. Полученный в результате профиль сообщения может затем быть зашифрован с использованием закрытого ключа эмитента 102, формирующего код активации. Поставщик 108 услуг может затем сформировать свой собственный профиль сообщения с использованием данных, предоставленных держателем 110 карты. Принятый код активации может быть дешифрован с использованием открытого ключа эмитента, и если дешифрованный код активации соответствует коду, сформированному поставщиком 108 услуг, можно подтвердить, что эмитент 102 действительно сформировал код активации с использованием тех же самых данных, которые были предоставлены поставщику 108 услуг.

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

В этапе 404 извлекаются данные, которые ассоциированы с пользователем. Как объяснено выше, эти данные будут обычно извлекаться из собственного хранилища данных эмитента. Эти данные могут включать в себя такую информацию, как адреса и номера социального страхования. Данные будут обычно предоставляться как часть отношения пользователя с эмитентом. Как объяснено выше, эмитент может хранить много информации о пользователе, но на этапе 404 будут извлечены только те сведения, которые согласованы с эмитентом и поставщиком услуг.

В этапе 406 извлекается элемент данных, который совместно используется с поставщиком услуг. Этот элемент данных также может упоминаться как пароль или фраза-пароль. Как описано выше, в некоторых вариантах осуществления сохраняются несколько версий совместно используемого элемента данных, и может быть извлечена версия, которая является действительной в настоящий момент. На этапе 408 формируется код активации на основе данных, ассоциированных с пользователем и извлеченных на этапе 404, и совместно используемого элемента данных, полученного на этапе 406. Код активации формируется с использованием таких функций, как хеш-функция, которая не позволила бы восстановить из кода активации, данные, используемые для формирования кода активации.

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

Фиг.5 изображает блок-схему подписки на услугу с использованием ключа активации на высоком уровне. Процесс может начаться на этапе 502 с приема запроса на подписку от пользователя. Как часть процесса подписки на этапе 504 могут быть приняты данные, ассоциированные с пользователем. Такие данные могут включать в себя такие элементы, как имя пользователя и адрес. На этапе 506 от пользователя может быть принят ключ активации. Как описано выше, владение допустимым ключом активации является показателем того, что пользователь авторизован для подписки на услугу.

На этапе 508 извлекается совместно используемый элемент данных, который использовался для формирования кода активации. В некоторых вариантах осуществления принятый код активации содержит показатель, который позволяет извлечь корректный совместно используемый элемент данных. Когда корректный совместно используемый элемент данных получен, код активации подтверждения может быть сформирован на этапе 510. Код активации подтверждения может быть сформирован с использованием совместно используемого элемента данных и данных, ассоциированных с пользователем, которые были приняты на этапе 504. Как описано выше, конкретные элементы данных, которые будут использоваться для формирования кода активации и кода активации подтверждения, определены заранее. На этапе 512 сравниваются код активации и код активации подтверждения.

Если коды не одинаковы, процесс переходит на этап 514 и подписка пользователя отклоняется. Если коды одинаковы, процесс переходит на этап 516 и пользователю разрешают подписаться на услугу. На этапе 518 могут быть сохранены данные, принятые на этапе 504. По меньшей мере части данных, которые использовались для формирования кода активации подтверждени