Сетевые коммерческие транзакции

Изобретение относится к способам проведения онлайновых коммерческих транзакций. Техническим результатом является увеличение безопасности проведения транзакции за счет обеспечения верификации идентификационной информации покупателя и верификации способности пользователя оплатить покупку. В распределенной системе защищенных коммерческих транзакций устанавливают трехсторонний обмен данными между продавцом, потребителем и поставщиком платежа. Потребитель посылает онлайновый запрос продавцу на покупку товаров и/или услуг и принимает от продавца электронный счет. Потребитель посылает экземпляр электронного счета поставщику платежа для авторизации платежа и принимает от поставщика платежа маркер платежа в качестве доказательства платежеспособности потребителя. Маркер платежа зашифровывается или подписывается (цифровой подписью). Маркер платежа передают от потребителя продавцу. Продавец проверяет его достоверность, посылая поставщику платежа запрос. Продавец посылает подтверждение достоверности маркера платежа потребителю. 4 н. и 35 з.п. ф-лы, 11 ил.

 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Настоящее изобретение относится к связанным в сеть системам транзакций и способам проведения онлайновых транзакций.

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

Рост числа связанных в сеть вычислительных систем открыл новые возможности по отношению к тому, как корпорации и отдельные лица ведут торгово-промышленную деятельность. Например, конечные пользователи, соединенные с сетью (например, Интернет), через сетевое устройство, такое как компьютер, персональный цифровой ассистент (ПЦА, PDA), телефон сотовой связи и т.д., могут проводить коммерческие транзакции по сети, чтобы покупать услуги и/или товары, вести финансовые операции, или иным образом вести торгово-промышленную деятельность или выполнять персональные транзакции по сети. Проблемой, присущей онлайновым транзакциям, является безопасность, особенно когда в состав транзакции включается перевод сумм денег, средств и/или передача финансовой, персональной или другой конфиденциальной информации.

Многие традиционные онлайновые транзакции проводятся в соответствии с одной из двух отличающихся, но взаимосвязанных моделей. Обе модели используют браузер (программа просмотра Web) в качестве интерфейса для обработки передачи информации между сторонами, участвующими в транзакции. В первой модели продавец предлагает товары или услуги в режиме «онлайн» (интерактивно) с помощью браузера. Термин "продавец" относится при этом обобщенно к любому объекту, предлагающему товары и/или услуги для покупки. Термин «продавец» не используется, чтобы описывать какой-либо конкретный коммерческий статус или описывать лицензированного продавца, если не указано конкретно. Предпочтительнее термин описывает обобщенно некоторого продавца или объект, предлагающий товар и/или услуги для покупки или продажи. Термин «поставщик услуг» используется при этом взаимозаменяемо с термином «продавец» и, если не указано иное, имеет тот же смысл.

В традиционной онлайновой транзакции продавец может иметь web-сайт, который описывает, отображает или иным образом предлагает товары и/или услуги для продажи. Конечный пользователь указывает желание купить одну или несколько единиц товаров или услуг обычно путем выбора соответствующего изделию пункта с помощью интерфейса браузера. Браузер затем отображает страницу транзакции, которая позволяет конечному пользователю выбирать один или несколько типов платежа и вводить информацию, требуемую, чтобы совершить транзакцию. Например, связанная с транзакцией страница, отображенная посредством браузера, может разрешать конечному пользователю выбирать тип платежа, такой как по кредитной карте (например, VISA, MasterCard, American Express и т.д.), и вводить связанную с транзакцией информацию, такую как номер кредитной карты, дата истечения срока действия карты и т.д. Связанная с транзакцией страница также может запросить конечного пользователя о персональной информации, такой как имя, адрес выставления счета, адрес отгрузки и т.д. Конечный пользователь затем представляет на рассмотрение информацию, и продавец обрабатывает представленную информацию.

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

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

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

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

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

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

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

Фиг. 2 - иллюстрация схемы системы и способа, предназначенных для инициирования и выполнения верификации идентификационной информации (набора персональных атрибутов объекта в сети) в онлайновой транзакции, в соответствии с одним вариантом осуществления изобретения;

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

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

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

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

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

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

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

Фиг. 8 - иллюстрация трехстороннего защищенного обмена платежной информацией и федерации (или интеграции при наличии слабосвязанных объектов) платежей в соответствии с примерными вариантами осуществления;

Фиг. 9 - иллюстрация различных применений подсистемы коммерческих транзакций и представления счета в соответствии с примерными вариантами осуществления;

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

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

КРАТКОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

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

Заявитель также установил, что трудности, связанные с проверкой достоверности идентификационной информации покупателя, могут быть уменьшены путем использования технологий, более защищенных и удобных, чем модель регистрационного имени/пароля. В одном варианте осуществления идентификационная информация о покупателе обеспечивается посредством карты модуля (SIM) идентификации абонента, хранящей идентификационную информацию о конечном пользователе, которая может выдаваться программно, создавая менее запутывающую и более прямую практику осуществления покупки. Кроме того, варианты осуществления в документе предусматривают протоколы, способы, вычислительные системы и другие механизмы, выполненные с возможностью одиночной или многоуровневой аутентификации с использованием SIM-устройства иным образом недоверительной или незащищенной сети (например, Интернет).

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

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

Термин "программируемо" и/или "автоматически" относится к действиям, выполняемым по существу без привлечения ручного действия или действия оператора. В частности, «программируемое» или «автоматическое» относится к действиям, инициированным и/или выполняемым посредством одной или нескольких компьютерных программ. Например, обеспечение идентификационной информации посредством запроса пользователя (например, покупателя) предоставить информацию регистрационного имени и/или пароля не будет считаться программируемым, поскольку существо действия выполняется пользователем. Однако действие, в котором идентификационную информацию (например, номер SIM, сетевой адрес, идентификатор (ID) аппаратного обеспечения и т.д.) программа выдает без запроса, чтобы пользователь вводил информацию, будет считаться программируемым. Следует отметить, что такие автоматические операции могут быть осуществлены посредством либо программных, либо аппаратных компонентов.

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

В одном варианте осуществления различные элементы онлайновой транзакции распределены по отдельным и независимым объектам в сети. Например, поставщик идентификационной информации может обеспечивать проверку достоверности идентификационной информации в форме идентификационного маркера (знака), который продавец может использовать, чтобы верифицировать идентификационную информацию покупателя. Идентификационный маркер может включать в состав один или несколько идентификационных мандатов (подтверждение права доступа) конечного пользователя. Идентификационный маркер может быть выдан на основании предоставленной конечным пользователем/покупателем идентификационной информации, например абонентского номера из SIM-карты, сетевого адреса (например, идентификация сетевой интерфейсной платы (СИП, NIC), глобальное имя (WWN) и т.д.), информации регистрационного имени и т.д. Подобным образом, поставщик платежа может обеспечивать верификацию платежеспособности конечного пользователя в форме маркера платежа. Кроме того, поставщик платежа может вести транзакции платежа от имени покупателя в уплату покупки товаров и/или услуг от продавца. Вышеописанная структура позволяет, между прочим, покупателю и продавцу, которые являются третьими сторонами, проводить онлайновую коммерческую транзакцию в недоверительной сетевой среде в относительной секретности, как обсуждается с дополнительной подробностью в различных примерных вариантах осуществления, предоставленных ниже.

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

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

Как предварительно упомянуто, другие варианты осуществления раскрытой структуры перемещают части транзакции на более защищенные подсистемы вычислительного устройства (например, операционную систему). Это эффективно допускает многочисленные возможности, включая в них: модель абстракции, чтобы давать возможность существующим приложениям обеспечивать внутреннюю практику работы с сетевой коммерческой транзакцией; дополнительные виды защиты от мошенничества; запись и представление платежного документа для ведения контроля, федерации платежей и других целей платежа или аутентификации; исполнение (программного) кода поставщика услуг для дополнительной защиты и специфических для продавца функциональных средств; многоуровневую аутентификацию и другие признаки. Например, такая модель абстракции позволяет существующим и другим приложениям обеспечивать пользователя возможностями онлайновой покупки и платежа, как если бы такая транзакция происходила непосредственно в рамках приложения, хотя части коммерческой транзакции являются выполняемыми внешне. Примеры включают покупку по каталогам (например, Amazon, Sears и т.д.), прямую покупку мультимедийного содержимого из мультимедийного приложения, загрузку по сети программного обеспечения/игр в пробном режиме и автоматическую разблокировку их с помощью внутренней модели платежа, предоставление возможности платежа за предоставляемые на основе абонирования услуги, такие как простая служба обмена сообщениями через электронную почту и т.д.

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

В другом варианте осуществления Заявитель также предусматривает общую систему и протокол, который использует модуль мобильной связи для защищенной связи и аутентификации возможностей идентификации и платежа для разнообразия различных услуг. Например, модуль (SIM) идентификации абонента (или другой подобный модуль мобильной связи) может использоваться для аутентификации пользователя и/или устройства по отношению к службе или серверу в среде многоуровневой проверки достоверности. В таком варианте осуществления модуль мобильной связи (и возможно даже пользователь) являются аутентифицируемыми по сети, независимой от инфраструктуры сети мобильной связи для модуля мобильной связи. Таким образом, система проверяет достоверность владения модулем мобильной связи посредством аутентификации активного платежного счета с инфраструктурой мобильной связи. Это устанавливает защищенную связь с вычислительным устройством, соединенным с модулем мобильной связи и службой (например, web-службой (WS)) с использованием имеющихся протоколов защищенной связи (например, WS-Authentication (WS-аутентификация), WS-Security (WS-безопасность) и других подобных протоколов). Такая защищенная связь также может использоваться для аутентификации пользователя посредством других протоколов и обменов данными между модулем мобильной связи и инфраструктурой мобильной связи, как описано более подробно ниже. Дополнительно другие варианты осуществления предусматривают протокол и конечный автомат, которые абстрагируют вычислительное устройство (используемое в связи по независимой сети) от инфраструктуры мобильной связи. Соответственно, сам модуль мобильной связи становится терминалом мобильной связи, и вычислительное устройство становится периферийным устройством, действуя, таким образом, по правилам текущих стандартов беспроводной связи, таких как 3GPP (проект партнерства систем связи 3-го поколения).

