Область техники
Изобретение относится к реализации оплаты за обслуживание в телекоммуникационной системе, более конкретно к реализации оплаты за мультимедийное обслуживание.
Предшествующий уровень техники
Плата за обслуживание представляет собой реализацию договора между провайдером обслуживания и потребителем. В принципе, имеются два типа оплаты: распределенный и централизованный.
При распределенном принципе оплаты потребитель производит оплату продавцу каждый раз, когда он использует обслуживание, предоставляемое продавцом. Оплата осуществляется либо наличными, либо с использованием иного эквивалентного метода. Например, доставка почты оплачивается за счет использования марок. Одним из последних примеров способа платежа, основанного на распределенном принципе, являются электронные наличные. Каждая "монета" электронных наличных состоит из шифрованной двоичной последовательности, которая должна быть проверена сервером банка.
При централизованной оплате либо продавец, либо третья сторона контролирует использование предоставляемого обслуживания. Потребитель вносит оплату периодически, например раз в месяц. Счет основывается на данных, собранных за предшествующий период платежа. Хорошо известными примерами централизованной оплаты являются платежи за электричество, телефон и оплата по кредитным карточкам. Централизованные платежи включают в себя три этапа. На первом этапе заключается договор между пользователем и провайдером обслуживания относительно предоставляемого обслуживания и платы за предоставляемое обслуживание. Второй этап состоит в контроле (или измерении) и хранении данных пользования предоставляемым обслуживанием. Счет генерируется в системе выставления счетов на базе хранящейся информации.
Например, централизованная система выставления счетов, используемая в телефонной сети, основывается на договоре между абонентами и телефонной компанией. Сущность этого договора состоит в том, что абоненту предоставляется доступ к телефонному обслуживанию, т.е. он может осуществлять и принимать вызовы. В ответ он вносит плату телефонной компании на базе предварительно определенных тарифов. В типовом случае счет содержит платежи двух различных типов: фиксированные платежи и платежи за пользование предоставляемыми услугами. Фиксированные платежи оплачиваются независимо от того, пользуются ли предоставляемыми услугами или нет. Платежи за пользование услугами зависят от того, сколько вызовов осуществил пользователь, и, возможно, от того, сколько вызовов он принял. Для того чтобы иметь возможность производить платежи за пользование услугами, телефонная компания должна контролировать осуществляемые и принимаемые вызовы. Контроль основан на соединениях и осуществляется коммутаторами в сети.
На фиг.1 иллюстрируется хорошо известный способ централизованной оплаты, используемый в телефонных сетях, путем представления части телефонной сети общего пользования. Для каждого осуществленного вызова сетевой коммутатор КОМ (локальный абонентский коммутатор) создает одну или несколько записей данных платежа ЗДП. Эти записи сначала запоминаются в памяти и затем передаются в централизованную систему выставления счетов, в которой они запоминаются в массовой памяти, например на магнитной ленте или на жестком диске. Могут использоваться дополнительные этапы обработки между коммутатором и системой выставления счетов. На этом этапе записи платежей являются предварительно обработанными, т. е. подготовленными для системы выставления счетов. Предварительная обработка может включать, например, преобразование поля класса тарифа в другой формат. Массовая память системы выставления счетов может содержать миллионы записей. Эти записи образуют "необработанные данные" (исходные данные), которые обрабатывает система выставления счетов. Таким образом, обработка записей платежей производится как процедура обработки отдельных пакетов на более позднюю дату, чем дата генерирования записей. Следует отметить, что на практике платежи могут быть намного более сложными, чем описано в вышеприведенном примере. Например, в сотовой сети каждый участвующий в работе сетевой коммутатор может генерировать записи платежей. Однако принцип оплаты сходен с тем, который представлен выше.
Далее записи платежей определяются как "запись данных платежей" (ЗДП), а программа формирования записей данных платежей определяется как ЗДП-генератор.
Телефонное обслуживание с централизованным принципом оплаты основывается на автономном платеже и на том факте, что в сети имеются ЗДП-генераторы, которые записывают события установки и высвобождения. Однако данный тип оплаты технически не пригоден в случаях, когда в сети предоставляется мультимедийное обслуживание. Имеются две основные причины этого. Во-первых, большинство из используемых в настоящее время видов обслуживания используют протокол сети Интернет (протокол IP), который применяется для обеспечения обслуживания без установления связи. Платежи, основанные на соединениях в телефонных сетях, не пригодны для такого типа системы. Во-вторых, очевидно, что платежи для мультимедийного обслуживания должны базироваться на содержимом передаваемой информации. Современная телефонная сеть может контролировать события установки и разъединения соединения, но она не может контролировать содержимое информации, передаваемой по соединению. При использовании ЗДП-генераторов сетевой оператор должен выбирать между двумя альтернативами: (а) оплата должна базироваться на соединениях независимо от содержимого или (b) в связи с каждой доставкой информация о содержимом передаваемой информации получается от провайдера обслуживания. Первый вариант означает, что оператор не может предоставить принцип оплаты с учетом содержимого; существующие централизованные системы выставления счетов телефонных сетей не могут быть эффективно использованы. Для потребителя это означает, что он получает один счет от оператора и, в дополнение к нему, отдельные счета от каждого их провайдеров услуг. Второй вариант приводит к высокоинтегрированной технически сложной системе, в которой имеется значительный трафик между серверами и ЗДП-генераторами.
Одна из систем выставления счетов для телекоммуникационной сети описана в заявке на европейский патент ЕР-А-0647052. Система имеет отдельный сервер выставления счетов, который осуществляет обработку выставления счетов для провайдеров услуг в сети. В этой системе пользовательский терминал всегда сообщает первым на сервер выставления счетов свои идентификационные данные и идентификационные данные желательной услуги. Сервер выставления счетов затем определяет, имеет ли место авторизация для пользователя в отношении получения данного вида услуги (например, может ли быть предоставлен кредит, необходимый для данной услуги). Если это так, то сервер выставления счетов пересылает к серверу, предоставляющему услугу, и к пользовательскому терминалу временный ключ услуги, который позволяет пользовательскому терминалу получить доступ к серверу, предоставляющему обслуживание. После этого пользовательский терминал передает сообщение запроса соединения к серверу, предоставляющему обслуживание, после чего пользовательский терминал и сервер, предоставляющий обслуживание, могут осуществлять переговоры о сроках предоставления услуги, прежде чем будет осуществлена доставка услуги. При осуществлении услуги сервер, предоставляющий обслуживание, передает сообщение с уведомлением о предоставляемой услуге серверу выставления счетов, который подготавливает счет для пользователя на основе полученного сообщения. Счет может пересылаться как по электронной почте, так и по обычной почте.
Основным недостатком данного типа системы является то, что она не может с выгодой использовать имеющиеся системы, за исключением соединений для передачи. По этой причине сложной операцией является установление обслуживания по выставлению счетов. В дополнение к этому защищенность информации в системе не полностью гарантирована, например, что касается исключения ситуаций непризнания (отрицания одним из участников транзакции факта ее совершения). Это означает, что пользователь должен иметь полное доверие к точности суммы выставленного счета, генерируемого терминалом выставления счетов. Также для пользователя невозможно иметь какие-либо разночтения в сумме полученного в результате счета, например в случаях, когда качество обслуживания на пользовательском терминале низкое, например, вследствие задержек или иных сбоев в сети во время доставки сервером согласованной услуги. Это особенно важно при предоставлении долговременного непрерывного обслуживания.
Сущность изобретения
Целью изобретения является исключение вышеуказанных недостатков и создание решения, которое обеспечивает возможность, например, использовать централизованную систему оплаты для выставления счетов за мультимедийное обслуживание с использованием существующих систем настолько эффективно, насколько это возможно.
Эта задача изобретения решается с использованием решения, определенного в независимых пунктах формулы изобретения.
Основная идея изобретения состоит в использовании в системе по меньшей мере одного отдельного устройства (называемого "сервером выставления счетов"), которое на основе услуги, выбранной пользователем, осуществляет согласование текущего договора с пользователем или которое по меньшей мере может удостоверять, что пользователь получил доступ к обслуживанию в соответственно определенные сроки. Серверы выставления счетов действуют как пункты, от которых записи платежей пересылаются к действительной системе выставления счетов, и дополнительно они могут проверять корректность записей платежей, созданных пользовательским терминалом, перед запоминанием и/или перед пересылкой их в систему выставления счетов. Таким образом, на практике заявленное решение в значительной степени базируется на существующих решениях, реализованных в телефонной сети, причем разница состоит лишь в том, что вместо измерения степени пользования предоставляемым обслуживанием и генерирования записей платежей или сообщений, относящихся к ним, в сети они формируются в пользовательском терминале, который передает записи платежей в отдельный сервер выставления счетов.
Систему, основанную на изобретении, легко реализовать, так как она использует существующие решения в максимально возможной степени. Кроме того, принципы системы таковы, что легко реализовать все факторы, существенные для обеспечения защиты данных: аутентификацию, целостность данных, исключение ситуаций непризнания (т.е. ни одна из сторон, участвующих в передаче данных, не может отрицать факта совершения транзакции) и конфиденциальность (лицо, противоправно получившее доступ к данным, не может интерпретировать какие-либо полученные данные).
Система также делает более простым для провайдера услуг начало функционирования, так как уже имеются существующие средства для выставления счетов (например, система выставления счетов телефонной сети). Они не требуют капиталовложений в реализацию систем оплаты.
Пользователь также располагает возможностью получения немедленного эффекта от полученного в результате счета, например, в случаях, когда качество обслуживания, предоставляемого пользователю, было низким из-за задержек и иных несовершенств сети.
Система также обеспечивает возможность использования параллельных способов платежей. Например, в системе, соответствующей изобретению, электронные деньги могут быть введены для использования в качестве альтернативного или параллельного способа оплаты. Кроме того, система обеспечивает возможность контроля уровня обслуживания, используемого пользователем. Поскольку контроль проводится в пользовательском терминале, который также генерирует записи платежей, процедура генерирования записей платежей может быстро реагировать на изменения уровня обслуживания. Кроме того, система легко масштабируется.
Решение также пригодно для использования в мобильной или сотовой сети, так что пользование услугами не ограничено географическими рамками.
Решение, соответствующее изобретению, может быть использовано в самых различных коммуникационных системах, поскольку оно не зависит от протоколов и методов передачи данных.
Краткое описание чертежей
Ниже изобретение и его предпочтительные варианты осуществления описываются детально со ссылками на примеры 2-10, иллюстрируемые чертежами, на которых представлено следующее:
Фиг. 1 - иллюстрация известного способа оплаты, используемого в телефонных сетях,
Фиг.2 - сетевая среда, в которой должно использоваться изобретение,
Фиг. 3а - иллюстрация передачи сообщения между различными компонентами системы перед началом действительной оплаты,
Фиг. 3b - иллюстрация ситуации, соответствующей фиг.3а, когда в сети используется шлюз между сервером выставления счетов и серверами предоставления обслуживания,
Фиг.4 - иллюстрация окна договора, отображаемого на пользовательском терминале,
Фиг. 5а - пример передачи сообщения между пользовательским терминалом и сервером выставления счетов в ходе одного сеанса оплаты,
Фиг.5b - иллюстрация ситуации, в которой тактовые генераторы сервера выставления счетов и пользовательского терминала имеют смещение один относительно другого,
Фиг.6 - содержимое и структура записи платежа,
Фиг. 7а - структура пользовательского терминала в виде функциональной блок-схемы,
Фиг.7b - подробная структура ЗДП- генератора, представленного на фиг.7а,
Фиг.8 - структура сервера выставления счетов в виде функциональной блок-схемы,
Фиг.9а - иллюстрация случая, когда пользователь использует услугу, предоставляемую сервером, который не принадлежит к области, управляемой собственным сервером выставления счетов пользователя,
Фиг. 9b - иллюстрация передачи сообщения между серверами выставления счетов в случае, представленном на фиг.9а,
Фиг. 10 - иллюстрация примера передачи сообщения, когда пользовательские терминалы расположены в сети кабельного телевидения.
Детальное описание изобретения
В последующем изобретение описывается детально со ссылками на пример, представленный на фиг.2, который иллюстрирует систему, основанную на изобретении, в типовой среде функционирования.
Система содержит пользовательские терминалы (ПТ), расположенные в помещениях пользователя. Они могут представлять собой персональные компьютеры, мобильные станции или отдельные пользовательские терминалы, которые соединены с обычным оконечным оборудованием. Оконечное оборудование может также быть интегрированным, например, в модем.
Кроме того, система содержит по меньшей мере один сервер выставления счетов (СС), который собирает и проверяет подлинность записей платежей, генерируемых пользовательским терминалом. Сервер выставления счетов может быть расположен, например, на границе сети Интернет, в соединении с серверами провайдера обслуживания в сети Интернет (ПОИ). Логически расположение сервера выставления счетов не имеет особого значения, но на практике на выбор местоположения влияют, например, следующие факторы. Во-первых, предпочтительно разместить сервер выставления счетов в соединении с телефонной сетью общего пользования или вблизи от нее, чтобы он имел возможность легкого доступа к существующей системе выставления счетов телефонной сети. Что касается эффективности, существенно, чтобы соединение между пользовательским терминалом и сервером выставления счетов устанавливалось с максимально возможным быстродействием и задержки были легко контролируемыми (что не имеет места в настоящее время, если сервер выставления счетов располагается глубоко в сети Интернет). Целью системы также является предоставление локальных услуг (в географически ограниченном районе), чтобы пользователям выставлялись счета за услуги, например, один раз в месяц, и при этом не имеет смысла расположение сервера выставления счетов далеко от пользователей.
Сервер выставления счетов включает в себя память (ПМ), например, на магнитной ленте, которая используется для хранения всех записей оплаты, которые приняты сервером выставления счетов. Собранные записи счетов периодически передаются в систему выставления счетов (СВС), которая представляет собой существующую систему выставления счетов в телефонной сети общего пользования (ТСОП) или, например, систему, подобную существующей системе выставления счетов, но расположенную в широкополосной сети. Перед передачей в систему выставления счетов записи оплаты могут временно записываться в устройство массовой памяти МП1.
Кроме того, в систему входят провайдеры обслуживания, которые предоставляют то обслуживание, за которое пользователи вносят плату с использованием системы, соответствующей изобретению. Для упрощения чертежа на фиг.2 показан только один провайдер обслуживания ПО1. Такой провайдер обслуживания может предоставлять обслуживание в режиме видеосервиса по запросу через сеть Интернет.
Пользовательский терминал (ПТ) может быть соединен с сетью различными путями, как показано на фиг.2. Например, соединения с Цифровой сетью с комплексным обслуживанием (ISDN) представляют собой возможный вариант выбора. Соединение ISDN может быть реализовано, например, с помощью обычного маршрутизатора (М), при этом в соединении ISDN используется протокол TCP/IP (набор протоколов коммуникации во взаимосвязанном наборе сетей), или с помощью ISDN карты и процедуры базового доступа к ISDN с помощью базового интерфейса абонента (БИА). Пользовательский терминал может также соединяться с сетевым коммутатором посредством модема и аналоговой абонентской линии. Кроме того, существующие методы, основанные на использовании асимметричной цифровой абонентской линии (АЦАЛ) и цифровой абонентской линии с высокой скоростью передачи цифровых данных (ЦАЛВС), предоставляют новые возможности для быстродействующей передачи данных и видеосигналов в линии телефонной сети в виде скрученной пары на абонентские терминалы. Позднее система сможет использоваться, например, для соединений асинхронной передачи данных. Пользовательский терминал может также располагаться, например, в локальной сети компании или иной организации или может представлять собой терминал сети кабельного телевидения. Провайдер обслуживания в сети Интернет может также соединяться с сетевым коммутатором, например, с помощью основного интерфейса абонента (ОИА).
Ниже более детально описана работа системы, соответствующей изобретению. В данном примере предполагается, что провайдер услуги по выставлению счетов представляет собой организационно обособленный блок, который обрабатывает только услуги по выставлению счетов посредством сервера выставления счетов СС, которым он управляет. Таким образом, провайдер услуги по выставлению счетов имеет свою собственную систему выставления счетов СВС.
Первоначально провайдер услуги по выставлению счетов заключает долгосрочный договор с каждым провайдером обслуживания. В этом договоре провайдер услуги по выставлению счетов принимает на себя функции контроля за использованием услуг и сбора оплаты за использование услуги. В качестве компенсации за это провайдер услуги по выставлению счетов может получить определенную долю прибыли за обслуживание или фиксированный тариф. В результате заключенного договора каждая услуга, обеспечиваемая провайдером обслуживания, получает уникальный идентификатор, который является одним и тем же как для сервера выставления счетов, так и для сервера провайдера обслуживания ПО1. Кроме того, каждому идентификатору присвоены параметры выставления счетов, которые используются сервером выставления счетов. Таким образом, в первом варианте осуществления настоящего изобретения сервер выставления счетов имеет базу данных, которая включает в себя параметры выставления счетов для идентификатора каждой услуги каждого провайдера обслуживания. Как будет пояснено позже, этот способ реализации может быть изменен, например, таким образом, что конкретные параметры передаются от сервера провайдера обслуживания к серверу выставления счетов в начале каждого сеанса.
После этого провайдер услуги выставления счетов заключает долгосрочные договоры с пользователями (теми лицами, которые желают использовать услуги, предоставляемые провайдерами обслуживания). Каждый пользователь получает уникальный идентификатор пользователя, который хранится в сервере выставления счетов и, возможно, также в сервисе провайдера обслуживания. Кроме того, каждый пользователь получает пару ключей шифрования, состоящую из ключа общего пользования и ключа индивидуального пользования. Эта пара ключей используется для подписи и удостоверения подписи записей оплаты. Ключ общего пользования, предоставленный пользователю, хранится в сервере выставления счетов, а ключ индивидуального пользования - в оконечном оборудовании. В первом варианте осуществления ключ индивидуального пользования известен только пользователю. Также возможно определить профиль обслуживания для пользователя.
Пользование услугой может начаться после того, как этот долговременный договор установлен.
После того как пользователь выбрал услугу, но перед началом оплаты, между пользователем и системой заключается краткосрочный текущий договор. Этот договор охватывает только услугу, которую пользователь только что выбрал, например просмотр какого-либо фильма или осуществление покупки. Последующее пояснение относится к фиг.3а, которая иллюстрирует заключение текущего договора. На чертеже показаны базы данных, соединенные с сервером выставления счетов, представляющие собой базы данных услуг, выставления счетов и абонентов.
Пользовательский терминал ПТ включает в себя программу браузер (просмотра), например программу просмотра Web-страниц, которую пользователь использует для отыскания соответствующих услуг в сети Интернет. После нахождения соответствующей услуги, которая в данном примере представляет собой видеосервис по запросу, предоставляемый провайдером обслуживания ПO1, пользователь выбирает конкретную услугу (например, фильм), например, путем щелчка на соответствующей опции. Этот этап выбора конкретной услуги показан стрелкой А. В этот момент осуществляется информационный обмен между пользовательским терминалом и сервером провайдера обслуживания.
После того как пользователь сделал свой выбор, сервер провайдера обслуживания пересылает в сервер выставления счетов СС (стрелка В) идентификатор услуги ИДУ, идентифицирующий выбранный фильм, и идентификатор абонента ИДА, идентифицирующий соответствующего пользователя. Идентификатор ИДА получают, например, от пользовательского браузера на основе адреса источника принятых сообщений (например, адрес приемной колодки TCP соединения (соединения с контролем передачи). Таким образом, браузер всегда требуется для выдачи идентификационных данных и адреса пользователя по меньшей мере на сервер услуги выставления счетов, но предпочтительно также и к провайдеру обслуживания. Идентификатор абонента может также, например, извлекаться из базы данных с помощью пароля, вводимого абонентом. Таким путем различные пользователи могут пользоваться услугами, предоставляемыми на один и тот же адрес. Также возможен вариант, когда в сети имеется отдельный сервер, который скрывает идентификацию пользователя от провайдера обслуживания, но выдает информацию провайдеру услуги выставления счетов. Однако такой тип конфигурации более сложен.
После этого сервер выставления счетов СС начинает процедуру обработки пользования конкретной услугой. Сначала сервер выставления счетов извлекает из базы данных услуг параметры, соответствующие конкретной услуге, и передает (стрелка С) определенный тип записи данных платежа (ЗДП) на пользовательский терминал. Запись платежа содержит параметры выставления счета, которые должны использоваться для конкретного сеанса и номера договора. После приема этой первоначальной записи платежа программа пользовательского терминала открывает окно на пользовательском терминале, которое определяется как окно договора. На фиг. 4 показан пример окна договора, использующего фиктивные имена серверов. Окно отображает на основе информации, полученной от сервера выставления счетов, основные данные о разных сторонах договора и о конкретной предоставляемой услуге. Кроме того, окно отображает номер договора, который идентифицирует данный конкретный сеанс предоставления услуги. Различие между этим договором и вышеупомянутым долгосрочным договором состоит в том, что этот договор является краткосрочным, он учитывает только сеанс текущей предоставляемой услуги. Так данный договор охватывает, например, только просмотр выбранного фильма. Путем щелчка на кнопке "принятие" пользователь подтверждает принятие предоставляемой ему услуги и подтверждает основу для оплаты услуги. Пользователь может отозвать предоставляемую услугу путем щелчка на кнопке "отмена". Пользователь может также программировать терминал для автоматического приема предоставляемой услуги, например, в случаях, когда полная цена или цена за единицу времени меньше, чем предварительно определенное значение.
В результате принятия пользователем предоставляемой услуги пользовательский терминал возвращает в сервер выставления счетов запись платежа, которую он получил от него. Однако запись платежа, которая возвращается, включает в себя электронную подпись (фиг.3а, стрелка D). Электронная подпись ссылается на известный алгоритм шифрования, основанный на паре ключей. Шифрование осуществляется с использованием ключа индивидуального пользования, хотя любое лицо может дешифровать сообщение с применением ключа общего пользования. Конфиденциальность сообщения, таким образом, теряется, но это обеспечивает гарантию того, что сообщение принято от корректного источника. Таким образом, передатчик не может отрицать тот факт, что он передал сообщение. При использовании электронной подписи все сообщение обычно не шифруется, а шифруется только дайджест, образованный из сообщения. Дайджест представляет собой некоторый тип контрольной суммы. С точки зрения шифрования такой дайджест является весьма эффективным средством, и постороннее лицо не может создать сообщение, которое имело бы идентичный дайджест. Дайджест и временная метка шифруются с использованием индивидуального ключа передатчика и образуют электронную подпись. Имеется несколько различных известных опций для реализации электронной подписи, но поскольку изобретение не имеет отношения к подписям передаваемых сообщений, то реализация подписей не рассматривается более детально. Любое лицо, заинтересованное в данном вопросе, может обратиться за более детальной информацией к различным опубликованным источникам (см., например, Schneier, Applied Cryptography, ISBN 0-471-11709-9, Wiley& Sons, 1996).
После этого сервер выставления счетов СС проверяет достоверность подписи с использованием известного способа в целях аутентификации записи данных платежа (ЗДП). Для этой цели сервер выставления счетов извлекает из своей базы данных абонентов ключ общего пользования для конкретного пользователя (стрелка Е). Сервер выставления счетов запоминает принятую запись платежа в свою базу данных выставления счетов (стрелка F) в течение некоторого времени на случай, если пользователь направит рекламацию на обслуживание в некоторый более поздний момент времени. После этого сервер выставления счетов запрашивает провайдера обслуживания о начале передачи информации пользователю (стрелка G).
Процедура, описанная выше, может варьироваться, например, так, чтобы сервер провайдера СП1 осуществлял передачу после того, как пользователь выбрал услугу, идентификатор услуги и другую, вероятно, требующуюся информацию, непосредственно на пользовательский терминал, который передает идентификатор обслуживания вновь к серверу выставления счетов. Для предотвращения возможности изменения пользователем идентификатора услуги сервер должен добавлять к сообщению электронную подпись, которую распознает сервер выставления счетов, или сервер выставления счетов должен проверять достоверность идентификатора услуги отдельно от сервера провайдера СП1 после того, как он принял идентификатор от пользовательского терминала. В другом варианте сервер провайдера СП1 формирует первоначальную запись платежа, которая содержит параметры выставления счетов, которые должны использоваться в конкретном сеансе обслуживания. В данном случае сервер выставления счетов только удостоверяет сообщение и передает его в пользовательский терминал, или сервер выставления оплаты может добавлять номер договора к сообщению.
Также возможно использовать отдельный шлюзовой компьютер в сети между сервером выставления счетов и серверами провайдера обслуживания. В этом случае шлюзовой компьютер имеет список доступных услуг, а сервер провайдера обслуживания СП содержит только текущую информацию, относящуюся к предоставляемой услуге (например, видеоданные). На фиг.3b иллюстрируется формирование текущего договора при использовании данной опции. Так, в данном случае шлюзовой компьютер ШК обрабатывает те же самые операции, что и сервер в варианте, представленном на фиг. 3а. Когда шлюзовой компьютер получает от сервера обслуживания запрос на передачу информации (стрелка G), он пересылает серверу запрос начала процедуры (стрелка Н), который содержит адрес пользовательского терминала и идентификатор услуги. В данном варианте может использоваться дополнительная проверка, так что шлюзовой компьютер отдельно от сервера проверяет, может ли быть предоставлена требуемая услуга пользователю. Могут иметься различные причины данной дополнительной проверки, что показано пунктирной линией на фиг.3b, например проверка нагрузки сервера. Сервер выставления счетов и шлюзовой компьютер не требуется физически разделять; они могут быть интегрированы в одном компьютере.
Ниже описаны операции в способе после того, как текущий договор заключен с использованием одного из способов реализации, упомянутых выше. После того как процедура обслуживания началась (например, начался показ фильма), пользовательский терминал пересылает, например, периодически записи оплаты, которые имеют электронные подписи и которые содержат информацию о сумме, которая должна быть оплачена. Таким образом, каждая запись данных платежа, которая должна быть передана, представляет платеж за определенный интервал времени, и полная сумма платежа получается суммированием оплаченных сумм во всех записях платежа, которые имеют один и тот же номер договора. Время между двумя последовательными записями данных платежа (и тем самым суммы платежа для одной записи данных платежа) может зависеть от провайдера обслуживания.
Сервер выставления счетов проверяет действительность происхождения каждой записи платежа с использованием пользовательского ключа шифрования общего пользования и запоминает полученные записи данных платежа в базе данных выставления счетов.
Из базы данных выставления счетов записи платежа периодически переносятся в систему выставления счетов СВС (фиг.2), где они используются для формирования счетов с использованием известного способа. Счета должны посылаться пользователям. Один счет содержит список и платежи для всех услуг, которые пользователь использовал в течение периода оплаты (например, за месяц). Счет может доставляться как печатная копия по почте или в электронной форме к пользовательскому терминалу. Поскольку работа системы выставления счетов известна, то она здесь не описывается детально.
В системе могут иметься, например, девять различных типов (0 - 8) записей данных платежа (сообщений платежа), определяемых следующим образом:
0. Договор: Это первоначальная запись данных платежа (стрелка С, фиг.3), которую сервер выставления счетов пересылает (без подписи) к пользователю и которую пользовательский терминал возвращает к серверу выставления счетов с подписью, если пользователь принимает предложенный договор.
1. Платеж: Этот тип записей данных платежа пересылается с подписью в процессе сеанса обслуживания от пользовательского терминала к серверу выставления счетов, который проверяет их.
2. Конечная запись: Этот тип записей данных платежа соответствует типу 1 в других аспектах, но он включает в себя в качестве дополнительной информации оператор, указывающий, что это последняя запись данных платежа, которую пользовательский терминал собирается передать в ходе текущего сеанса. Этот тип записи передается, например, когда пользователь прерывает обслуживание. Он может использоваться для однократных платежей.
3. Импульс: Этот тип записей данных платежа посылается от сервера выставления счетов к пользовательскому терминалу. Назначением его является сообщить пользовательскому терминалу, что он должен передать новую запись данных платежа, если обслуживание должно продолжаться. Если пользовательский терминал не передает действительную запись данных платежа в течение определенного интервала времени, то сервер выставления счетов передает сообщение прерывания к серверу провайдера обслуживания.
4. Номер пропущенной последовательности: Этот тип записи платежа передается от сервера выставления счетов к пользовательскому терминалу (в течение продолжения действия договора), чтобы уведомить о том, что запись данных платежа, имеющая определенный номер последовательности, не получена на сервере выставления счетов, или о том, что запись данных платежа не действительна. В этом случае пользовательский терминал может передать запись данных платежа вновь, чтобы исправить ситуацию. Однако данный тип функциональных характеристик не обязательно обеспечивать для каждой стороны. Если пользовательский терминал не отвечает на данный тип записей данных платежа, то наилучшим вариантом выбора является то, что система выставления счетов не имеет права выставлять счет за эту часть пропущенной записи данных платежа.
5. Модифицированный договор: Этот тип записей данных платежа передается от сервера выставления счетов к пользователю и соответствует типу 0 записей платежа в остальных аспектах, но не содержит нового номера договора. Номер договора тот же самый, что и номер краткосрочного договора, который используется в данный момент. Эта запись данных платежа передается в ходе сеанса обслуживания для уведомления о том, что параметры выставления счета изменились. Пользовательский терминал может, например, автоматически принять новый договор, если цена снизилась; в других случаях может потребоваться принятие договора пользователем.
6. Прерывание: Этот тип записей данных платежа может передаваться в любом направлении для указания, что договор должен быть завершен. Передатчик подписывает запись данных платежа.
7. Электронные деньги: Также возможно использовать систему выставления счетов таким образом, что запись данных платежа (типа 1 или 2), связанная с определенным платежом, включает в себя оплату в электронных деньгах. Однако сервер выставления счетов не переносит электронные деньги в систему выставления счетов. Сервер выставления счетов переносит их непосредственно, например, на сервер банка (всякий раз, когда он накопил некоторое, относительно малое, количество электронных денег) или на сетевой сервер, поддерживаемый другими организациями (сервер системы выставления счетов СВС' на фиг.2), который производит расчеты непосредственно с расчетным счетом пользователя. Помимо централизованной системы выставления счетов СВС электронные деньги могут использоваться для нормальных сделок с использованием электронных денег или в качестве альтернативной реализации вместо централизованной системы выставления счетов.
8. Синхронизация оплаты: Этот тип записи пересылается от сервера выставления счетов к пользовательскому терминалу (в течение непрерывно действующего договора) для информирования о том, что записи данных платежа пересылаются слишком часто. В этом случае пользовательский терминал может пропустить одну передачу записи данных платежа.
На фиг.5 показан пример передачи сообщения между пользовательским терминалом и сервером выставления счетов. Тип каждого сообщения указан над стрелкой, представляющей сообщение. Сообщения с электронными подписями показаны непрерывными линиями, а сообщения без электронных подписей (существует только одно такое сообщение, и оно также может сопровождаться подписью) показаны пунктирными линиями. На чертеже иллюстрируется случай, когда сервер выставления счетов уведомляет в процессе обслуживания, что определенная запись платежа пропущена.
В зависимости от числа процедур, выполняемых одновременно в пользовательском терминале, время (Т) между двумя последовательными типами 1 ЗДП может варьироваться. Если нагрузка пользовательского терминала увеличивается весьма значительно и генерирование ЗДП задерживается относительно номинального значения, то сумма расходов, включенная в ЗДП, соответственно увеличивается.
На практике непрерывное оплачивание расходов несет в себе проблему синхронизации, обусловленную уходом тактовых генераторов пользовательского терминала. В результате может случиться, что пользовательский терминал не передает информацию с корректной частотой. Эта проблема может быть решена, например, путем разрешения серверу выставления счетов допускать "ошибку" определенной величины в общей сумме аккумулированного платежа (например, 3%). Эта "ошибка" может быть увеличена вследствие неточного расчета/округления в пользовательском терминале. Если "ошибка" увеличивается в процессе сеанса платежа так, что она становится больше, чем может допустить сервер выставления счетов, то сервер выставления счетов передает запись данных платежа типа 4 с номером последовательности, который представляет собой номер последовательности самой последней записи данных платежа плюс один. После этого имеется несколько вариантов возврата пользовательского терминала к конкретной записи данных платежа. Пользовательский терминал может, например, программироваться для приема автоматически всех записей платежа данного типа, которые имеют сумму, меньшую, чем предварительно определенный предел.
На фиг. 5b показана ситуация, определенная выше, путем представления последовательных временных кадров сервера выставления счетов с опорной меткой ВКВЗ (временной кадр видеосервиса по запросу) и временных кадров пользовательского терминала между ними с опорной меткой ВКПТ (временной кадр пользовательского терминала). Пользовательский терминал пересылает в начале каждого временного кадра ЗДП (тип 1). Когда имеется временной кадр в сервере выставления счетов, для которого отсутствует оплата, то сервер автоматически отвечает передачей записи данных платежа и непосредственно после этого следующей записью данных платежа, когда начинается следующий временной кадр пользовательского терминала.
Если тактовый генератор пользовательского терминала имеет повышенную частоту, то пользовательский терминал в некоторый момент времени пошлет две ЗДП в течение одного временного кадра сервера выставления счетов. Этот тип ситуации может быть скорректирован, например, таким путем, что сервер выставления счетов передает избыточное сообщение в пользовательский терминал. Это избыточное сообщение является логической противоположностью ЗДП типа 4. После приема избыточной ЗДП пользовательский терминал пропускает одну ЗДП. Для этой цели требуется отдельный тип ЗДП (тип 8).
Вся информация, требуемая в системе, передается в последовательных полях сообщений протокола (записей оплаты). На фиг.6 показаны поля, используемые в записях оплаты:
ТИП: Указывает тип ЗДП, т.е. конкретный один из восьми типов ЗДП, упомянутых выше.
ДЛИНА: Данное поле указывает общую длину ЗДП в байтах, включая поля типа и длины.
НОМЕР ДОГОВОРА: Данное поле включает целое число, выдаваемое сервером выставления счетов. Этот номер является одним и тем же для всех ЗДП, которые относятся к одному и тому же сеансу оплаты.
НОМЕР ПОСЛЕДОВАТЕЛЬНОСТИ: Целое число, которое указывает порядок генерирования ЗДП в течение одного и того же сеанса оплаты. Пользовательский терминал присваивает номер 0 ЗДП (типа 0), которую он возвращает. После этого он увеличивает номер на один для каждой ЗДП. Это поле не определено в ЗДП типов 3, 5, 6 и 7, а в ЗДП типа 4 оно указывает номер последовательности пропущенной ЗДП.
ИДЕНТИФИКАТОР УСЛУГИ: Содержимое этого поля указывает услугу, за которую пользователь вносит плату. Параметр в этом поле получает свое значение в результате договора между провайдером услуги выставления счетов и провайдером мультимедийного обслуживания.
ТИП УСЛУГИ: Параметр в этом поле указывает категорию услуг в различных классах для статистических целей. Например, Web-страницы, видеосервис по запросу, пересылка файла и т.д.
НАЧАЛЬНОЕ ВРЕМЯ: Параметр в этом поле указывает текущее время для ЗДП типов 0 и 5, а также 3, 4 и 6 и начальное время периода оплаты для ЗДП типов 1 и 2.
ВРЕМЯ ОКОНЧАНИЯ: Параметр в этом поле определяет окончание сеанса оплаты для ЗДП типа 1 или 2. Для ЗДП типов 0 и 5 разница между начальным временем и временем окончания представляет собой максимально допустимый период оплаты. В ЗДП других типов этот параметр не определен.
ИДЕНТИФИКАТОРЫ: Параметр в этом поле указывает пользователя, сервер выставления счетов и идентификаторы серверов. Эти идентификаторы могут представлять собой целые числа или сетевые адреса, но они должны быть уникальными в пределах системы выставления счетов.
МЕТОД ПЛАТЕЖА: Параметр в этом поле определяется для ЗДП типов 0, 5, 1 и 2. Методы платежа могут классифицироваться следующим образом: свободный, однократный платеж (одна ЗДП), периодический или с внешним запуском, т.е. другая процедура в пользовательском терминале может его запустить. Например, видеоплейер пользовательского терминала может запускать генерацию ЗДП один раз в минуту, если приемлемый видеосигнал принимается в течение самого последнего времени.
СУММА ДЕНЕГ: Это поле указывает долг пользователя (либо для всего сеанса, либо для интервала времени между двумя ЗДП).
ДАННЫЕ ТРАФИКА: Данное поле содержит информацию, пересылаемую от внешней прикладной программы пользовательского терминала к пользовательскому терминалу и дальше в сеть.
ПОДПИСЬ: данное поле содержит электронную подпись пользователя, которая используется для аутентификации ЗДП.
Фиг. 7а иллюстрирует функционирование пользовательского терминала (ПТ) с помощью функциональной блок-схемы. В соответствии с изобретением основным звеном аппаратуры является ЗДП-генератор (ЗГ), который генерирует записи платежей. С ЗДП-генератором связана библиотека защиты (БЗ). Ее память содержит пользовательские ключи шифрования индивидуального пользования и используется для обработки подписей записей платежей. ЗДП-генератор создает ЗДП и передает их в библиотеку защиты, где они подписываются с использованием пользовательского ключа шифрования индивидуального пользования. Библиотека защиты возвращает подписанные ЗДП в ЗДП-генератор, который передает их в сервер выставления счетов (СС). Если среда применения такова, что подписанные сообщения должны пересылаться между пользовательским терминалом и сервером выставления счетов, то библиотека защиты осуществляет обработку в соответствии с функциями шифрования, подписи и верификации подписи.
Библиотека защиты может быть реализована на основе аппаратных средств или на основе программного обеспечения. Однако решение, основанное на применении аппаратных средств, обеспечивает более высокое быстродействие. Библиотека защиты или ее часть может быть реализована, например, с использованием интеллектуальной карточки (карточки с интегральной схемой, включающей в себя микропроцессор), которая содержит, например, ключ шифрования индивидуального пользования для применения его пользователем.
Кроме того, пользовательский терминал включает в себя интерактивные элементы для приема данных обслуживания. Они могут включать в себя, например, плейер предоставляемой услуги (ПУ), который может представлять собой видеоплейер для воспроизведения видеосигнала, получаемого из сети, и может также выдавать команды ЗДП-генератору о генерировании записей платежей. Браузер услуги (БУ), плейер предоставляемой услуги (ПУ) и ЗДП-генератор соединены с сетью через коммуникационную библиотеку (КБ) терминала. КБ образует стек протоколов, в соответствии с которыми функционирует пользовательский терминал. Этот стек протоколов может представлять собой, например, стек протоколов TCP/IP, например, от Microsoft Winsock.
Пользовательский терминал может также содержать счетчик выставления счетов СчС, который пользователь может использовать для проверки точности счета, пересылаемого провайдером обслуживания. Кроме того, пользовательский терминал может иметь различные компоненты для контроля качества предоставляемой услуги для принятой информации. Например, видеоплейер может выдать команду источнику остановить передачу информации, если качество предоставляемой услуги падает ниже определенного уровня.
На фиг. 7b показана более детально функциональная блок-схема ЗДП-генератора. Блок логики договора (БЛД1) обеспечивает генерацию записей оплаты на базе информации, запомненной в базе данных конфигурации (БДК). Она содержит логику, которая переносит принятую информацию договора в графический пользовательский интерфейс (ГПИ) и генерирует определенный тип записи платежа, как определено выше. Эта логика включает в себя компоненты тактирования, которые определяют время между двумя последовательными ЗДП. Блок логики договора БЛД1 соединен с коммуникационной библиотекой и с сетью через интерфейс внешнего управления и с плейером предоставляемой услуги через интерфейс внутреннего управления. Интерфейс внешнего управления осуществляет преобразование между внутренним и внешним форматом ЗДП. Интерфейс внутреннего управления обеспечивает пересылку сообщения между плейером предоставляемой услуги и блоком логики договора и обеспечивает необходимые преобразования между форматом сообщения, используемым плейером предоставляемой услуги, и внутренним форматом сообщения, используемым аппаратурой. Соединение между интерфейсом внутреннего управления и плейером предоставляемой услуги (интерфейс A3) может быть реализовано, например, с использованием коммуникационной библиотеки (приемной колодки TCP). База данных конфигурации БДК используется для хранения установок, которые сделаны пользователем (предпочтения пользователя), а также может быть использована для хранения информации о различных услугах (например, фильмах), которые предоставляются пользователю на базе принятой идентификации услуги. Эта база данных может быть реализована, например, с использованием программных продуктов Microsoft Access или Borland Paradox. База данных конфигурации управляется с использованием блока управления (БУ). Блок управления, база данных конфигурации и блок логики договора соединены с графическим пользовательским интерфейсом (ГПИ) устройства. Этот интерфейс может быть реализован с использованием, например, приложений Java или средств программирования Microsoft Visual Basic. (Приложения Java представляют собой маленькие пакеты программ, которые пересылаются на пользовательский компьютер, когда пользователь открывает Web-страницу, содержащую эти приложения.) Заметим, что часть базы данных конфигурации может быть размещена в сети.
Если плейер предоставляемой услуги спроектирован, например, для видеосервиса по заказу, то он может быть реализован с помощью персонального компьютера и программы, созданной для услуг видеосервиса по заказу. Одной из таких программ является StreamWorks компании Xing Technology Inc. (США).
Блок управления и блок логики договора соединены с библиотекой защиты посредством интерфейса А1. Библиотека защиты и интерфейс А1 могут быть реализованы, например, с использованием интеллектуальной карточки SETCOS 3.1 компании Setec Oy или с использованием иного эквивалентного продукта, который основывается на международных стандартах для интеллектуальных карточек.
Способы пересылки данных, используемых в реализации способа, варьируются соответственно типу сети и способу, используемому для соединения пользовательского терминала с сетью. Если пользовательский терминал соединен с сетью, например, через маршрутизатор (канал протокола IP), то записи платежей могут передаваться в кадрах протокола TCP. Если пользователь имеет, например, соединение Цифровой сети с комплексным обслуживанием (ISDN-соединение) (2B+D), то ЗДП могут передаваться в пакетах ISDN-сигнализации (сообщения, передаваемые от пользователя к пользователю) по D-каналу или, например, TCP-соединение может быть реализовано посредством одного из В-каналов. Записи платежей могут также передаваться, например, в сообщениях протокола ТСАР сети, использующей систему сигнализации SS7. Существенным моментом для передачи данных является то, что только между пользовательским терминалом, сервером выставления счетов и сервером требуется наличие соединения, что дает возможность передачи сообщений, определенных выше.
Способ передачи информации от провайдера обслуживания к пользователю не описан выше, так как он непосредственно не относится к изобретению. Информация может передаваться пакетами (как это имеет место в настоящее время в сети Интернет) или для передачи могут использоваться специализированные соединения (как фиксированные, так и виртуальные). Некоторые услуги, например видеосервис по запросу, могут требовать специализированного соединения между пользователем и сервером. Оператор сети может рассчитываться за эти соединения отдельно, но если определенная сумма за использование этих соединений должна включаться в счет в системе, соответствующей изобретению, то необходимо аккумулировать ЗДП, генерируемые сетевыми коммутаторами. В этом случае было бы предпочтительным, если бы эти ЗДП содержали номер
договора, так как в этом случае стоимость использования соединений можно было бы связать с услугой, которая потребовала формирования данного соединения. Таким образом, предпочтительнее, если вызывающая сторона передает номер договора к коммутатору. Это может быть сделано, например, с использованием сообщений управления, связанных с формированием и разъединением соединения (соединения, через которое осуществляется реализация услуги). Соединения и использование услуги могут быть увязаны друг с другом за счет использования временных меток в ЗДП.
На фиг. 8 представлена структура сервера выставления счетов (СС) в виде блок-схемы обобщенного уровня. Основное звено аппаратуры образует блок логики договора БЛД2, который имеет доступ к базе данных обслуживания, абонентской базе данных (АБД) и к базе данных выставления счетов (ВДВС). База данных обслуживания содержит информацию об услугах различных провайдеров и параметры для платежей за пользование услугами. Сервер выставления счетов может также независимо изменять параметры, например, в соответствии с временем суток. Абонентская база данных содержит пользовательские данные для оператора, управляющего сервером выставления счетов (включая ключ общего пользования для каждого пользователя). Записи платежей, полученные от пользовательского терминала, хранятся в базе данных выставления счетов. Блок шифрования (БШ) связан с блоком логики договоров. Блок шифрования выполняет обработку, относящуюся к верификации подписи записи платежа. Этот блок соответствует блоку библиотеки защиты (БЗ) пользовательского терминала. Блок логики договоров получает от пользовательских терминалов записи платежей с подписями пользовательских терминалов и пересылает их к блоку шифрования для осуществления проверки подлинности. Блок логики договоров запоминает принятые записи платежей в базе данных выставления счетов. Блок логики договоров соединен с сетью через коммуникационную библиотеку (КБ'), которая формирует стек протоколов, определяющий соединение, которое необходимо осуществить.
На практике блоки логики договоров, описанные выше, могут быть реализованы, например, с использованием инструментальных средств, базирующихся на международном стандарте SDL (язык системного описания), например инструментальных средств SDT компании Teleologic АВ.
Базы данных сервера выставления счетов могут находиться в памяти, описанной выше (фиг. 2) и расположенной взаимосвязанно с сервером выставления счетов. Кроме того, записи платежей могут храниться в отдельной массовой памяти (МП1) (фиг. 2), которая находится в сети между сервером выставления счетов и системой выставления счетов и которая организована таким образом, чтобы система выставления счетов могла легко манипулировать информацией, хранящейся в ней. При использовании такой отдельной базы данных провайдеры обслуживания получают возможность использовать базу данных для различного рода запросов, чтобы усовершенствовать предоставляемое обслуживание. Провайдер обслуживания или пользователь может, например, запросить о стоимости определенной услуги в течение периода оплаты (например, с использованием электронной почты).
Базы данных абонентов и услуг могут находиться в сервере выставления счетов и в сервере провайдера обслуживания (последний может использовать их, например, для аутентификации данных). Эти базы данных могут поддерживаться различными организациями, и не требуется, чтобы они были идентичными. Например, автономные услуги не требуется запоминать в базе данных сервера выставления счетов. Также абонентские записи и записи услуг в базах данных не обязательно должны быть идентичными. Только идентификаторы абонентов и услуг, которые сервер обслуживания пересылает на сервер выставления счетов, должны быть идентичными.
Сервер выставления счетов может состоять из нескольких параллельно работающих блоков сервера, и в связи с ними могут использоваться известные принципы распределения, например, путем снабжения их общим блоком распределения нагрузки, который распределяет запросы на обслуживание между параллельными блоками некоторым предварительно определенным образом.
Услуга, предоставляемая с использованием изобретения, понимается как локальная в том отношении, что один сервер выставления счетов обрабатывает определенную группу пользователей, которые располагаются в территориально ограниченном районе. На фиг.9а показаны области обслуживания ОО и ОО', которые обслуживаются двумя различными серверами выставления счетов СС1 и СС2. Естественно, для пользователя определенного сервера выставления счетов имеется возможность пользоваться услугами сервера, расположенного в области, обслуживаемой другим провайдером услуги выставления счетов (т.е. другим сервером выставления счетов), например, в другом городе или стране. На фиг.9а показана ситуация данного типа, когда пользователь П1, находящийся в области, обслуживаемой сервером выставления счетов СС1, контактирует с сервером С3, который имеет соглашение с провайдером услуги выставления счетов, управляющим сервером выставления счетов СС2. На фиг.9b иллюстрируется пересылка сообщений.
Когда сервер выставления счетов СС2 получает идентификатор пользователя ИДП (или адрес) и идентификатор услуги (ИДУ) от сервера С3, он замечает, что соответствующий пользователь не относится к нему. В этом случае провайдеры услуги выставления счетов должны устанавливать взаимный контакт так, чтобы сервер выставления счетов СС2 после приема идентификаторов пользователя и услуги от сервера С3 мог передать исходную запись данных платежа (ЗДП договора) на сервер выставления счетов СС1. Последний (т.е. сервер СС1) преобразует информацию, специфическую для сервера выставления счетов (идентификатор сервера выставления счетов и номер договора), чтобы обеспечить соответствие с его собственной информацией, и после этого передает исходную запись данных платежа соответствующему пользователю. ЗДП договора, принятая от сервера выставления счетов СС2, связывается с ЗДП договора, пересланной пользователю, путем запоминания в сервере выставления счетов СС1 "пустой" ЗДП, которая в противном случае является той же самой, что и подписанная ЗДП договора, полученная от сервера выставления счетов СС2, но идентификатор сервера заменен номером договора, который сервер выставления счетов СС1 использует для идентификации соответствующей услуги. Таким образом, сервер выставления счетов СС1 получает информацию о том, что услуга исходит от провайдера обслуживания, который имеет договор с другим провайдером услуги выставления счетов.
Поле этого сервер выставления счетов СС1 может аккумулировать записи данных платежей, получаемые от пользования услугой. Таким образом, ситуация сходна с той, которая имеет место при размещении пользователем международного вызова.
Локально аккумулированные ЗДП могут либо обрабатываться в локальной системе выставления счетов, либо могут пересылаться к провайдеру услуги выставления счетов, который владеет сервером выставления счетов СС2. В телефонной сети ЗДП обрабатываются, и выставление счетов осуществляется в локальной системе. Часть выставленных счетов, относящаяся к другому оператору, возвращается к нему позже.
Вышеприведенный пример показывает, что способ, соответствующий изобретению, может быть расширен до глобального масштаба путем заключения текущего договора с локальным сервером выставления счета и с использованием тех же самых способов управления, что и в телефонной сети общего пользования.
Путем дополнения системы регистрами исходного местоположения и местоположения визитеров, аналогично тому, что имеет место в сетях мобильной связи, можно реализовать режим роуминга, как в сетях мобильной связи. В этом случае существенным является обеспечение того, чтобы пользовательский ключ шифрования общего пользования мог надежным образом пересылаться серверу выставления счетов, ближнему к абоненту, так чтобы соответствующий сервер мог проверять действительность записей платежей. (Если пересылка не может быть осуществлена надежным образом, то возникает опасность того, что третья сторона сможет изменить ключ в процессе пересылки и таким образом перенести расходы на счет исходного абонента. ) Пользовательский ключ шифрования общего пользования может пересылаться, например, в базу данных (регистр местоположения визитеров - РМВ) вблизи сервера выставления счетов, к которому сервер выставления счетов имеет доступ. Сервер выставления счетов, ближайший к абоненту, совершающему роуминг, может осуществлять обработку, связанную с выставлением счетов, путем использования идентификатора сервера выставления счетов, собственного для абонента. Аккумулированные ЗДП пересылаются на сервер выставления счетов, собственный для абонента, после окончания сеанса обслуживания.
Пользовательский терминал может представлять собой, например, обычную мобильную станцию, к которой добавлены свойства, необходимые для реализации изобретения, и изобретение может использоваться в мобильной телефонной сети или мобильной сети передачи данных.
Если пользовательские терминалы находятся в сети кабельного телевидения, то обслуживание, например видеосервис, может реализовываться, как описано ниже. Поскольку сеть кабельного телевидения является сетью вещания, в которой все пользователи принимают один и тот же сигнал, сервер шифрует видеосигнал и передает его с использованием ключа шифрования, который изменяется часто, например каждые 5-10 минут. Каждый раз, когда сервер изменяет ключ шифрования, он информирует сервер выставления счетов о ключе шифрования, и сервер выставления счетов выдает новый ключ шифрования на пользовательский терминал после приема соответствующего платежа от пользовательского терминала.
Фиг. 10 иллюстрирует платеж начисленной суммы в случае, когда пользовательские терминалы являются терминалами системы кабельного телевидения. В результате заключения договора сервер выставления счетов выдает пользовательскому терминалу первый ключ шифрования, который он получил от сервера, предоставляющего обслуживание. Сервер выставления счетов передает периодически запись платежа типа 3 (импульс) на пользовательские терминалы. Таким путем он запрашивает новый платеж. В ответ на платеж сервер выставления счетов передает новый ключ, который он получил от сервера, предоставляющего обслуживание. Этот ключ может быть передан, например, в ЗДП отдельно определенного типа (типа 9), в который он может быть помещен, в зашифрованном виде с использованием пользовательского ключа шифрования общего пользования, в поле подписи. Шифрование может быть реализовано, если имеется риск того, что постороннее лицо может скопировать ключ. Ключ передается только на те пользовательские терминалы, от которых принята ЗДП. Провайдер обслуживания не обязан передавать ключ каждый раз на сервер выставления счетов, все ключи могут быть переданы вместе. Также нет необходимости заключать отдельный контракт с пользователем с использованием ЗДП типа 0. Вместо этого передача первого ключа может осуществляться как предложение текущего договора со стороны системы, и первая ЗДП может действовать как принятие этого договора со стороны пользователя. После этого сеанс обслуживания получает номер договора.
Данная задача в применении к кабельному телевидению может быть реализована без записей платежей типа 3. В этом случае ключ передается на каждый пользовательский терминал как ответ на ЗДП, переданную терминалом.
Хотя изобретение было описано в связи с примерами, иллюстрируемыми чертежами, следует иметь в виду, что изобретение не ограничивается этими примерами и может быть видоизменено различными путями в пределах, определяемых пунктами формулы изобретения. Ниже кратко описаны некоторые из возможных модификаций.
Например, возможно, что пользовательский терминал не передает реальные записи платежей к серверу выставления счетов, а передает некоторые иные сообщения, которые сервер выставления счетов может использовать в качестве базы для генерирования записей платежей. Например, пользовательский терминал может передать так называемые сообщения сохранения состояния включения, пока продолжается сеанс обслуживания, после чего сервер выставления счетов генерирует запись плат, в которой длительность сеанса обслуживания определяется как время между последним сообщением сохранения состояния включения и временем принятия договора. Записи платежей могут также генерироваться в сервере обслуживания после того, как пользовательский терминал уведомил о принятии выбранной услуги в установленных терминах.
В системе, описанной выше, обслуживание, предоставляемое провайдером обслуживания, состоит в передаче информации. В принципе, ничто не препятствует тому, чтобы услуга состояла в доставке физических товаров (например, в случае почтового обслуживания) потребителю. В этом случае записи данных платежей могут генерироваться в сервере выставления счетов (так как пользовательский терминал не может измерить качество обслуживания).
Если соединение между пользователем и сервером выставления счетов обладает достаточной степенью защиты, то может оказаться необязательным включение электронной подписи в записи платежей. Также передача отдельного сообщения принятия для текущего обслуживания в сервер выставления счетов не является необходимой, так как первая ЗДП может действовать в качестве принятия текущего обслуживания со стороны пользователя. Таким образом, единственно существенным фактором является то, что некоторое сообщение уведомляет сервер выставления счетов о том, что пользователь принял договор.
Также возможно, что текущий договор сначала заключается между сервером выставления счетов и пользователем, и только после этого устанавливается контакт с сервером провайдера обслуживания.
Обслуживание может реализовываться как сеанс обслуживания, в котором участвуют более одного сервера, помимо пользовательского терминала. Один сервер может передавать к пользовательскому терминалу, например, видеосигнал, в то время как другой сервер передает одновременно дополнительную информацию, относящуюся к видеосигналу, например текст или чертежи.
Если серверы, упомянутые выше, имеют различных владельцев, то платеж может подразделяться между ними различными путями. Например, система выставления счетов может рассчитывать доли отдельных провайдеров обслуживания, когда она составляет ежемесячные счета. Другим решением является то, что сервер выставления счетов распределяет платежи следующим образом: для каждой ЗДП, полученной от пользовательского терминала, сервер выставления счетов создает, например, две новые ЗДП, которые он подписывает и запоминает в массовой памяти. Одна из этих записей платежей содержит платеж за видеосервис, а другая - за сервис передачи данных. Сумма этих платежей равна сумме денег, указанной в записи данных платежей, которая была получена от пользовательского терминала. Способ разделения этой суммы между провайдерами обслуживания является одним из параметров совместного обслуживания, которые хранятся в базе данных услуг. Если различные серверы участвуют в одном и том же сеансе обслуживания, то сервер выставления счетов может соответственно разделить любую сумму денег, полученную от пользователя, между различными записями платежей. В дополнение к возможности разделения платежей между провайдерами обслуживания путем генерирования новых ЗДП сервер выставления счетов может также непосредственно определить их долю. Так, при наличии N одновременно действующих провайдеров обслуживания сервер выставления счетов может разделить каждую принятую ЗДП на N+1 частей для получения новых записей платежей, чтобы каждый провайдер обслуживания и провайдер услуги выставления счетов получили свою долю.
Изобретение относится к способу реализации оплаты в телекоммуникационной системе. Технический результат заключается в том, что обеспечивается возможность использовать централизованную систему оплаты для выставления счетов за мультимедийное обслуживание с использованием существующих систем обслуживания. В способе и системе используют отдельный сервер для выставления счетов. Сообщение договора на обслуживание пересылается на терминал пользователю. Принятие договора пользователем пересылается на указанный сервер. Серверы выставления счетов используют для передачи записей платежей в систему выставления счетов таким образом, что пересылка записей платежей для выбранной услуги предусматривает использование по меньшей мере одного сервера выставления счетов. 2 с. и 25 з.п.ф-лы, 10 ил.
| Инструмент для изготовления заготовок под прокатку изделий типа железнодорожных колес | 1977 |
|
SU647052A1 |
| RU 94036759 A1, 27.08.1996 | |||
| US 5301234 A1, 05.04.1994 | |||
| US 5524142 A1, 04.06.1996 | |||
| US 5383113 А1, 17.04.1995 | |||
| RU 94004197 A1, 27.05.1996. | |||