На Фиг. 1 иллюстрируется блок-схема системы 100 коммерческих транзакций, содержащей множество сетевых узлов, включая компьютер 110 конечного пользователя (покупателя), компьютер 140 продавца, компьютер 120 поставщика идентификационной информации и компьютер 130 поставщика платежа. Каждый из вышеуказанных узлов может включать в состав одно или несколько вычислительных устройств, взаимосвязанных посредством сети 105. Понятно, что компьютер конечного пользователя, продавца 140, поставщика 120 идентификационной информации и поставщика 130 осуществления платежа могут быть связаны с объектом в сети, таким как отдельное лицо, компания или предприятие. Например, компьютер 110 конечного пользователя обычно связан с отдельным лицом, использующим компьютер, чтобы осуществлять доступ к ресурсам в сети, и компьютер 140 продавца может быть связан с корпорацией или предприятием, предлагающим товары и/или услуги для продажи. Одно или несколько вычислительных устройств, которые образуют каждый упомянутый компонент в системе 100 коммерческих транзакций, могут действовать в качестве точки входа, вычислительной платформы и/или средства передачи, посредством которого связанные объекты в сети взаимодействуют по сети.

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

Также следует отметить, что сеть 105 может быть сетью любого типа в конфигурации любого типа, которая связывает узлы и позволяет взаимодействовать соединенным с сетью узлам. Узлы или устройства могут быть соединены с сетью посредством медного (например, кабельной системы категории 5) кабеля, оптических соединений, радиосвязи или любой их комбинации. Информация может передаваться с использованием любого протокола низкого уровня, такого как Ethernet и/или любого информационного протокола, такого как TCP/IP. Сеть 105 может иметь любое количество соединенных с ней устройств и может быть доверительной (например, учрежденческой сетью) или недоверительной сетью (например, локальная вычислительная сеть/глобальная вычислительная сеть (ЛВС/ГВС, LAN/WAN), Интернет, и т.д.), или комбинацией обеих. Компьютеры, соединенные с сетью, могут быть устройствами любого типа, включая в них, но, не ограничиваясь таковыми, одно устройство или любую комбинацию устройств из телефона мобильной связи, настольного компьютера, планшетного персонального компьютера, сервера, рабочей станции и т.д.

На Фиг. 2 в соответствии с одним вариантом осуществления изобретения иллюстрируется схема системы и способа для инициирования и выполнения верификации идентификационной информации в онлайновой транзакции, и на Фиг. 3 в соответствии с одним вариантом осуществления изобретения иллюстрируется схема системы и способа для выполнения согласования условий платежа, верификации и/или сертификации в онлайновой транзакции. Способы могут использоваться отдельно или в комбинации, чтобы выполнять онлайновую транзакцию между конечным пользователем/покупателем и продавцом. В нижеследующем описании, если не указано конкретно, не делается различия между объектом в сети и связанными с ним сетевыми устройствами. Например, "поставщик идентификационной информации" используется обобщенно, чтобы описывать поставщика идентификационной информации в виде объекта (например, банка, правительственного учреждения, ведомства, и т.д.) и в виде вычислительного устройства, который объект использует для выполнения различных сетевых функций, таких как обеспечение верификации идентификационной информации для конечного пользователя, или иным образом действуя от имени объекта. Компьютер 110 конечного пользователя может размещать заказ 242 продавцу 140. Заказ 242 может быть любым указанием, что конечный пользователь хотел бы купить одну или несколько единиц товаров и/или услуг от продавца 140. Например, заказ 242 может быть результатом выбора конечным пользователем товара или услуги с помощью web-браузера, отображающего страницы, постоянно находящиеся на web-сайте продавца, или может быть результатом выбора возможного варианта из исполняющегося локально приложения, как описано с дополнительными подробностями ниже. В качестве примера первого случая продавец 140 может обеспечивать web-сайт, чтобы отображать или иным образом предлагать для продажи товары и/или услуги, которые он предоставляет, или может предоставлять онлайновый каталог товаров. Заказ 242 может быть любого типа с указанием, что конечный пользователь хотел бы купить одну или несколько единиц товаров и/или услуг от продавца 140.

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

В ответ на заказ 242 продавец 140 может запросить, чтобы конечный пользователь 110 предоставил указание идентификационной информации конечного пользователя и/или верификацию, что конечный пользователь является действительно тем, кого он должен означать (этап 205). Например, продавец 140 может не знать что-либо об источнике заказа 242 и ему может быть желательна идентификационная информация конечного пользователя и/или гарантии, что конечный пользователь не имитирует обманным путем свою идентификационную информацию. В качестве альтернативы, продавец 140 может посылать уведомление или указание, что требуется платеж за услугу, и потребовать, чтобы был обеспечен маркер платежа. Чтобы получить маркер платежа, сначала может быть необходимым установить идентификационную информацию с помощью идентификационного маркера, как описано с дополнительными подробностями ниже. В любом случае конечный пользователь 110 может отвечать на запрос продавца 140 путем привлечения к участию услуг поставщика 120 идентификационной информации (этап 215).

Для получения идентификационного маркера конечный пользователь 140 поставляет идентификационную информацию поставщику 120 идентификационной информации. Идентификационная информация может включать в состав любую информацию, которая позволяет поставщику 120 идентификационной информации устанавливать различие между конечным пользователем, использующим компьютер 110 конечного пользователя, и многими другими конечными пользователями, которым поставщик идентификационной информации может поставлять услуги. Например, идентификационная информация может включать в состав уникальный идентификатор, связанный с аппаратными средствами компьютера 110 конечного пользователя. В одном варианте осуществления идентификационная информация обеспечивается посредством карты SIM, выдающей идентификатор, уникальный для абонента. Идентификационная информация может включать в состав обеспечение уникального номера аппаратного обеспечения для сетевой интерфейсной платы (NIC) компьютера 110 конечного пользователя, глобального имени (WWN) или другого сетевого адреса компьютера 110 конечного пользователя или любого другого средства, посредством которого может быть идентифицирован компьютер 110 конечного пользователя, включая (в некоторых вариантах осуществления) установленную комбинацию регистрационного имени/пароля.

Поставщик 120 идентификационной информации использует идентификационную информацию, чтобы определить местоположение идентификационных мандатов, связанных с конечным пользователем. Например, поставщик 120 идентификационной информации может включать в состав базу данных, которая хранит идентификационную информацию и мандаты относительно ряда конечных пользователей. Идентификационная информация может использоваться для (организации) индекса в базу данных, чтобы получать корректные идентификационные мандаты. Поставщик 120 идентификационной информации может быть объектом любого типа. Например, поставщик 120 идентификационной информации может быть компанией обслуживания телефонов сотовой связи, которая использует номер абонента, обеспечиваемый SIM-картой конечного пользователя, чтобы определить местоположение соответствующей идентификационной информации. В одном варианте осуществления номер абонента используется, чтобы определять местоположение и получать информацию, предоставляемую конечным пользователем во время абонентской подписки на телефон сотовой связи или другое устройство, применяющее технологию SIM. Поставщик 120 идентификационной информации может быть банком, правительственным ведомством (таким как реестр транспортных средств (RMV)), или любым другим средством, которое поддерживает идентификационную информацию или мандаты, связанные с конечными пользователями.

В ответ на идентификационную информацию, предоставленную конечным пользователем, поставщик 120 идентификационной информации поставляет идентификационный маркер на компьютер 110 конечного пользователя, который обеспечивает аутентификацию идентификационной информации и/или идентификационные мандаты относительно конечного пользователя (этап 225). Идентификационный маркер может быть любым типом электронного сообщения, которое другое сетевое устройство может использовать для аутентификации, верификации и/или определения идентификационной информации конечного пользователя. Например, идентификационный маркер может включать в состав идентификационные мандаты конечного пользователя. Идентификационные мандаты могут включать в состав, но не ограничиваются таковыми, любой один или комбинацию атрибутов из имени, даты рождения, адреса, номера телефона, адреса электронной почты и т.д.

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

Поставщик 120 идентификационной информации может передавать идентификационный маркер на компьютер 110 конечного пользователя для пересылки продавцу 140 (этап 235), и/или поставщик 120 идентификационной информации может передавать идентификационный маркер непосредственно продавцу 140. Продавец 140 затем может обрабатывать идентификационный маркер, чтобы идентифицировать конечного пользователя и/или верифицировать, что конечный пользователь является тем, кого он должен означать. Идентификационный маркер может использоваться для аутентификации некоторой информации о конечном пользователе, которая может влиять на транзакцию. Например, продавец 140 может поставлять услугу, которая требует, чтобы конечный пользователь имел некоторый определенный возраст. Идентификационные мандаты, переданные с помощью идентификационного маркера, могут использоваться, чтобы гарантировать, что конечный пользователь имеет надлежащий возраст и удовлетворяет этому требованию. Продавец 140 может иметь скидки для конкретных конечных пользователей, которые являются частыми покупателями, или приняли купон, стимулирующее предложение, и т.д. Продавец 140 может индексировать базу данных конечных пользователей, чтобы определять, отвечает ли требованиям конечный пользователь или должен быть иным образом особо обработан на основании предоставленных идентификационных мандатов.

Факультативно продавец 140 может запрашивать проверку достоверности идентификационного маркера посредством посылки запроса поставщику 120 идентификационной информации (этап 245). Запрос проверки достоверности идентификационного маркера может включать в состав пересылку идентификационного маркера от продавца 140 поставщику 120 идентификационной информации. Приняв запрос на проверку достоверности идентификационного маркера, поставщик 120 идентификационной информации может проверить достоверность идентификационного маркера и таким образом определить, является ли идентификационный маркер подлинным. Поставщик 120 идентификационной информации затем может переслать указание достоверности идентификационного маркера продавцу 140 (этап 255). В качестве альтернативы, продавец 140 может просто непосредственно подтвердить достоверность идентификационного маркера (этап 265) (например, полагая, что идентификационный маркер является действительным, или иным образом обрабатывая маркер). Ответ может быть возвращен от продавца 140 на компьютер 110 конечного пользователя, причем ответ может включать в состав сообщение о том, является ли идентификационный маркер действительным, о какой-либо применимой скидке или стимулирующих предложениях, и/или любой другой тип сообщения, поскольку изобретение не является ограниченным в этом отношении (этап 265).

После того как продавец 140 обработал идентификационный маркер и/или принял подтверждение достоверности идентификационного маркера от поставщика 120 идентификационной информации, продавец 140 может запросить, чтобы конечный пользователь обеспечил верификацию или проверку достоверности платежеспособности и/или обеспечил указание, каким образом конечный пользователь хотел бы оплатить товары или услуги. Продавец 140 может выполнить запрос посредством запроса маркера платежа (этап 305 на Фиг. 3). В ответ на запрос маркера платежа компьютер 110 конечного пользователя может привлечь услуги поставщика 130 платежа. Поставщик 130 платежа может быть связан с третьей стороной, которая поддерживает финансовую и платежную информацию о различных конечных пользователях, такой как финансовое учреждение, или сторонний посредник, который ведет финансовые операции и процедуры осуществления платежей.

Компьютер 110 конечного пользователя может затребовать маркер платежа от поставщика 130 платежа (этап 315) путем передачи идентификационного маркера поставщику 130 платежа. В качестве альтернативы конечный пользователь может запрашивать маркер платежа путем регистрации на поставщике 130 платежа способом, подобным обсужденному в связи с поставщиком 120 идентификационной информации (то есть обеспечивая идентификатор, такой как номер абонента SIM, адрес NIC, и/или используя комбинацию регистрационного имени/пароля). Понятно, что конечный пользователь может запрашивать маркер платежа другими способами, поскольку изобретение не является ограниченным в этом отношении. Кроме того, конечный пользователь может посылать информацию о покупке, такую как цена и характеристика покупки, с тем, чтобы поставщик платежа мог проверить, что конечный пользователь платежеспособен. Однако обеспечение информации о покупке не требуется, поскольку она может не быть необходимой, или она может быть обработана на последующих этапах транзакции.

Поставщик 130 платежа обрабатывает идентификационный маркер (или другой предоставленный идентификатор), чтобы определить местоположение информации о конечном пользователе. Например, поставщик 130 платежа может осуществлять доступ к базе данных платежной информации на основании идентификационных мандатов, переданных с маркером идентификационной информации. Поставщик 130 платежа может определить, какие возможности оплаты и возможные варианты идентифицированный конечный пользователь имеет в наличии. Поставщик 130 платежа затем может проверить, что конечный пользователь платежеспособен, и в ответ формирует и передает маркер платежа на компьютер 110 конечного пользователя (этап 325). Маркер платежа может указывать платежеспособность конечного пользователя и/или подтверждение, что поставщик 130 платежа желает обрабатывать транзакцию от имени конечного пользователя. Компьютер 110 конечного пользователя затем может переслать маркер платежа продавцу 140 (этап 335).

Продавец 140 обрабатывает маркер платежа с тем, чтобы продавец 140 был удовлетворен, что конечный пользователь способен оплатить товары или услуги (этап 365). Например, продавец 140 может запросить поставщика 130 платежа проверить достоверность маркера платежа (этапы 345, 355) или может просто проверить (подтвердить) его достоверность сам (этап 365) (например, полагая, что маркер платежа действителен или иным образом обрабатывая маркер). Продавец 140 может затем начинать процесс поставки товаров и/или услуг конечному пользователю. Поскольку поставщиком 130 платежа может быть незаинтересованная третья сторона, продавец 140 может рассматривать маркер платежа по существу в качестве платежа и не обязан ждать, пока транзакция не будет полностью обработана.

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

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

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

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

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

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

На Фиг. 8 иллюстрируется пример использования некоторых признаков, описанных выше для трехсторонней защищенной связи и различных доверительных границ, которые могут быть установлены в течение коммерческой транзакции. Как будет описано более подробно ниже, эта модель учитывает единовременные или абонентские платежи, а также федерацию платежей, так что служба или продавец могут соединять в одно целое платежи, предназначенные для более мелких компаний; таким образом, предоставляя возможность клиенту оплачивать единовременный платежный документ. Как показано, распределенная система 800 выполнена с возможностью содействовать коммерческой транзакции между потребителем 810, продавцом 830 и поставщиком 805 платежа. Доверительная граница 815 платежа отделяет продавца 830 от потребителя 810/поставщика 805 платежа, так что доверительные отношения существуют между поставщиком 805 платежа и потребителем 810 или вычислительным устройством покупателя (то есть потребитель надлежащим образом идентифицировал или аутентифицировал себя для поставщика платежа, используя любой из имеющихся в наличии механизмов, как описано в документе). Соответственно, потребитель 810 может использовать это доверительное отношение, чтобы авторизовать платеж продавцу 830 для различных типов платежей и различных типов услуг.

Например, допустим, что продавец 830 требует резервной оплаты продукта (например, специализированное изделие, которое требует предварительного платежа, подобно автомобилю, компьютеру и т.д.), который потребитель 810 желает купить. Однако перед запросом авторизации платежа пользователь вычислительного устройства потребителя 810 может потребовать надлежащей аутентификации, как описано в документе. Как только пользователь осуществляет аутентификацию, вычислительное устройство потребителя 810 может соответственно запрашивать платеж от поставщика 805 платежа посредством любых различных механизмов, как также описано в документе. Например, потребитель 810 может снабжать поставщика платежа платежно-расчетной или другой информацией запроса, которая подписана или иным образом зашифрована посредством вычислительной системы потребителя 810. Это аутентифицирует запрос проверки достоверности надлежащей платежеспособности владельца (то есть потребителя) счета (то есть пользователь имеет заранее оплаченный счет, кредитовый счет, или другой платежный счет, такой как абонирование мобильной связи, как описано ниже). Если проверка успешна, выдается маркер платежа и затем резервируются средства, чтобы гарантировать платеж. Такой маркер платежа обычно затем подписывается и/или иным образом шифруется поставщиком платежа (например, web-сервером мобильной связи, как описано в документе) и передается на клиентскую часть потребителя 810. Потребитель 810 передает обратно маркер платежа продавцу 830, который проверяет достоверность маркера по отношению к поставщику платежей, и если успешно, совершает заказ.

Как только изделие готово к доставке (например, специализированное изделие было создано), продавец 830 может использовать маркер резервного платежа, чтобы запросить платеж от поставщика 805 платежей. Следует отметить, что сумма запроса об оплате может быть отличной от резервированной суммы. Тем не менее, поставщик 805 платежа проверяет достоверность и возвращает ответ на запрос платежа продавцу 830 и/или потребителю 810. Если одобрено, продавец 830 может отправить (или обеспечить поставку иным образом) заказ потребителю 810 и получить за него оплату. С другой стороны, если платеж отклонен, или требуется дополнительное взаимодействие с пользователем, продавец 830, поставщик 805 платежа, и/или потребитель 810 могут выбирать, какую процедуру действия предпринять. Например, если запрошенная продавцом 830 сумма не соответствует резервированным средствам, поставщик 805 платежа и/или продавец 830 могут запрашивать авторизацию от потребителя 810 для новой суммы. В качестве альтернативы, поставщик 805 платежа может требовать пользовательского ввода данных, авторизующего перевод средств независимо от какого-либо изменения в резервированных и запрошенных суммах платежа. Конечно, другие действия и процедуры для совершения коммерческой транзакции также рассматриваются при этом.

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

Например, пусть подразумевается, что потребитель 810 желает установить с продавцом 830 абонирование длительной услуги (например, абонентская подписка на газету или журнал, абонентская подписка на кинофильм, игровое приложение, или другие товары и/или услуги, предоставляемые по схеме pay-as-you-go («с оплатой счетов в срок»)). Соответственно, продавец 830 запросит потребителя 810 о маркере платежа, и таким образом клиент потребителя 810 может взаимодействовать с пользователем, запрашивая авторизацию, чтобы продолжать действие, как описано в документе. Подобно вышеописанному, потребитель 810 снабжает цифровой подписью или иным образом шифрует запрос платежа (например, используя информацию электронного представления счета, как описано в документе ниже) и посылает такой запрос поставщику 805 платежа (например, оператору мобильной связи, компании, продающей товары по кредитным картам, сторонней службе с предварительной оплатой или другого типа и т.д.). Он аутентифицирует запрос и проверяет достоверность, что владелец счета (то есть потребитель или покупатель) имеет достаточные начальные средства. Если успешно, выдается маркер платежа, снабжается подписью и/или иным образом шифруется, и возвращается на клиент потребителя 810, который передает обратно маркер платежа продавцу 830 абонентской подписки. Продавец 830 затем верифицирует аутентификацию маркера и завершает установку абонентской подписки.

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

Как указано выше, другие варианты осуществления предусматривают федерацию единовременного платежа потребителя 810 для ряда деловых партнеров или филиалов с наличием договорного соглашения. Зачастую деловые отношения являются сложными и требуют распределения платежей за различные услуги и/или товары, предоставленные в рамках конкретной деловой модели. Например, при покупке поездки от туристического агента 830 потребитель 810 может быть снабжен пакетным соглашением, включающим в состав схемы рейсов, размещения в гостинице, транспортные услуги и т.д. Продавец 830, который обычно заключает контракт со многими из (поставщиков) таких услуг и/или товаров, должен затем вести подробный бухгалтерский учет такой коммерческой транзакции, чтобы выполнять надлежащие платежи его деловым партнерам. Чтобы уменьшить сложность такого учета и других задач, варианты осуществления в документе предусматривают автоматическую федерацию платежей для деловых партнеров в рамках конкретного типа отношений на основе «за каждую транзакцию».

Например, служба проката автомобилей (например, деловой партнер "А" 820) может потребовать платеж от продавца 830 в качестве части праздничной пакетной продажи. Страховая компания (например, деловой партнер "B" 825) может взимать с продавца 830 комиссионные, начисляемые за каждую операцию по текущему счету. На основании доверительной границы 835 деловых партнеров платежи являются автоматически интегрированными для каждого делового партнера (например, "А" 820 и "B" 825), когда выполняется единовременный платеж продавцу 830. Другими словами, потребитель 810 или поставщик 805 платежа выполняет единовременный платеж продавцу 830; однако могут быть надлежащим образом оплачены все филиалы с деловыми отношениями в соответствии с доверительной границей для деловой модели 835. Следует отметить, что такой платеж будет обычно связываться с отчетом о состоянии электронного счета, как описано более подробно ниже. Более конкретно, различная часть электронного счета для ввода и записи, предъявления и других целей может соответствовать тому, какую часть платежа следует интегрировать для каждого делового партнера. Дополнительно, каждая из этих частей может быть подписана и/или зашифрована так, что конкретная информация об оплате является непрозрачной для потребителя 810, поставщика 805 платежа или между различными деловыми партнерами 820, 825, как определено посредством различных доверительных границ 815, 825.

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

На Фиг. 4 иллюстрируется сетевая вычислительная система для обработки коммерческих транзакций в соответствии с одним вариантом осуществления настоящего изобретения. Сетевая вычислительная система 400 может быть подобна вычислительной системе 100, проиллюстрированной на Фиг. 1. Однако, на Фиг. 4, каждый из компьютеров в системе 400 включает в состав локальные установки программного обеспечения 485 коммерческих транзакций. В частности, компьютер 410 конечного пользователя или потребителя, поставщика 420 идентификационной информации, поставщика 430 платежа и продавца 440 включает в состав программное обеспечение 485a-485d коммерческих транзакций, соответственно. Программное обеспечение коммерческих транзакций, локально установленное в каждом из компьютеров в системе, может быть одинаковым, или может быть настроено для конкретного компьютера, принимая во внимание какую роль(и) играет компьютер в транзакции (то есть действует ли компьютер в качестве узла конечного пользователя, узла продавца, узла поставщика идентификационной информации, узла поставщика платежа и т.д., или некоторой комбинация вышеуказанных). В любом случае каждая установка выполнена с возможностью осуществлять связь с установками на других сетевых компьютерах, чтобы выполнять онлайновые транзакции. Например, каждая установка может быть выполнена с возможностью осуществлять связь с установками на сетевых компьютерах, чтобы выполнять способы, проиллюстрированные на Фиг. 2 и/или Фиг. 3.

В одном варианте осуществления локальная установка программного обеспечения 485a коммерческих транзакций на компьютере поставщика 420 идентификационной информации может создавать идентификационный маркер, идентифицирующий конечного пользователя, использующего компьютер 410 конечного пользователя. Кроме того, программное обеспечение 485a коммерческих транзакций на компьютере поставщика 420 идентификационной информации может пересылать идентификационный маркер на компьютер 410 конечного пользователя, поставщика 430 платежа, продавца 440, и/или любой другой компьютер, поскольку изобретение не ограничено в этом отношении. Локальная установка программного обеспечения 485b коммерческих транзакций на компьютере 410 конечного пользователя может выдавать идентификационную информацию (с тем, чтобы идентифицировать конечного пользователя) в ответ на указание провести онлайновую транзакцию между конечным пользователем и продавцом. Локальная установка программного обеспечения 485c коммерческих транзакций, установленная на компьютере поставщика 430 платежа, может принимать идентификационный маркер и формировать маркер платежа, верифицируя платежеспособность конечного пользователя (например, маркер платежа) для онлайновой транзакции. Локальная установка программного обеспечения 485d коммерческих транзакций, установленная на компьютере продавца 440, может принимать результат верификации платежеспособности конечного пользователя перед продолжением онлайновой транзакции.

В одном варианте осуществления каждый из компьютеров в системе 400 действует с использованием локальной установки одинаковой или сходной операционной системы 495. Например, каждый из компьютеров в системе 400 может действовать с использованием операционной системы Microsoft Windows® корпорации Майкрософт. Программным обеспечением 485 коммерческих транзакций может быть подсистема операционной системы. Таким образом, различные компьютеры, используемые в коммерческой транзакции, осуществляют связь согласованным и известным образом. Поскольку программное обеспечение коммерческих транзакций поддерживает связь непосредственно по сети и обрабатывает проверку достоверности, верификацию и защиту, конечному пользователю и продавцу требуется знать что-либо друг о друге, и более важно, им не требуется устанавливать какое-либо доверительное отношение. Кроме того, поскольку некоторые части транзакций обрабатываются посредством операционной системы, почти вся транзакция может быть выполнена по существу невидимой для пользователя, не требуя путанного и неудобного участия конечного пользователя.

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

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

На Фиг. 5 иллюстрируется коммерческая транзакция, инициированная конечным пользователем, выбирающим один или несколько желательных товаров и/или услуг, причем относящиеся к транзакции компоненты покупки обрабатываются, по меньшей мере, частично, подсистемой программного обеспечения транзакций, распределенной в качестве части операционной системы различных компьютеров, участвующих в одной или нескольких транзакциях. Конечный пользователь, соединенный с сетью 505 через компьютер 510 конечного пользователя, может исполнять приложение 555. Приложение 555 может быть браузером, отображающим web-сайт предприятия, которое предлагает для продажи товары или услуги. Приложение 555 может быть приложением, предоставляющим факультативную возможность для принятия участия в онлайновой транзакции, таким как программа редактирования изображения, которая позволяет пользователям управлять изображениями.

Конечный пользователь с помощью приложения 555 может выбирать один или несколько товаров или услуг для покупки. Например, конечный пользователь может пожелать иметь отредактированное изображение, профессионально напечатанное на бумаге фотографического качества. Приложение 555 может включать в состав такой возможный вариант под набором команд для печати. В результате выбора, команда печати может формировать прямоугольную область или диалоговое окно, отображающее перечень всех доступных возможных вариантов печати, включая в них доступные по сети услуги. Например, команда печати может отображать перечень поставщиков 540a, 540b и 540c услуг в качестве возможных вариантов для обеспечения услуги печати. Когда пользователь выбирает одного из поставщиков услуг, может быть инициирована онлайновая коммерческая транзакция, как описано выше. В частности, поставщик услуг может запрашивать, чтобы конечный пользователь предоставил идентификационный маркер. В ответ приложение 555 (или приложение, встроенное в программное обеспечение 585 коммерческих транзакций) может сформировать диалоговое окно или интерфейс, отображающий перечень доступных поставщиков идентификационной информации. Например, как описано более подробно ниже, диалоговое окно может отображать перечень поставщиков 520a, 520b и 520c идентификационной информации, соответственно, в качестве возможных поставщиков идентификационной информации, которых пользователь может выбирать, чтобы вести верификацию идентификации.

На Фиг. 9 иллюстрируется использование доверенной коммерческой подсистемы и других возможностей в распределенной системе и в соответствии с примерными вариантами осуществления. Как показано, локальное вычислительное устройство 920 в распределенной системе 900 выполнено с возможностью обеспечивать онлайновую или локальную транзакцию розничной торговли в соответствии с вариантами осуществления, описанными в документе. Следует отметить, что хотя доверенная подсистема 965 коммерческих транзакций показывается только в виде части локального вычислительного устройства 920, подобные подсистемы также могут постоянно находиться на других объектах в сети. Дополнительно следует отметить, что хотя различные компоненты или модули могут быть описаны в виде постоянно находящихся на любом конкретном объекте в сети, такие компоненты или модули могут быть распределены по всей вычислительной системе и могут постоянно находиться на любом количестве объектов в сети (то есть части могут присутствовать на одном или нескольких объектах в сети). Соответственно, конкретная «эстетическая» схема размещения и использование конкретного модуля посредством сетевого устройства или объекта используются в документе только для иллюстративных целей и при этом не предназначены ограничивать или иным образом сужать объем вариантов осуществления.

Независимо от распределения и «эстетической» схемы размещения вычислительной системы 900, как описано предварительно, имеется доверительная граница 906, разделяющая доверительные отношения между различными компонентами. Хотя отношения могут быть разделены различным образом, в настоящем примере доверительные отношения имеются между поставщиком 990 платежа и доверенной подсистемой 965 коммерческих транзакций. Это преимущественно допускает многие возможности, которые существующие коммерческие системы не могут обеспечивать. Например, доверительная граница 906 абстрагирует приложения 925 от коммерческой транзакции с продавцом. Соответственно, существующие и другие приложения 925 могут обеспечивать для конечного пользователя 940 внутреннюю практику работы, хотя почти вся функциональность выглядит внешней. Например, в вышеуказанном примере для предоставления возможности профессиональной печати изображения на бумаге фотографического качества выбор в «выпадающем» наборе команд, проверка достоверности идентификационной информации, возможные варианты платежа и другие компоненты для помощи пользователю в покупке такой услуги выглядят как часть приложения 925. Соответственно, приложение 925 при приеме входных данных для осуществления покупки услуг и/или товаров может создавать вызов 930 покупки в доверенную подсистему 965 коммерческих транзакций, которая затем используется, чтобы формировать диалоговые окна, принимать вводимые данные 935 пользователя 940 и иным образом автоматически взаимодействовать с продавцом 905 и/или поставщиком 990 платежа, как описано в документе.

Другими словами пользователь 940 не должен обязательно доверять приложению 925 или продавцу 905 в коммерческой транзакции. Вместо этого доверие ограничивается подсистемой 965 настоящей структуры, что уменьшает степень или уровни доверия, необходимые для доверительного и безопасного выполнения коммерческой транзакции. То есть к подробностям 950 учетной записи пользователя 940, включающим в состав конфиденциальную информацию 955, которую пользователь 950 не желает или считает неудобным публично совместно использовать (например, информация кредитной карты, персональная информация, пользовательские имена/пароли и т.д.), осуществляют доступ либо посредством прямого пользовательского ввода 935 данных в подсистему 965, либо из защищенного 960 хранилища 945 информации учетных записей. Как таковые приложения 925, продавец 905 и другие компоненты абстрагируются от финансовых и других платежно-счетных подробностей 955 учетной записи, управляемых посредством подсистемы 965, как описано в документе. Это является весьма отличающимся от современных моделей коммерческих транзакций, описанных выше, где приложения 925 или продавцы 905 поддерживают и управляют информацией учетной записи. Соответственно, этот и другие варианты осуществления, описанные в документе, полезно обеспечивают дополнительные уровни защиты в течение таких коммерческих транзакций. Это представляет значительно более управляемые доверительные отношения для того, чтобы минимизировать количество компонентов или организаций, которые имеют доступ к весьма уязвимым финансовым данным или затрагивают их.

Показанная также на Фиг. 9 и сходная с описанной выше трехсторонней защищенной коммерческой транзакцией доверительная граница 906 также указывает защищенную связь между поставщиком платежа и доверенной подсистемой 965 коммерческих транзакций. Соответственно, подсистема 965 осуществляет аутентификацию по отношению к поставщику 990 платежа любым из многочисленных способов, описанных в документе, допуская защищенную связь с ним. Подобно вышеуказанному, локальное вычислительное устройство (которое может быть, как описано ниже, переносным портативным устройством в локальной розничной транзакции, персональным компьютером в онлайновой транзакции или другим подобным устройством, как описано в документе) требует различные услуги и/или товары, предлагаемые продавцом(ами) 905. В этом примере информация 910 представления счета поставляется на локальное вычислительное устройство 920 для аутентификации, ведения контроля и других целей, как используется в примерных вариантах осуществления, описанных в документе. Такая информация представления счета может включать в состав, но не ограничиваться таковыми, стоимость товаров и/или услуг, подробное описание коммерческой транзакции, конкретную для продавца 905 информацию, информацию федерации платежей, тип транзакции (например, единовременный платеж, абонирование, и т.д.) или другие типы информации представления счета. Информация 910 представления счета также может включать другую информацию, такую как ограничения продавца и возможные варианты платежа, как описано более подробно ниже. В одном варианте осуществления информация 910 представления счета является электронным платежным документом (векселем), выполненным машиночитаемым, что обеспечивает много выгодных возможностей данной системы коммерческих транзакций. Например, один вариант осуществления обеспечивает, что информация 910 представления счета может быть частью запроса 980 маркера платежа (или иным образом поставленной в другой передаче информации на компьютер поставщика 990 платежа), как предварительно описано. Как таковая информация представления счета может использоваться поставщиком 990 платежа для проверки 940 достоверности маркера платежа. Более конкретно, информация 910 представления счета, предоставленная от потребителя или локального вычислительного устройства 920, может сравниваться с предоставленной от продавца 905 информацией маркера 985 платежа в проверке 904 достоверности маркера платежа. Соответственно, если информация 910 представления счета для проверки 904 достоверности маркера платежа совпадает с информацией 910 представления счета из запроса 980 маркера платежа, поставщик 990 платежа может быть дополнительно заверен в подлинности маркера платежа 985 и действительности продавца.

Следует отметить, что способ, каким информация 910 представления счета от продавца передается поставщику 990 платежа (а также другим компонентам в нем), может меняться. Например, информация 910 представления счета, посланная от продавца 905 поставщику 990 платежа, может быть экземпляром информации 910 представления счета, посланной на доверенную подсистему 965 коммерческих транзакций или клиент 920. В качестве альтернативы, или вместе, информация 910 представления счета может быть снабженной подписью и/или зашифрованной версией от поставщика 990 платежа, маршрутизированной через потребителя или локальное вычислительное устройство 920. В любом случае, поставщик платежа может выполнять сравнение, описанное выше для аутентификации маркера 985 платежа.

Дополнительно следует отметить, что такая информация 910 представления счета, как используется поставщиком 990 платежа, также может использоваться, чтобы давать более подробное описание связанных со счетом начислений, которое будет впоследствии представлено пользователю 940 для взиманий по счету пользователя. Поскольку это также может быть машиночитаемым представлением счета 910, локальное вычислительное устройство 920 может сопоставлять информацию 910 представления счета с предварительно принятой продавцом 905 для дополнительной авторизации платежа относительно продавца 905. Другими словами, если информация 910 представления счета в счете от поставщика 990 платежа не совпадает с какой-либо принятой от продавца 905, то начисления для оклада могут рассматриваться мошенническими.

В другом варианте осуществления продавец 905 может использовать информацию 910 представления счета для целей ведения контроля, аутентификации пользователя и других, федерации платежей и т.д. Например, продавец может подписывать или иным образом шифровать части информации 910 представления счета. Это допускает многие выгодные признаки в вариантах осуществления, описанных в документе. Например, информация 910 представления счета может быть частью маркера 985 платежа, принятого поставщиком платежа посредством локального вычислительного устройства 920. Продавец 905 может проверять достоверность информации 910 представления счета для аутентификации, что маркер 985 платежа поступил от клиента 920 или доверенной подсистемы 965 коммерческих транзакций. Подобным образом в течение проверки достоверности 904 маркера платежа продавец 905 может использовать информацию 910 представления счета, принятую от поставщика 990 платежа, чтобы проверить достоверность или аутентифицировать поставщика 990 платежа и/или локальное вычислительное устройство 920. Другими словами, поскольку информация 910 представления счета маршрутизуется поставщику платежа через подсистему 965 или потребителя 920, информация представления счета, принятая от поставщика платежа, которая соответствует посланной на клиент 920, может подтверждать достоверность клиента 920 и маркера платежа 985 со стороны поставщика 990 платежа.

Следует отметить, что в другом варианте осуществления, как кратко описано выше, информация 910 представления счета также может использоваться продавцом для федерации платежей. В этом варианте осуществления различные части информации 910 представления счета могут быть машиночитаемыми для определения, какие части средств от поставщика 990 платежа (при успешной аутентификации платежа) должны быть распределены деловым партнерам, как предварительно описано. Следует отметить, что в этом варианте осуществления части информации 910 представления счета обычно будут зашифрованными или иным образом непрозрачными для пользователя 940 (или клиента 920 потребителя), поставщика 990 платежа, или других компонентов, не являющихся частью деловых отношений с продавцом 905. Это также уникально идентифицирует делового партнера в федерации представления счетов и посредством этого может использоваться для целей аутентификации. Более точно, различные части информации 910 представления счета, конкретные для делового партнера, могут зашифровываться с использованием ключа, конкретно определенного для такого делового партнера, таким образом, информация представления счета может быть видимой только для продава 905 и конкретного делового партнера. В других вариантах осуществления, однако, части счета для распределения или федерации платежей подписываются только продавцом 905, чтобы быть непрозрачными для других компонентов в системе 900.

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

Следует отметить, что доверительная граница 906 и подсистема 965 также имеет другие выгодные признаки в других вариантах осуществления, описанных в документе. Например, как показано на Фиг. 9, (программный) код 970 поставщика платежа в рамках подсистемы 965 допускает защищенный исполняющийся код, конкретно определенный для одного или нескольких поставщиков 990 платежа. Такой код может использоваться для дополнительной авторизации, конкретно определенной для поставщика платежа, например биометрической, радиочастотной идентификации (РЧИ, RFID), пользовательского имени/пароля, или любых многочисленных дополнительных способов аутентификации. Другими словами, вследствие доверительных отношений, которые поставщик 990 платежа имеет с подсистемой 965, поставщик платежа может исполнять доверенный код для своей конкретной цели деловой деятельности.

Использование такого кода 970 также допускает более интегрированную внутреннюю практику работы пользователя, которая может управляться поставщиком 990 платежа или любым другим компонентом, имеющим доверительные отношения с подсистемой 970. Например, хотя не показано, доверительные отношения могут существовать между некоторыми продавцами 905 и подсистемой 965, чтобы позволять исполнение их доверительного кода посредством подсистемы 965. Как таковые продавец 905, поставщик 990 платежа или любой другой компонент, участвующий в коммерческой транзакции, могут обеспечивать интегрированную внутреннюю практику работы пользователя, которая выглядит исполняемой изнутри приложения 925 (существующего или иного); однако многие события происходят внешним образом. Например, в примере печати изображения с фотографическим качеством посредством профессиональной службы, указанном выше, диалоговые окна, возможные варианты платежа, или любое другое множество представляемых пользователю возможностей, или функциональность приложения (например, в ответ на пользовательский ввод данных) могут управляться посредством кода 970, специально предоставленного различными доверенными объектами в сети (например, поставщиком 990 платежа, продавцом 905 и т.д.). Соответственно, как будет описано более подробно ниже, этот код также может использоваться при оценке возможных вариантов платежа и других ограничений от продавца 905 и/или поставщика 990 платежа.

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

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

Следует отметить, что другие варианты осуществления также предусматривают сравнение ограничений продавцов (например, доступных возможных вариантов платежа, возрастных ограничений, и т.д.) с правилами потребителя для определения различных действий, которые могут предприниматься. На Фиг. 10 иллюстрируется такой вариант осуществления, в котором распределенная система 1000 выполнена с возможностью программно определять действия на основании таких обстоятельств, как ограничения 1010 продавца, и/или правила 1035 потребителя. Например, продавец 1020 в рамках ограничений 1010 продавца может задавать поставщиков 1005 платежа или типы платежа, приемлемые для осуществления покупки их услуг и/или товаров. Модуль принятия решений может затем представлять такие ограничения пользователю, например, в пользовательском интерфейсе, запрашивающем пользовательский ввод 1040 данных для выбора одного или нескольких доступных возможных вариантов платежа. На основании пользовательского ввода 1040 данных можно связаться с соответствующим поставщиком 1005 платежа для надлежащего финансирования услуг и/или товаров. В другом варианте осуществления правила 1035 потребителя также могут использоваться в дополнение к ограничениям 1010 продавца или вместо них. Например, правила 1035 потребителя могут указывать, что только некоторые типы платежей могут выполняться для некоторых типов продавцов 1020. Более конкретно, правила 1035 потребителя могут указывать, что если продавец 1020 является незарегистрированным или иным образом недоверительным, то для покупок у продавца 1020 могут использоваться только платежи, которые могут быть обратимыми.

Конечно, как описано выше, другие правила 1010 продавца и ограничения 1035 потребителя могут использоваться модулем 1030 принятия решений при определении действий, которые предпринимаются в коммерческой транзакции. Фактически ограничения 1010 продавца и правила 1035 потребителя могут сопоставляться на совместимость и для других целей. Например, доступные от продавца 1020 возможные варианты платежа могут сравниваться с поставщиками 1005 платежа, доступными или допускаемыми потребителем, при представлении пользователю выборки поставщиков 1005 платежа. Конечно, выборка платежа также может происходить автоматически на основании таких обстоятельств, как настройка по умолчанию, рейтинги или предпочтения поставщика, или любого другого числа установочных параметров для возможных вариантов. Фактически может происходить любое число действий на основании осуществления различных правил продавца 1010 и/или потребителя 1035. Например, если правила (продавца 1010 или потребителя 1035) безуспешно или иным образом нарушены, могут быть необходимы дополнительные входные данные от продавца 1020 или пользователя 1040 (либо автоматически на основании дополнительных правил, либо настроечные параметры), чтобы разрешить противоречия или другие несоответствия. Соответственно, любое конкретное действие, предпринятое при осуществлении заданных ограничений и/или правил, используется в документе только для иллюстративных целей и не предназначено ограничивать или иным образом сужать варианты осуществления, представленные в документе.

Дополнительно следует отметить, что, как описано выше, ограничения 1010 продавца могут включаться в состав информации представления счета или поставляться потребителю отдельно. Также следует отметить, что сравнение различных правил и действий, предпринятых в связи с этим, могут все происходить под «оболочками», то есть без знания пользовательских и/или других системных компонентов. Кроме того, следует отметить, что настоящая система не ограничивается только ограничениями или правилами, заданными либо потребителем, либо продавцом. Например, поставщик платежа также может задавать различные ограничения, которые также могут рассматриваться вместе с правилами потребителя и/или продавца или вместо них. Соответственно, вышеуказанное использование ограничений продавца и потребителя для определения различных действий (таких как возможные варианты поставщика платежа) используется в документе лишь для иллюстративных целей и не предназначено ограничивать или иным образом сужать варианты осуществления, описанные в документе, если явно не указано иное.

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

Заявитель оценил, что обеспечение возможностей регистрации в журнале или ведения контроля в программном обеспечении коммерческих транзакций может устранять некоторые неопределенности относительно электронных загрузок по сети. Например, окончательное исполнение возможного варианта платежа может зависеть от сигнала или от средства ведения контроля, что загрузка завершена. В этом случае, если загрузка по сети прервана, конечный пользователь может убедиться, что выбранный возможный вариант платежа не прошел. Например, программное обеспечение 585 коммерческих транзакций по Фиг. 5 (или другие подсистемы или компоненты объекта в сети, как описано в документе) может включать в состав средство регистрации, которое регистрирует в журнале все различные этапы коммерческих транзакций, проводимых посредством вычислительной машины. Информация регистрации может использоваться в качестве доказательства покупки или иным образом сохранять информацию о транзакции. Кроме того, программное обеспечение 585 коммерческих транзакций может включать в состав средство мониторинга электронных загрузок по сети, которое посылает подтверждение верификации успешной загрузки по сети только после того, как будет выполнен окончательный платеж. Делая платеж зависящим от сигнала, что передача товаров или услуг была совершена успешно, проблемы двойного выставления счета могут быть разрешены и по существу устранены.

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

Заявитель оценил преимущества предоставления конечному пользователю возможности использовать программное обеспечение в среде «pay-as-you-go». В частности, с конечного пользователя может взиматься только за суммарное время, затраченное на использование приложения, предпочтительнее платежа розничной цены за программное обеспечение (в котором многие возможности и/или приложения были бы в значительной степени неиспользованными). На Фиг. 6 иллюстрируется сетевая вычислительная система с наличием структуры коммерческих транзакций, которая позволяет конечному пользователю оплачивать время, затраченное на использование приложения. Сетевая вычислительная система 600 содержит сеть 605, связывающую узел 610 конечного пользователя с множеством поставщиков 620 идентификационной информации, множеством поставщиков 630 платежа и множеством поставщиков 640 услуг.

Узлом 610 конечного пользователя может быть компьютер, исполняющий операционную систему 695. На компьютере конечного пользователя могут быть установлены несколько программных приложений 655. Программные приложения могут поставляться в комплекте с компьютером при покупке, свободно загружаться по сети или распространяться иным образом (зачастую бесплатно или за номинальную плату, или для регистрации с поставщиком) продавцом приложения. Приложение 655 может быть приложением любого типа, и любое количество приложений может быть установлено на компьютере. Поставщики 640 услуг могут быть связаны с одним или несколькими приложениями, установленными на компьютере 610 конечного пользователя. Например, поставщиком 640a услуг может быть один или несколько компьютеров, принадлежащих разработчику и продавцу приложения 655a. Подобным образом поставщики 640b и 640c услуг могут быть связаны с приложениями 655b и 655c, соответственно.

В модели «pay-as-you-go» услуга, предоставляемая поставщиками услуг, является лицензией на использование соответствующих приложений, установленных на компьютере. Например, когда программное обеспечение (например, приложения 655) является свободно распространяемым, оно может быть первоначально блокировано (защищено) с тем, чтобы пользователи не могли исполнять приложение без получения сначала лицензии от продавца приложения. Лицензия может быть получена путем инициирования коммерческой транзакции с одним или несколькими поставщиками 640 услуг. Например, приложением 655a может быть приложение настольной издательской системы, которое конечный пользователь хотел бы использовать в течение пары часов, чтобы создать карту или брошюру. Когда конечный пользователь открывает приложение 655a, конечный пользователь уведомляется, что он должен купить лицензию, чтобы использовать приложение. Например, может появляться диалоговое окно, отображающее перечень характеристик и цены для различных возможностей лицензирования «для использования».

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

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

Принятая лицензия может быть обработана посредством общей службы 690 лицензий, так чтобы могла быть активизирована соответствующая доступность к приложению. Служба общих лицензий может затем выдать для приложения 655 разрешающий ключ с тем, чтобы пользователь мог исполнять программное обеспечение и использовать его функциональные возможности в соответствии с лицензией. Разрешающий ключ может включать в состав любую информацию, необходимую для приложения, чтобы предоставить необходимые услуги в течение срока, обозначенного в лицензии. Разрешающий ключ может включать в состав пароль, предоставленный поставщиком услуг, так что приложение уведомляется, что лицензия является действительной и/или может просто доверять представлению от общей службы 690 лицензий, что была получена действительная лицензия. Как только приложение начинает действовать, может быть уведомлен измерительный процессор 694, чтобы отслеживать время и указывать приложению, когда лицензия истекла. В качестве альтернативы приложение может быть запрограммировано, чтобы периодически запрашивать измерительный процессор и затем отключаться, когда лицензия истекла. Кроме того, посредством запроса измерительного процессора приложение может передавать пользователю периодические предупреждения или обновления о времени, остающемся в купленной лицензии, если лицензия включает в состав срок действия.

Когда конечный пользователь закончил операцию, он может выбрать получение профессионально напечатанного готового продукта и выбирает команду печати, которая инициирует другую онлайновую транзакцию, такую как транзакция, описанная в связи с Фиг. 5. Лицензия «pay-as-you-go» может обеспечивать пользователей значительно большей приспособляемостью и с помощью лицензии срока действия давать им доступ к программному обеспечению, к которому они ранее не имели доступа вследствие стоимости покупки пакета программ. Кроме того, поставщики программ могут извлекать выгоду из дохода от пользователей, которые не желали оплачивать полную розничную цену, но желают оплачивать ограниченное использование и/или ограниченную функциональность.

Пиратство программного обеспечения влияет на прибыль по всей индустрии программного обеспечения. Нелицензированное программное обеспечение пользователя стоит коммерческим предприятиям относительно существенные суммы каждый год. Как только программный продукт был куплен, продавец имеет небольшой контроль над тем, где и на скольких компьютерах установлено программное обеспечение. Незаконное предоставление программного обеспечения для загрузки по Интернет обеспечивает еще более масштабный способ распространения и получения программного обеспечения, за которое конечный пользователь не заплатил. Заявитель установил, что обеспечение относительно защищенной и простой структуры коммерческих транзакций с оплатой лицензии по схеме «pay-as-you-go», например структуры, описанной в варианте осуществления, проиллюстрированном на Фиг. 6, может уменьшать или устранять проблемы пиратства. Поскольку программное обеспечение распространяется свободно продавцом, конечные пользователи могут (незаконно) приспосабливать программное обеспечение таким путем, какой они считают подходящим. Поскольку программное обеспечение предоставляется только посредством оплаты лицензии на срок или лицензии на задачу, конечные пользователи существенно ограничиваются в их способности некорректно использовать программное обеспечение.

Как предварительно описано, варианты осуществления в документе допускают аутентификацию для целей идентификации и/или платежа с использованием модуля мобильной связи (например, модуля (SIM) идентификации абонента), связанного с конкретным платежным счетом инфраструктуры мобильной связи или операционной системы. В отличие от обычных стандартов для мобильной связи (например, глобальные системы мобильной связи (ГСМС, GSM), проект партнерства систем связи 3-го поколения и другие подобные протоколы), которая совершается через доверенную радиосеть, аутентификация в соответствии описанными с вариантами осуществления имеет место по независимой недоверительной сети передачи данных (например, Интернет). В результате описанные варианты осуществления решают многие из дополнительных сложностей защиты, налагаемых использованием таких модулей (SIM) мобильной связи в Web-службе и других средах независимых сетевых протоколов. Такие сложности защиты включают среди прочего: определение конечной точки доверенной сети для аутентификации сервера; аутентификацию клиента для модуля мобильной связи или устройства SIM; аутентификацию пользователя для устройства SIM; аутентификацию SIM и сервера аутентификации; установление защищенного сетевого соединения между модулем мобильной связи и сетевым сервером аутентификации и аутентификация пользователя для сетевого сервера аутентификации.

Кроме того, чтобы соблюдать GSM, 3GPP и другие стандарты, дополнительные требования возлагаются на оконечное оборудование, которое взаимодействует с модулем мобильной связи или SIM-устройством. Более конкретно, GSM, 3GPP и другие подобные стандарты требуют, чтобы SIM ограничивал доступ к некоторым типам информации, включая в нее ключи шифрования, для терминала мобильной связи. Для того чтобы удовлетворять этим требованиям, описанные варианты осуществления обеспечивают абстракцию профиля защиты, который передает обработку и декодирование некоторых сообщений и защиты на устройство SIM непосредственно. Например, как показано на Фиг. 11, межсетевая защита 1090 задает конечный автомат и сообщения протокола для абстрагирования SIM 1085 от ведущего устройства (хоста) 1075 при осуществлении связи по независимой сети 1060. Более конкретно, межсетевая защита 1090 использует формальный конечный автомат, который устанавливает предел или ограничивает число и/или последовательность команд, посылаемых от драйвера считывания внутри ведущего устройства 1075 на SIM 1085 непосредственно. Соответственно, SIM-устройство 1080 (например, телефон сотовой связи, SIM-интерфейс и т.д. - следует отметить, что "модуль мобильной связи" представляет общий термин для "SIM", но используется в документе взаимозаменяемо, если конкретно не заявлено иное) становится терминалом мобильной связи, и ведущее устройство 1075 становится внешним устройством, которое соблюдает протокол 1055 связи для сети 1050 мобильной связи. Нижеследующее описывает более подробно некоторые конечные автоматы и протоколы, используемые для решения некоторых из дополнительных требований защиты и факторов, описанных выше.

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

Уровень защиты устройства указывает физическое владение модулем мобильной связи, например SIM-устройством, таким как телефон сотовой связи. Маркер устройства (то есть маркер защиты SIM с наличием уровня защиты устройства) обычно выдается локально посредством модуля мобильной связи или SIM-устройства при надлежащей аутентификации пользователя для него. Такие требования аутентификации пользователя для модуля мобильной связи обычно устанавливаются инфраструктурой мобильной связи или оператором мобильной связи. Дополнительно аутентификация устройства обычно приводится в исполнение устройством SIM, однако другие варианты осуществления могут предусматривать использование других компонентов в процессе аутентификации. Например, SIM или другое устройство могут потребовать пароль прежде, чем модуль мобильной связи или другое устройство выдадут маркер устройства. Конечно, в документе также рассматриваются другие формы мандатов для аутентификации на уровне устройства.

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

Уровень защиты сети указывает аутентифицированное соединение между модулем мобильной связи или SIM и инфраструктурой мобильной связи или сетью по недоверительной независимой сети. Уровень защиты сети может быть установлен без присутствия пользователя или взаимодействия с пользователем, если разблокированное SIM-устройство является доступным для клиента или ведущего компьютера. Обычно уровень защиты сети является однофакторной аутентификацией, которая утверждает доказательство принадлежности SIM-устройства инфраструктуре мобильной связи или оператору. Обычно инфраструктура мобильной связи будет выдавать маркер защиты сети посредством сервера аутентификации и посредством механизма типа «ответа на вызов» прежде выдачи маркера защиты сети на вычислительное устройство клиента или ведущее устройство. Этот маркер уровня защиты сети может затем использоваться на последующих стадиях аутентификации и обеспечивает соответствующую транспортному уровню защиту, чтобы шифровать и/или подписывать дальнейшие взаимодействия между клиентом и сервером аутентификации и/или инфраструктурой мобильной связи.

На Фиг. 7A иллюстрируется независимая сеть 700, настроенная с возможностью выдавать маркер уровня защиты сети, чтобы устанавливать защищенную связь транспортного уровня между клиентом и сервером аутентификации. Обычно клиентское или ведущее вычислительное устройство 710 (которым может быть персональный компьютер, телефон мобильной связи или другое портативное или не поддерживающее мобильную связь вычислительное устройство) инициирует запрос аутентификации путем посылки запроса 725 маркера защиты сети на инфраструктуру 720 мобильной связи через сервер 715 аутентификации/доверенный сервер (следует отметить, однако, что запрос также может быть инициирован другим устройством, таким как непосредственно SIM 705). Обычно запрос 725 будет неподписанным, когда принимается сервером 715 аутентификации, который затем может снабдить подписью и/или зашифровать запрос перед посылкой в инфраструктуру 720 мобильной связи для проверки достоверности, что запрос поступил от сервера 715 аутентификации. Доверенный сервер 715 затем может запросить инфраструктуру 720 мобильной связи или оператора мобильной связи для вызова 730, который затем будет послан на модуль 705 мобильной связи. Модуль 705 мобильной связи использует секрет (секретный ключ) 740 с инфраструктурой 720 мобильной связи, чтобы сформировать ответ 735 на вызов, который затем пересылается на клиент 710. Обычно секрет будет конкретным для SIM 705 и установленным оператором 720 мобильной связи.

Клиент 710 будет использовать ответ 735 на вызов, чтобы формировать ответ на запрос маркера защиты, который также для целей аутентификации может включать в состав идентификационную информацию SIM и вызов 730. Обычно клиент будет запрашивать, чтобы модуль 705 мобильной связи подписал и/или зашифровал ответ на запрос маркера защиты с помощью соответствующего устройства 705 совместно используемого секрета 740 или другого ключа, такого как маркер устройства SIM - хотя это может быть или не быть необходимым. Ответ на запрос маркера защиты и ответ 735 на вызов при этом могут быть проверены на достоверность с использованием, например, совместно используемого секрета 740. Следует отметить, как предварительно упомянуто, что ответ на запрос маркера защиты может быть или не быть снабжен подписью и/или зашифрован посредством одного и того же ключа, используемого для формирования ответа 735 на вызов. В любом случае, если инфраструктура 720 мобильной связи подтверждает достоверность ответа 735 на вызов (то есть ответ на вызов является действительным, и модуль мобильной связи имеет активный платежный счет), инфраструктура 720 мобильной связи и/или сервер 715 аутентификации может отвечать путем формирования сообщения, которое содержит маркер 745 защиты сети с зашифрованным сеансовым ключом(ами), которые снабжены подписью и/или зашифрованы с использованием совместно используемого секрета 740. Сообщение может быть дополнительно подписано с использованием либо собственного маркера защиты сервера 715 аутентификации (например, сертификация по стандарту X.509, сертификация по технологии Kerberos и т.д.), либо с использованием маркера защиты инфраструктуры 720 мобильной связи. Клиент 710 может затем проверять снабженное подписью сообщение и передавать зашифрованный сетевой сеансовый ключ(и) на SIM 705 для расшифровывания. Используя совместно используемый секрет 740, модуль 705 мобильной связи затем может возвращать незашифрованный сеансовый ключ(и) 750 на клиент 710.

Следует отметить, что в вышеуказанной выдаче маркера 745 защиты сети на модуль 705 мобильной связи обычно требуется активный платежный счет в хорошем (финансовом) состоянии на инфраструктуре 720 мобильной связи. Соответственно, после верификации ответа 735 на вызов и информации такого активного платежного счета может быть установлено доверие между SIM 705 и инфраструктурой 720 мобильной связи, создавая виртуальный защищенный канал. Сеансовый ключ(и) 750 затем делегируют или передают от модуля 705 мобильной связи на базовые программные средства или стек ведущего вычислительного устройства 710 и от оператора 720 мобильной связи на сервер 715 аутентификации (в случае необходимости). Следует отметить физически тесное соседство модуля 705 мобильной связи с ведущим вычислительным устройством 710 (которое может быть соединено с ним через порт универсальной последовательной шины (УПШ, USB), Bluetooth или другое беспроводное или проводное соединение) и доверительное отношение между инфраструктурой 720 мобильной связи и сервером 715 аутентификации. Этот сеансовый ключ(и) 750 затем используется клиентом 710 и доверенным сервером 715, чтобы устанавливать защищенную связь 755.

Следует отметить, что может быть второй режим работы для аутентификации модуля 705 мобильной связи, который может использоваться инфраструктурой 720 мобильной связи. В этом случае ведущее устройство 710 клиента может запрашивать, чтобы SIM 705 сформировал и подписал свой собственный вызов (обычно в форме параметра Nonce). Клиент 710 затем может присоединить информацию в качестве части маркера устройства, когда запрашивает маркер 725 защиты сети от доверенного сервера 715 или инфраструктуры 720 мобильной связи. Если оператор 720 мобильной связи может верифицировать, что маркер устройства содержит действительный ответ 735 на вызов, он может непосредственно выдавать сетевой маркер 745 обратно на клиент 710 для расшифровывания сеансового ключа(ей), как описано выше.

Как будет описано более подробно ниже, обычно этот маркер 745 защиты сетевого уровня требуется, чтобы предоставлять клиенту доступ к аутентифицированному маркеру службы, который может использоваться, чтобы запрашивать услуги и/или товары от сторонней службы. Следует отметить также, что для того, чтобы получить маркер сети, выше предполагается, что клиентское или ведущее устройство 710 успешно определило оконечную точку сети для сервера 715 аутентификации и/или инфраструктуры 720 мобильной связи. Дополнительно, предполагается, что клиент 710 и пользователь (не показано) уже аутентифицированы для SIM- устройства 705. Как описано выше, маркер 745 защиты сетевого уровня используется на последующих стадиях аутентификации и обеспечивает соответствующую транспортному уровню защиту, чтобы зашифровать и снабжать подписью дальнейшие взаимодействия между клиентом 710 и доверенным сервером 715. Срок действия сетевого маркера 745 (и других маркеров) контролируется сервером 715 аутентификации или оператором 720 мобильной связи. Поскольку сетевой маркер 745 используется в качестве контекста сеанса между SIM-устройством 705 и инфраструктурой 720 мобильной связи, срок действия может быть ограничен часами или днями, количеством переданных байтов и/или может быть действительным, только если модуль 705 мобильной связи должным образом соединен с клиентом 710.

Как предварительно упомянуто, пользовательский уровень защиты указывает, что пользователь аутентифицирован для сети (доверенного сервера 715, инфраструктуры 720 мобильной связи или другой службы) обычно согласно обеспечению информации, хранимой вне SIM 705 или ведущего вычислительного устройства 710. Соответственно, пользовательский уровень защиты вместе с сетевым уровнем защиты устанавливает многофакторную аутентификацию на основании доказательства принадлежности SIM 705 и некоторых внешних сведений (например, пользовательского имени/пароля). Обычно доверенный сервер 715 или инфраструктура 720 мобильной связи являются единственными компонентами, чтобы выдавать защиту пользовательского уровня, однако, в некоторых случаях, сторонняя служба также может выдавать такие пользовательские маркеры. Соответственно, инфраструктура 720 мобильной связи (или другая служба в зависимости от обстоятельств) будет проверять пользователя посредством механизма ответа на вызов перед выдачей маркера защиты пользовательского уровня обратно на клиент 710. Следует отметить, что пользовательский маркер защиты используется клиентом, чтобы подписывать и/или шифровать запросы маркеров служб, как описано ниже. Для клиента может не рекомендоваться посылать пользовательский маркер защиты на какую-либо службу, отличную от доверенного сервера (поскольку обычно никакая другая служба не сможет его верифицировать/использовать). Как в случае с вышеуказанным сетевым маркером 745, пользовательский маркер может иметь ограниченный срок действия, контролируемый оператором 720 мобильной связи, и может быть ограничен продолжительностью времени, количеством переданных байтов и/или посредством наличия соединения между модулем 705 мобильной связи и клиентом 710.

На Фиг. 7B иллюстрируется независимая сеть 700, настроенная для выдачи маркера защиты пользовательского уровня, чтобы устанавливать многоуровневую защищенную связь между клиентом 710 и сервером 715 аутентификации. Стадия аутентификации пользователя в сети позволяет оператору 720 мобильной связи (или другому серверу) верифицировать, что известное лицо владеет известным устройством 705. Эффективным образом стадия аутентификации пользователя для сети является стадией двухфакторной аутентификации и предотвращает сеть от распределенных атак отказа служб. Кроме того, это защищает пользователя посредством предотвращения от использования ненадлежащим образом похищенного SIM-устройства 705.

Ведущее вычислительное устройство 710 может выдавать запрос пользовательского маркера 765, который посылается на инфраструктуру 720 мобильной связи через доверенный сервер 715. Обычно, запрос 765 будет неподписанным, когда принимается сервером 715 аутентификации/доверенным сервером, который затем подписывает и/или шифрует запрос прежде посылки на инфраструктуру мобильной связи 720 для проверки достоверности, что запрос поступил от сервера 715 аутентификации. Доверенный сервер 715 может затем запросить инфраструктуру 720 мобильной связи или оператора мобильной связи для вызова 770, который затем будет послан на модуль 705 мобильной связи. Следует отметить, что вызов 770 может быть сформирован с использованием алгоритма, отличающегося от вызова 730, используемого для аутентификации устройства 705 для сети. Клиент 710 извлечет вызов 770 из сообщения маркера и передаст его на модуль 705 мобильной связи, указывая, что он является аутентификацией пользователя. Соответственно SIM 705 запросит пользовательский мандат(ы) 775 от клиента 710. Ведущий компьютер 710 затем запросит пользователя 760 о пользовательском вводе 780 данных и возвратит их на модуль 705 мобильной связи. SIM 705 или клиент 710 могут необязательно принимать решение, что пользовательский ввод 780 данных или мандат(ы) следует зашифровать с помощью ключа (то есть предварительно принятого сеансового ключа(ей)) 750 защиты сети.

Используя пользовательский ввод 780 данных, модуль 705 мобильной связи сформирует ответ 785 на вызов и вернет его на клиент 710, который сформирует и пошлет ответ на запрос маркера защиты, который включает в состав, например, идентификатор SIM, вызов 770 и ответ 785 на вызов. Обычно клиент 710 будет запрашивать, чтобы модуль 705 мобильной связи подписал/или зашифровал ответ на запрос маркера защиты вместе с маркером 745 защиты сети с помощью совместно используемого секретного ключа 740, или конкретного для SIM 705 ключа. Сходно с вышеуказанным, ответ на запрос маркера защиты и ответ 785 на вызов могут быть проверены на достоверность с использованием, например, совместно используемого секретного 740 или другого конкретного для модуля 705 мобильной связи ключа. Следует отметить, как предварительно упомянуто, что ответ на запрос маркера защиты может снабжаться или не снабжаться подписью и/или зашифровываться тем же ключом, используемым для формирования ответа 785 на вызов. В любом случае, если инфраструктура 720 мобильной связи проверяет достоверность ответа 785 на вызов (то есть предоставленные пользовательские мандаты являются надлежащими), инфраструктура 720 мобильной связи и/или сервер 715 аутентификации могут отвечать посредством формирования сообщения, которое содержит пользовательский маркер защиты 795 вместе с зашифрованными пользовательскими ключами(ами), которые снабжены подписью и/или зашифрованы с использованием совместно используемого секретного 740 или другого конкретного для устройства 705 ключа. Сообщение может быть дополнительно подписано с использованием или собственного маркера защиты сервера 715 аутентификации (например, сертификация по стандарту X.509, сертификация по технологии Kerberos, и т.д.), или с использованием маркера защиты инфраструктуры 720 мобильной связи. Клиент 710 затем может верифицировать подписанное сообщение и передавать зашифрованный пользовательский сеансовый ключ(и) на SIM 705 для расшифровывания. Используя совместно используемый секретный 740 или другой ключ (в зависимости от обстоятельств), модуль 705 мобильной связи затем может возвращать незашифрованный пользовательский ключ(и) 790 на клиент 710; таким образом аутентифицируя пользователя для сети 792.

Стадия аутентификации пользователя по отношению к службе обеспечивает механизм, предназначенный для сетевого оператора 720 сети мобильной связи, чтобы обеспечивать аутентификацию от имени сторонней службы. Сходно с уровнем защиты пользователя для сети, стадия «пользователь по отношению к службе» является многофакторной аутентификацией и предотвращает, чтобы сеть выдавала маркеры службы без того, чтобы пользователь 760 присутствовал в течение, по меньшей мере, одной стадии аутентификации. Обычно имеются два режима работы сервера 715 аутентификации относительно того, как выдаются маркеры службы. Сначала, если пользователь 760 предварительно получил пользовательский маркер, доверенный сервер 715 может рассматривать пользователя 760 как аутентифицированного и автоматически выдавать маркер службы (при условии, что запрос маркера службы соответственно подписан вместе с пользовательским маркером 790, 795). С другой стороны, если инфраструктура 720 мобильной связи не выдала пользовательский маркер 790, 795, от пользователя 760 будет требоваться аутентификация способом, подобным описанному в общих чертах выше для осуществления запроса пользовательского маркера 795, 790.

На Фиг. 7C иллюстрируется, как различные объекты в сети взаимодействуют по независимой сети 700 при установлении защищенной связи между клиентом 710 и сторонним сервером 728. Как упомянуто выше, устройство 705 мобильной связи и пользователь 760 могут аутентифицироваться для системы 720 оператора мобильной связи, как предварительно описано. Соответственно, имеется защищенная связь между сервером 715 аутентификации и клиентом 710 после надлежащей проверки достоверности платежного счета для устройства 705 мобильной связи и аутентификации принадлежности его пользователю 760. Доверенный сервер 715 (или инфраструктура 720 мобильной связи в зависимости от обстоятельств) может затем выдавать маркеры 724 службы для различных услуг, когда, например, клиент 710 пожелает купить услуги и/или товары от сторонней службы 728. Соответственно, клиент 710 может выдавать маркер 726 службы на сторонний сервер, который затем проверяет достоверность маркера 722 посредством сервера 715 аутентификации. Следует отметить, что сторонний сервер 728 может требовать или не требовать дополнительной аутентификации, и как предварительно описано, может использовать различные механизмы для выполнения такой проверки достоверности. Также следует отметить, что использование маркера 726 службы не только устанавливает защищенную связь между клиентом 710 и сторонним сервером 728, но также может указывать возможность пользователя 760 оплатить одну или несколько единиц услуг и/или товаров способом, подобным таковому, предварительно описанному. Следует отметить, что обычно пока маркер службы не выдан на клиент 710, выдаются маркеры защиты, не имеющие значения для какой-либо другой службы, отличной от сервера 715 аутентификации. Причина состоит в том, что иерархия защиты может препятствовать тому, чтобы какая-либо внешняя сторона надлежащим образом расшифровала маркер устройства, сетевой маркер, или даже пользовательский маркер, поскольку они все являются производными от корневого или совместно используемого ключа 740, известного только на устройстве SIM 705 и инфраструктуре 720 мобильной связи. Это происходит обычно после того, как сервер 715 аутентификации выдает маркер 724 службы, который произвольная сторонняя 728 web-служба может использовать для маркера 724 защиты. Также следует отметить, что вышеуказанные маркеры защиты и сообщения (например, вызовы, ответы на вызовы и т.д.) могут принимать различные форматы или схемы. Например, маркеры и/или сообщения могут быть в формате расширяемого языка разметки (XML), двоичном, или другом подобном формате шифрования, который может быть выдан оператором 720 мобильной связи, который может желать или не желать, чтобы были видимыми некоторые элементы сети для взаимодействия SIM с промежуточным сторонами.

Вышеописанное использование портативного аппаратного устройства 705 для проверки достоверности аутентификации, идентификационной информации и/или платежа может применяться для онлайновой или локальной розничной покупки услуги и/или товаров (например, онлайновой газеты, музыкального произведения, программного приложения или других товаров и услуг) или для предоставления доступа к приложению, исполняющемуся на локальном персональном компьютере (ПК, PC) или клиенте 710 (например, Word®, Adobe Photoshop, программа Print, программное обеспечение «pay-as-you-go») и т.д.). Соответственно, вышеуказанные варианты осуществления особенно выгодны для разблокирования свободно распространяемого защищенного программного обеспечения или содержимого (например, музыки, видео, игр и т.д.) на многих ведущих устройствах 710. Другими словами, лицензия теперь становится связанной с портативным устройством 705 мобильной связи, которое может быть аутентифицировано, как описано выше, предусматривая, что переносимая цифровая идентификационная информация не будет связанной с ограниченным набором вычислительных устройств. Как таковой пользователь 760 идет в дом друга и не должен приносить все свои программы или другое защищенное содержимое; это все является доступным и аутентифицированным посредством портативного устройства 705.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9. Способ по п.1, в котором коммерческая транзакция является прямой внутренней практикой работы в том, что платеж и выбор услуги и/или товаров интегрированы в отдельное приложение, которое не является частью web-браузера.

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

11. Способ по п.1, в котором стоимость является переменной и представлена в платежной информации в виде диапазона значений.

12. Способ по п.1, в котором маркер платежа является аннулируемым потребителем и/или, по меньшей мере, одним поставщиком платежа.

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

14. Способ по п.1, в котором маркер платежа снабжается подписью и/или зашифровывается, по меньшей мере, одним поставщиком платежа, и при этом проверка достоверности маркера платежа, по меньшей мере, для одного поставщика платежа включает в себя проверку достоверности подписи и/или шифрования.

15. Способ по п.1, в котором одно или более из услуг и/или товаров требуют абонентских или многократных платежей, и при этом маркер платежа можно использовать многократно для такого платежа.

16. Способ по п.1, в котором одно или более из услуг и/или товаров требуют абонентских или многократных платежей, и при этом маркер платежа является действительным только для единовременного платежа из абонентских или многократных платежей, и при этом для последующих платежей являются необходимыми дополнительные маркеры.

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

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

19. Способ по п.18, в котором маркер платежа включает в себя информацию представления счета, которая снабжена подписью и/или зашифрована, по меньшей мере, одним поставщиком платежа для подтверждения достоверности маркера платежа и для соответствия маркера платежа запросу авторизации платежа от потребителя.

20. Способ по п.17, в котором маркер платежа истекает после установленного поставщиком платежа некоторого заранее заданного промежутка времени и/или частоты использования.

21. Способ по п.17, в котором, по меньшей мере, часть стоимости является переменной и представлена в информации представления счета в виде диапазона значений.

22. Способ по п.17, в котором маркер платежа является аннулируемым потребителем и/или поставщиком платежа.

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

24. Способ по п.17, в котором одно или более из услуг и/или товаров требует абонентских или многократных платежей, и при этом маркер платежа можно использовать многократно для такого платежа.

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

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

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

28. Способ по п.25, в котором маркер платежа истекает после установленного поставщиком платежа некоторого заранее заданного промежутка времени и/или частоты использования.

29. Способ по п.25, в котором стоимость является переменной и представлена в информации представления счета в виде диапазона значений.

30. Способ по п.25, в котором маркер платежа является аннулируемым потребителем и/ли поставщиком платежа.

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

32. Способ по п.25, в котором маркер платежа снабжен подписью и/или зашифрован поставщиком платежа, и при этом проверка достоверности маркера платежа для поставщика платежа включает в себя проверку достоверности подписи и/или шифрования.

33. Способ по п.25, в котором одно или более из услуг и/или товаров требует абонентских или многократных платежей, и при этом маркер платежа можно использовать многократно для такого платежа.

34. Способ по п.25, в котором одно или более из услуг и/или товаров требует абонентских или многократных платежей, и при этом маркер платежа является действительным только для единовременного платежа из абонентских или многократных платежей, и при этом для последующих платежей необходимы дополнительные маркеры.

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

36. Способ по п.35, в котором одна или более частей электронного счета зашифрована продавцом для того, чтобы одна или более частей были непрозрачными для потребителя и/или поставщика платежа.

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

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

39. Способ по п.35, в котором экземпляр электронного счета снабжен подписью продавца, при этом способ дополнительно содержит этапы, на которых:
принимают от поставщика платежа маркер платежа, чтобы авторизовать платеж по одному или более из услуг и/или товаров, при этом маркер включает в себя подписанный экземпляр электронного счета; и посылают маркер платежа продавцу для авторизации платежа, при этом продавец может проверять достоверность маркера платежа по поступлению от потребителя на основании подписанного экземпляра электронного счета.