ФИНАНСОВЫЕ ТРАНЗАКЦИИ С ОПЛАТОЙ ПЕРЕДАЧИ И ПРИЕМА СООБЩЕНИЙ
FINANCIAL TRANSACTIONS WITH PAYMENT FOR MESSAGE TRANSMISSION AND RECEPTION

Предпосылки создания изобретения
1. Область техники
Настоящее изобретение в целом относится к передаче электронных сообщений, а более конкретно к защите передачи электронных сообщений, которая обеспечивает безопасность финансовых транзакций и позволяет избежать имеющих место в настоящее время трудностей, которые испытывают пользователи при передаче электронных сообщений для проведения финансовых транзакций.
2. Уровень техники
Использованию Интернета для деловых и личных контактов препятствуют опасения относительно (а) безопасности финансовых транзакций, (б) злонамеренное использование адресов электронной почты, (в) злоупотребление конфиденциальной информацией и (г) неудобства, связанные с решениями первых трех проблем.
Что касается злонамеренного использования электронной почты, решения по отсечению спама часто рассчитаны на фильтрацию, которая приводит к опасности блокировки нужного сообщения; создание "белых" и "черных" списков, которые, соответственно, пропускают или блокируют электронную почту в зависимости от источника письма; и систему предъявления претензий, например, раскрытую в патенте США № 6393465. Другой подход включает установление финансовых препятствий для рассылки спама. В патенте США № 5999967 описано требование присоединять к электронным почтовым отправлениям "электронную марку", которая позволяет получателю "затребовать от отправителя согласованную сумму в случае, если он [получатель] примет электронную почту". Альтернативно, отправитель может купить электронную марку у третьего лица, у которого получатель может впоследствии получить эту сумму. В патентах США № 6192114 и 6587550 раскрыт способ, в котором несанкционированным отправителям посылают электронный счет, который должен быть оплачен до доставки электронной почты. В патенте США № 6697462 раскрыты способы, в которых несанкционированные отправители обязаны отправить некий залог, из которого поставщики услуг вычтут штраф при уведомлении, что получателю не нужно доставленное сообщение.
Что касается злоупотребления конфиденциальной информацией, то даже желательное взаимодействие и транзакции с торговцами повышают риск последующего злоупотребления адресами электронной почты, номерами кредитных карточек или другой предоставленной информацией. Чтобы избежать распространения по Интернету номеров кредитных карт, в патенте США № 6246996 раскрыт механизм, позволяющий продавцу выставить счет покупателю через почтовую систему посредника. Счет направляется покупателю через почтовую систему посреднической службы, и когда покупатель санкционирует оплату счета, посредник может обработать эту транзакцию без передачи какой-либо информации продавцу. Альтернативно, в патенте США 6332134 для предотвращения раскрытия информации о кредитной карте торговцам предусматривается, что клиент обращается с электронным сообщением к финансовому учреждению, разрешающему перечисление платы торговцу, идентифицированному в этом сообщении финансовому учреждению. Другая попытка ограничить предоставляемую информацию раскрыта в патенте США № 6330550, в котором используется сервер профиля потребителя.
Получение нежелательной электронной почты приводит к потере времени и производительности до такой степени, что многие люди активно стремятся скрыть адреса своей электронной почты для защиты от "спама". Это сводит на нет стремление к более легкому общению с людьми и фирмами, с которыми активно ищется связь. То же самое относится к нежелательным запросам телемаркетинга. Поэтому имеется потребность в системе, которая обеспечивает надлежащее равновесие между неприкосновенностью частной жизни и потребностью в эффективном маркетинге желательных продуктов.
Проблемы, сформулированные выше, невозможно решить в рамках существующих систем передачи электронных платежей и электронной почты, в которой используются протоколы SMTP (Simple Mail Transfer Protocol - простой протокол пересылки почты) и РОР3 (Post Office Protocol - протокол почтового офиса). Соответственно, имеется потребность в новой электронной системе связи, которая обеспечит пользователю (а) больший контроль времени, которое он тратит на просмотр как ожидаемой, так и неожидаемой почты, (б) большую ценность информации, связанной с его идентификацией на рынке, и (в) большее удобство и безопасность в проведении финансовых транзакций.
Настоящее изобретение решает эти задачи путем (а) объединения системы безопасной передачи сообщений в электронный финансовый счет для каждого пользователя, который обеспечивает как посылку, так и прием денежных средств в качестве части электронной почты другой стороне и от другой стороны, использующей аналогичный электронный финансовый счет, (b) разрешения пользователю определить список сборов за получение, необходимых для получения электронной почты от определенных людей групп людей, или классов фирм, и (в) сбора, с разрешения пользователя, маркетинговой информации о закупках пользователя, сделанных с использованием этого финансового счета, так чтобы ее можно было продать специалистам по маркетингу и таким образом повысить доход пользователя путем сборов за получение. Ни один из этих трех признаков, по отдельности или в комбинации, на настоящий момент не известен.
Словарь
Следующий словарь технических терминов, неоднократно используемых в настоящем описании, призван способствовать лучшему пониманию настоящего изобретения:
Цифровая Идентификация
или ЦИ относится к законно присоединенной электронной подписи, цифровой подписи (ЦП) или электронному подтверждению идентичности, которая может быть в форме асинхронно зашифрованного, поддающегося проверке свидетельства о правомочности (СА - certificate of authority), выданного доверенным третьим лицом, например банком или почтовым отделением, которое подтверждает идентичность означенного держателя счета.
Заголовок
относится к информации, связанной с Summa-сообщением (см. определение ниже), которая обычно не просматривается получателем, но используется серверами и клиентами для обработки сообщения и проведения расчетов по счету.
Сетевой сервер
относится к программному обеспечению и оборудованию, используемому провайдером услуг для сбора и распространения информации между клиентами с Summa-счетами (см. определение ниже).
Сбор за получение
- сбор, установленный получателем Summa-сообщения (см. определение ниже), выставляемый отправителю и начисляемый получателю, как в целом или конкретно определено в списке сборов.
Получатель
относится к пользователю Summa-счета (см. определение ниже), который получает Summa-сообщение (см. определение ниже).
Отправитель
относится к пользователю, который посылает Summa-сообщение (см. определение ниже).
Провайдер
(поставщик) услуг относится к объекту, который обеспечивает Summa-счета (см. определение ниже) для множества пользователей по меньшей мере через один сетевой Summa-сервер. Как правило, провайдер услуг может быть банком или другим финансовым учреждением, провайдером Интернет-услуг или другой фирмой, предлагающей или обслуживающей кредиты, предоставляемые пользователям через Summa-счет (см. определение ниже).
Summa-счет
относится к электронному финансовому счету, который включает интегрированную электронную систему передачи сообщений или, наоборот, к электронной системе передачи сообщений, которая интегрирована в электронное управление одним или несколькими финансовыми счетами. Альтернативно, Summa-счет может состоять из электронной системы передачи сообщений, которая включает программирование и авторизацию, необходимые для кредитования или дебетования одного или нескольких финансовых счетов.
Summa-клиент
относится к программному обеспечению, установленному на машине пользователя для создания, посылки, получения и чтения Summa-сообщения (см. определение ниже), а также для обеспечения доступа к соответствующему финансовому счету (счетам) и к записям счета.
Summa-сообщение
относится к электронному сообщению, которое содержит информацию о передаче денежных средств между Summa-счетами и которое может также включать дополнительную информацию, сообщения или вложения для передачи от отправителя получателю. В дополнение к идентификации передачи денежных средств, Summa-сообщение может включать электронный текст, изображение, аудиоданные, видеоданные или телефонную связь.
Пользователь
относится к любому человеку или деловому лицу с Summa-счетом в сети. Пользователь может быть получателем или отправителем Summa-сообщения.
Именно в свете вышесказанного было задумано настоящее изобретение, а затем сведено для практического использования.
Сущность изобретения
Согласно предпочтительному варианту выполнения настоящего изобретения до проведения финансового перечисления каждый Summa-пользователь должен создать финансовый счет у своего провайдера Summa-услуг. Этот счет должен включать депозит денежных средств или кредитную линию или и то, и другое.
Посредством Summa-клиента, с помощью которого пользователь получает доступ и управление одним или несколькими Summa-счетами, пользователь определяет список сборов за получение, которые отправители должны заплатить получателю в виде компенсации за прием их Summa-сообщений. После доставки Summa-сообщения Summa-счет отправителя дебетуется на согласованную сумму, а счет получателя кредитуется на сумму сбора минус любые издержки, которые могут быть наложены провайдером услуг.
В дополнение к обеспечению процедуры, для того чтобы получатель мог устанавливать и получать сборы за получение сообщений, это изобретение также обеспечивает безопасный способ перечисления других денежных средств между любыми двумя Summa-счетами. Это облегчает покупки по Интернету, микроплатежи, электронное выставление счета и оплату счета, а также любое другое перечисление денежных средств, которое может потребоваться пользователю. Поскольку эта оплата включает перечисление денежных средств непосредственно между Summa-счетами, отсутствует необходимость в передаче по Интернету номера кредитной карты или номера счета.
Кроме того, с разрешения пользователей провайдеры услуг могут также отслеживать виды сделанных покупок и добавлять их в маркетинговую базу данных, хранимую для каждого пользователя. Сбор и создание этих данных позволяют повысить ценность маркетингового идентификатора каждого пользователя и таким образом повысить доход, который пользователи могут получать от сборов за получение сообщений.
Этот процесс дает следующие преимущества: (1) "рассылка спама" в виде нецелевых коммерческих предложений или частных сообщений устраняется, поскольку пользователи получают только те сообщения, которые они согласились принимать согласно их списку сборов, (2) получатели имеют доход за потраченное время и маркетинговое имя, (3) провайдеры Summa-услуг получают дополнительную сборы за услуги и доход от рекламы, (4) торговые предприятия могут легче получить списки людей, заинтересованных в получении их коммерческих предложений посредством Summa-сообщения, и (5) электронные финансовые транзакции могут осуществляться безопасно с лучшим отслеживанием и проверкой.
Таким образом, главной особенностью настоящего изобретения является создание дружественной к пользователю системы финансовых транзакций с использованием Интернета, которая может рассчитывать на доверие ее пользователей.
Другой особенностью настоящего изобретения является создание такой системы транзакций, которая предоставляет пользователю возможность лучше управлять временем, которое он тратит на просмотр как ожидаемых, так и неожидаемых сообщений, обеспечивает большую ценность распространяемой информации о его маркетинговом имени и предоставляет больше удобств и большую безопасность при совершении финансовых транзакций.
Еще одной особенностью настоящего изобретения является создание системы транзакций, которая сочетает безопасную систему передачи сообщений с электронным финансовым счетом для каждого пользователя, что позволяет как посылать, так и получать денежные средства в составе электронной почты по отношению к другой стороне, использующей аналогичный Summa-счет, позволяет пользователю определить список сборов за получение, требуемых за прием электронной почты от определенных людей, групп людей или классов фирм, и собирает маркетинговую информацию о закупках пользователя с использованием этого финансового счета с разрешения пользователя, чтобы эту информацию можно было продать специалистам по маркетингу и таким образом увеличить доход, который пользователь получает за счет сборов за получение сообщений.
Остальные и дополнительные признаки, преимущества и выгоды от использования изобретения станут понятными из последующего его описания со ссылками на сопровождающие чертежи. Должно быть понятно, что предыдущее общее описание и последующее подробное описание даются только с целью примера и иллюстрации, но не ограничивают изобретения. Сопровождающие чертежи, которые составляют часть настоящего изобретения, иллюстрируют один из вариантов выполнения настоящего изобретения и вместе с описанием служат для пояснения принципов изобретения в общем виде. В описании одинаковые позиции относятся к одинаковым элементам.
В этом месте полезно рассмотреть некоторые примеры известных запатентованных систем, а затем проанализировать преимущества, достигнутые в настоящем изобретении и отсутствующие в известных технических решениях.
В патенте США № 5999967 раскрыт способ фильтрации электронной почты, где используется электронное почтовое приложение, которое представляет собой электронную марку, имеющую "собственную" или договорную стоимость. Эта методика описана на примере достижения "более эффективной идентификации и обработки "макулатурной" электронной почты. Его главной целью является создание экономического барьера (посредством электронной марки) для рассылки спама. С этой целью достаточно, чтобы электронная марка была простым векселем, который должен быть предоставлен человеку, санкционирующему оплату. Альтернативно, этот патент предлагает, чтобы пользователь мог купить жетоны, которые затем можно выкупить и превратить в договорную валюту посредством третьего лица, провайдера жетонов. Другими словами, патент не предлагает улучшенного способа перевода денежных средств или получения оплаты за чье-либо время или маркетинговое имя. В отличие от этого в настоящем изобретении не используется ценное электронное почтовое приложение, а вместо этого, не полагаясь на обещание оплаты и безадресную задачу по сбору денежных средств, обеспечивается механизм для инициирования и завершения фактической транзакции или перевода денежных средств с одного финансового счета на другой. Это происходит, являясь неотъемлемой частью доставки Summa-сообщения (то есть, финансовой транзакции плюс сообщения). Следует отметить, что патент США № 5999967 не предусматривает какого-либо условия для использования простых векселей или жетонов с любой другой целью, нежели их однократное использование в качестве электронного почтового приложения. Фактически заявляется, что необходимо предотвратить повторное использование как жетона, так и электронного приложения. Это подчеркивает, что согласно патенту США № 5999967 электронная марка в качестве "индикатора стоимости" не является валютой, которая может использоваться для новых закупок, оплаты векселей или даже для оплаты электронных почтовых расходов.
В патентах США № 6192114 и 6587550 раскрыт способ фильтрации электронной почты, в котором несанкционированным отправителям (то есть людям, не входящим в список разрешенных адресов, или белый список) посылают электронный счет, который нужно оплатить до доставки электронной почты. Этот способ также обеспечивает, что отправители (наиболее вероятно - большие коммерческие рекламодатели) могут заранее санкционировать оплату издержек по доставке путем предоставления провайдеру услуг счета для оплаты или номера кредитной карты. Как и в случае патента США № 5999967, в патентах США № 6192114 и 6587550 не выявлены преимущества создания финансового счета, на котором можно депонировать денежные средства за счет сборов за получение и изымать их для покупок, оплаты счетов или оплаты сборов по приему сообщений для другого человека. Кроме того, в патентах США № 6192114 и 6587550 не выявлены преимущества, обусловленные разрешением пользователям создавать список различных сборов за получение почты в зависимости от конкретного отправителя или более широкого коммерческого класса. Вместо этого требуется, чтобы пользователи имели список разрешенных отправителей и стремились выставить счет тем отправителям, которые не находятся в этом списке. Напротив, настоящее изобретение упрощает отношения между всеми пользователями тем, что любой человек с Summa-счетом, даже люди, не известные пользователю, автоматически заранее имеют разрешение послать сообщения, причем для сбора издержек по доставке не требуется никакого процесса выставления счетов. Кроме того, в патентах США № 6192114 и 6587550 не предусмотрен механизм для того, чтобы пользователи имели счета у различных провайдеров услуг, но требует, чтобы все счета оплачивались в единственной компании, которая обеспечивает эту услугу. Другое замечание относится к тому, что эти патенты требуют, чтобы приемный компьютер пользователя был запрограммирован на обнаружение признака источника электронной почты и был способен сравнить источник со списком разрешенных отправителей. Однако, как сказано выше, такая система не может предотвратить появление ложных заголовков. Не имеется никаких средств для определения того, что признак подлинный. В отличие от этого система согласно настоящему изобретению не требует от приемного компьютера пользователя поиска источника электронной почты, поскольку сама Summa-сеть спроектирована так, чтобы аутентифицировать идентичность пользователей.
Краткое описание чертежей
Вышеуказанные аспекты и другие особенности настоящего изобретения поясняются в последующем описании со ссылками на сопровождающие чертежи, где:
на фиг.1 показана блок-схема, иллюстрирующая отношения между Summa-пользователями, сетевыми серверами и базами данных, ассоциированными с каждым пользовательским Summa-счетом, в рамках настоящего изобретения;
на фиг.2 представлена таблица, иллюстрирующая пример типов информации, хранимой в базе данных и связанной с учетной записью пользователя, в рамках настоящего изобретения;
на фиг.3 показана упрощенная блок-схема процедуры, используемой пользователем для составления списка сборов, требуемых с тех, кто желает послать сообщения пользователю, в рамках настоящего изобретения;
на фиг.4 показана блок-схема, представляющая пример процедуры, используемой сетевым сервером, для принятия решения по обработке Summa-сообщения, посланного от одного пользователя, обслуживаемого одним сервером, другому пользователю, обслуживаемому другим сервером, в рамках настоящего изобретения;
на фиг.5 показана блок-схема, аналогичная изображенной на фиг.1, но с финансовыми счетами, постоянно находящимися вне базы данных Summa-сети, причем иллюстрируется, как может быть предоставлена возможность совершить передачу денежных средств с аутентификацией и доступом к электронному заказу на перевод денежных средств на финансовый счет пользователя или с такого счета, хранимого во внешнем финансовом учреждении, в рамках настоящего изобретения.
Подробное описание предпочтительных вариантов выполнения настоящего изобретения
Обратимся вначале к фиг.1, где иллюстрируется уникальная методика изобретения на примере реализации и управления при помощи компьютерной сети, где сетевые серверы 32 и 38 обмениваются Summa-сообщениями через электронное соединение 36. Хотя настоящее изобретение будет описано на примере вариантов его выполнения, изображенных на чертежах, должно быть понятно, что оно может быть реализовано во многих альтернативных формах или вариантах выполнения. В практике изобретения могут использоваться любые подходящие размеры, формы или типы элементов или материалов.
Как показано на фиг.1, каждый отдельный пользователь 20, 22, 24, 26 и 30 имеет доступ по меньшей мере к одному Summa-клиенту. Например, пользователь 20 имеет доступ к Summa-клиенту 21. Пользователи 24 и 26 имеют доступ к коллективному компьютеру, который выполняет роль Summa-клиента 25 и имеет параметры настройки, позволяющие посылать и извлекать Summa-сообщения для трех адресов со счетами: одного для пользователя 24, user24@snl, одного для пользователя 26, user26@snl, и одного, который находится в совместном пользовании у пользователя 24 и пользователя 26, joint@snl. Посредством соответствующих Summa-клиентов пользователи общаются с назначенным сетевым сервером 32 или 38. Например, показано, что Summa-клиент 21 связан с сетевым сервером 32 через Интернет-подключение 28. Если пользователь 20 посылает сообщение, адресованное пользователю 22, то сетевой сервер 32 будет хранить сообщение, полученное от Summa-клиента 21, в памяти до тех пор, пока оно не будет извлечено Summa-клиентом 23 пользователя 22.
Обмен сообщениями между пользователями, которые обслуживаются различными серверами, происходит лишь немного более сложным образом. Например, предположим, что пользователь 24 желает передать сообщение пользователю 30, который обслуживается сервером 38. Адрес получателя, т.е. пользователя 30, будет распознан сервером 32 как относящийся к пользователю, связанному с сетевым сервером 38, и передан в сетевой сервер 38 через сетевое подключение 36. Маршрутизирующее программное обеспечение сервера 38 автоматически проанализирует адрес получателя и распознает, что сообщение нужно доставить пользователю 30. Если определено, что сообщение нужно доставить, то оно сохраняется в файле, доступном для извлечения через Summa-клиента 31 для этого пользователя.
Предыдущее описание хорошо известно специалистам в области передачи электронных сообщений. Однако в этом изобретении к обычной схеме добавлен еще один элемент. А именно, серверы Summa-сети обслуживают также финансовые счета и базы 34 и 40 данных для каждого пользователя, которые включают список сборов, которые будут дебетованы со счетов отправителей и кредитованы каждому пользователю после доставки, а также средства для дебетования или кредитования финансовых счетов после доставки Summa-сообщения.
Общий пример списка сборов и профиля потребителя для пользователя 20, введенный и сохраненный в базе 34 данных, показан на фиг.2. На этом чертеже каждый столбец соответствует отдельной категории информации. Для примера положим, что каждый столбец 80-88 представляет собой дискретный файл. Специалистам в данной области техники очевидны и другие конфигурации. Как показано на фиг.2, первая строка каждого файла - это метка для типа информации, хранимой в данном файле, а вторая строка - уникальный идентификатор для пользователя 20, обозначенный в этом примере просто как "User20 ID" и используемый для идентификации, связи и доступа к соответствующим данным для пользователя 20 для нескольких файлов.
В этом примере файл 80 данных с общей информацией представляет собой область в памяти, в которой хранятся текущие суммы кредитов, дебетов и платы за обслуживание для пользователя 20, а также другая стандартная информация, например пароли и значения по умолчанию для сборов за получение. Файл 82 списка личных контактов - это список пользователей, которые известны пользователю 20 и для которых пользователь 20 желает установить сбор за получение, который отличается от значения сборов за получение по умолчанию. Любой адрес, идентифицированный как имеющий сбор за получение, равный нулю, помечается как относящийся списку разрешенных адресов. Файл 84 списка профиля потребителя содержит данные о профиле потребителя для пользователя 20, например предпочтения и антипатии, предпочтительные продукты, недавние покупки и демографическая информация. Файл 86 списка коммерческой оплаты содержит список сборов, который определен пользователем 20 и который должен быть применен к различным типам коммерческих счетов. Файл 88 с "отказным списком" - это список адресов пользователей, почтовые отправления которых пользователь 20 хочет возвратить автоматически или отказаться от них, независимо от максимального значения сборов за получение, которое они намерены заплатить.
Во время создания нового Summa-счета или в какое-либо другое время, когда провайдер услуг или клиент желает изменить параметры настройки счета клиента, владелец Summa-адреса заполняет или корректирует электронную форму, которая задает базовый список сборов. На фиг.3 показана блок-схема, демонстрирующая основные шаги процедуры, с помощью которой пользователь может ввести информацию, хранимую в базе данных, как показано на фиг.2. Порядок этих шагов не является критическим. Специалисты в области программирования легко обнаружат множество возможных модификаций этой процедуры. Основные шаги этой подпрограммы устанавливают значения по умолчанию для сборов за получение для пользователя, обеспечивают ввод определенных сборов для определенных категорий коммерческих сообщений и ввод любой дополнительной информации, которая может оказаться полезной в профиле потребителя. Дополнительными модификациями базовых требований является идентификация людей, которые должны платить сбор за получение, отличный от значений по умолчанию для сборов за получение, и адреса, с которых прием почтовых отправлений запрещен. Определенные адреса в этих списках можно ввести индивидуально или загрузить в виде файлов записной книжки, обычно используемых в программах электронной почты. Шаги, показанные на фиг.2, не являются исчерпывающими для всех типов данных, которые могут быть собраны и сохранены в базе данных и которые полезны для управления обменом сборами и кредитами обычным способом, охватываемым данным изобретением.
На фиг.4 показана последовательность операций, где выделены основные шаги серверной процедуры, которая исследует поступившее получателю Summa-сообщение и либо (1) накладывает соответствующие сборы на счет отправителя, кредитует получателя и доставляет Summa-сообщение получателю, либо (2) возвращает сообщение отправителю с соответствующим сообщением, в котором указывается причина отказа. Последнее может произойти, если отправитель будет у получателя в списке отправителей, сообщения которых необходимо возвращать всегда, или если отправитель не имеет Summa-счета или не имеет на счете достаточных средств. Сообщение будет возвращено также и в случае, если сбор за получение у получателя превышает максимальную сумму, которую отправитель указал в сообщении как сумму, которую он согласен заплатить в качестве сбора за получение. Например, если пользователь установил сбор в сумме 10 центов за получение сообщений из финансовых информационных бюллетеней, но отправитель такого коммерческого сообщения послал сообщение с уведомлением, что он заплатит сбор за получение только в сумме до семи центов, отправитель получит назад уведомление, в котором сказано, что сообщение не доставлено, с указанием соответствующего сбора, который отправитель должен согласиться заплатить прежде, чем сообщение можно будет доставить. Посредством такого способа отправители коммерческих распространяемых сообщений могут с большой точностью управлять своими затратами, а также определять, какой части Summa-списка они лишаются, если устанавливают максимальное значение сбора слишком низким. В типичном варианте выполнения настоящего изобретения, если максимальное значение сбора, которое отправитель желает заплатить, превышает значение сбора за получение у получателя, из счета отправителя вычитается только фактический сбор за получение.
Поскольку настоящее изобретение обеспечивает механизм совершения финансовых транзакций и кредитования, провайдеры услуг могут пожелать взыскать плату за обработку, а федеральные, государственные и местные органы власти могут пожелать обложить эти транзакции различными налогами. Это включает разбиение денежных средств, особенность, которая также может принести пользу фирмам, например, разбивая платежи между отчислениями продавца и торговца, заполняющего заказ. В любом случае, если собранные суммы денег требуется - по закону, контракту или другому соглашению - разбить между множеством счетов, довольно легко просто предусмотреть программу, которая вычитает требуемое значение у соответствующей стороны при каждой транзакции и немедленно вносит это количество (которое может быть, например, налогом, платой или долей прибыли) на соответствующий счет, согласно действующему закону, контракту или по желанию пользователя. В зависимости от требований копия оригинального сообщения может быть послана каждой стороне, получающей часть оплаты, или альтернативное сообщение может быть создано автоматически, чтобы удовлетворить потребности учета для каждой принимающей стороны. Такие сообщения, если они имеются, по количеству не превышают отслеживаемое количество или количество доставочных адресов. Процесс добавления шага дополнительной программы для наложения и отслеживания этих дополнительных оплат очевиден для специалистов в данной области техники.
Шаги, показанные на фиг.4, не являются исчерпывающими для всех возможных вариантов процедуры, которая управляет доставкой Summa-сообщения. Напротив, эта последовательность операций просто демонстрирует типичный пример реализации в рамках настоящего изобретения. Множество вариантов этого подхода очевидны для специалистов в данной области техники.
В типичном варианте выполнения настоящего изобретения безопасная доставка сообщения может потребовать от сервера отправителя сигнала "запрос на передачу" (RTS - Request to send) и потребовать от сервера получателя разрешения на передачу (PTS - Permission to send). Этот шаг предусматривает проверку сборов и личности до передачи Summa-сообщения. В качестве дополнительной гарантии безопасности RTS может включать хэш-сумму для сообщения, которая будет выслана после приема PTS. Это позволит серверу получателя проверить, что полученное сообщение соответствует тому, для которого был выдан PTS. Как только PTS получен, сервер отправителя помещает переводимые денежные средства на временный условный счет на случай, если сообщение не будет успешно доставлено. Как только подтверждение доставки из сервера получателя получено, условные денежные средства будут переведены принимающей стороне.
В вышеуказанном примере, перевод денежных средств завершается только после подтверждения успешной доставки сообщения. Альтернативно, при других обстоятельствах может быть желательно придержать сообщение, пока не будет подтверждена окончательная передача денежных средств. Какая именно альтернатива используется, может определяться типом сообщения или выбранными опциями пользователей. Кроме того, очень просто записать, наряду с сообщением, идентифицирующую информацию, например хэш-информацию для сообщения, дату и время, в которое Summa-сообщение было послано изначально, и дату и время, в которое они были доставлены. Эта информация может быть полезной во многих обстоятельствах в качестве официальной отметки даты и времени, которая может быть подтверждена путем сравнения копии записи, которая хранится у пользователя, с записью, которая хранится у провайдера услуг, являющегося третьим лицом.
Это движение денежных средств от пользователей, которые обслуживаются одним Summa-провайдером услуг, к пользователям, которые обслуживаются другим провайдером услуг, приведет к непрерывному смещению значений нетто-активов, хранимых на счетах пользователя у каждого провайдера услуг. В предпочтительном варианте выполнения настоящего изобретения, в котором провайдеры услуг являются финансовыми учреждениями, балансы между провайдерами услуг можно отрегулировать посредством АСН-подобных операций (операций через автоматизированную клиринговую палату), которые происходят в фиксированные временные интервалы, например в конце дня. Как показано на фиг.1, в типичном варианте выполнения настоящего изобретения этот процесс может быть автоматизирован с использованием одного или нескольких центральных серверов клиринговой палаты 50, которые контролируют, вычисляют и обрабатывают периодические переводы, необходимые для помещения нетто-балансов для каждого Summa-провайдера услуг в надлежащем порядке. Как правило, центральная клиринговая палата 50 обслуживает также список всех сетевых адресов сервера для всех Summa-провайдеров услуг, а каждая транзакция начинается с запроса к клиринговой палате на поиск или подтверждение адреса провайдера услуг для получателя. Аналогично, приемные серверы могут проверить через клиринговую палату целостность передающих серверов. Таким образом, любая попытка инициировать Summa-сообщение и транзакцию через несанкционированный сервер будет автоматически подавлена. Специалисты в данной области техники легко найдут другие способы обеспечения общей безопасности и сбора данных, которыми можно было бы легко управлять посредством серверов клиринговой палаты.
В предпочтительном варианте выполнения настоящего изобретения, показанном на фиг.1, система передачи сообщений объединена с системой электронного перевода средств и системой учета финансового учреждения. Альтернативно, как показано на фиг.5, Summa-транзакцию совершают с использованием внешнего электронного компонента 42 для заказа перевода денежных средств. Например, если пользователь 20 имеет счет в банке 44, который обеспечивает доступ к Интернет-банку, пользователь 20 может передать свой пользовательский логин (имя пользователя) и пароль своему Summa-клиенту 21, который затем сможет воспользоваться пользовательским сервером 32 для доступа к денежным средствам и их перевода через интерфейс 42 Интернет-банка для выбранного счета в банке. Как правило, учетные записи этих передач все еще хранятся в базе данных 34 Summa-счета. В таком случае, если система передачи Summa-сообщений фактически не интегрирована в системы финансовых счетов банка, можно предоставить Summa-системе достаточный доступ и управление финансовым счетом, чтобы она смогла совершить перевод денежных средств, необходимых для реализации целей настоящего изобретения.
Альтернативно или дополнительно, пользователь может подписать соглашение, позволяющее провайдеру услуг, касающихся Summa-сообщений, создать перевод посредством автоматизированной клиринговой палаты (АСН) на любой из существующих пользовательских счетов. В этом альтернативном варианте выполнения настоящего изобретения средство 42 передачи денежных средств представляет собой любое средство системы электронных платежей, включая, но этим не ограничиваясь, АСН систему, систему обработки кредитных карт, отдельно или в комбинации с клиринговой палатой 50, через которую серверы Summa-сети могут координировать передачу денежных средств между финансовыми счетами. Например, в случае, когда АСН транзакция задействована, через пользовательского Summa-клиента выдается номер маршрутизации выбранного пользовательского счета. Так как АСН транзакции типично обрабатываются с использованием пакетных файлов, отсутствует необходимость или целесообразность создавать заказ АСН перевода для каждого дискретного Summa-сообщения. Например, предположим, что в течение одного дня пользователь 20 произвел десять Summa-платежей и получил тринадцать Summa-платежей при чистой прибыли 5,31 доллара. В этом случае сетевой сервер сохраняет в базе 42 данных ежедневную трансфертную сумму, представляющую собой сумму кредитов и дебетов для каждого Summa-счета. Вместо того чтобы провести (23) АСН транзакции для пользователя 22, сетевой сервер заказывает в конце дня одну АСН транзакцию с кредитованием 5,31 доллара. Этот процесс не только уменьшает плату за АСН транзакции, но и уменьшает количество финансовых операций, которые должны происходить в банковском утверждении. Поскольку кредитуются и дебетуются суммарные денежные средства, включая плату за услуги, баланс должен подводиться в конце каждого дня; эта система еще более упрощается путем направления всей суммы кредита на конец дня на Summa-счета в центральном финансовом счете, принадлежащем провайдеру услуг, и направления всей суммы дебета на конец дня на Summa-счета того же самого центрального финансового счета. В этом альтернативном варианте выполнения настоящего изобретения состояние пользовательского баланса в банке покажет только одну АСН транзакцию в течение каждого дня, представляющую итоговые кредиты или дебеты Summa-счета в течение этого дня. Однако к деталям каждой транзакции можно получить доступ через базу данных Summa-счета, которая в случае вышеуказанного примера покажет детали десяти исходящих Summa-платежей Пользователя 20 и тринадцати входящих Summa-платежей. Альтернативно, вместо того чтобы производить ежедневное подведение баланса, провайдер услуг может подождать, чтобы подвести баланс для каждого пользовательского счета только тогда, когда итоговый кредит или дебет превысят некоторую минимальную сумму, например 20 долларов, которая достаточна для покрытия расходов на АСН перевод. Аналогичный процесс может использоваться для доступа к кредитной линии с использованием, например, номера кредитной карты.
В другом варианте выполнения настоящего изобретения может произойти смещение итогового баланса между счетами отдельного провайдера услуг, который владеет финансовым счетом в нескольких финансовых учреждениях 44 и 46, как показано на фиг.5. Для уменьшения транзакций между учреждениями 44 и 46 пользователи могут быть вынуждены управлять собственными финансовыми счетами с помощью их Summa-счета в учреждениях 44 или 46; по меньшей мере те, кто получает и выплачивает небольшие суммы. В этой альтернативе, пусть пользователь 22 выбрал банк 44 и банк 46 пользователя 30, а оба Summa-счета управляются операционными сетевыми серверами 32 и 38 одного провайдера услуг. При соответствующем разрешении от Summa-пользователей и посредством счетов провайдера услуг в каждом банке платежи между 22 и 30 могут быть совершены без какого-либо перевода денежных средств между банками. Вместо этого денежные средства, выплаченные пользователем 22, переходят на счет провайдера услуг в учреждении 44, а со счета провайдера услуг в учреждении 46 - на счет пользователя 30. Таким образом, при сокращении затрат два внутрибанковских трансферта заменяются одним межбанковским трансфертом. В этом случае суммарные депозиты в каждом банке остаются незатронутыми, но затрагиваются счета провайдеров услуг в каждом банке. Это легко осуществить периодическими АСН трансфертами между собственными счетами провайдера услуг в учреждениях 44 и 46, что может потребоваться нечасто. Этот процесс можно вновь координировать клиринговой Summa-палатой 50, которая неявно включена в средство 42 системы электронных платежей.
В нескольких из сценариев урегулирования платежей, описанных выше, пользователи могут быть вынуждены уполномочить провайдера услуг объединить расходы и приходы на условных счетах. Условные счета существуют в виде файлов, хранящихся в сетевых серверах или серверах 50 клиринговой палаты. В комбинации с записью текущего баланса для каждого счета сетевой сервер может использовать условный счет для проверки достаточности денежных средств и предотвращения перерасхода. Как правило, условный счет может состоять из двух частей: транзакции на рассмотрении и завершенные транзакции. Транзакции на рассмотрении включают те денежные средства, который должны быть выплачены после доставки Summa-сообщения, которое находится в очереди на доставку, но, возможно, еще не доставлено, поскольку получатель еще не загружал свои Summa-сообщения. Денежные средства, разрешенные для оплаты рассматриваемых транзакций, хранятся на счете условного депонирования, поскольку они не доступны ни для отправителя, ни для получателя. Если (а) доставка отклонена, (б) отправитель отменил доставку или (в) отправитель выбрал опцию указания срока доставки, по истечении которой попытки доставки прекращаются, то условные денежные средства, ассоциированные с этим сообщением, будут возвращены на счет отправителя. В противном случае, как только сетевой сервер получает подтверждение о доставке, платеж между отправителем и получателем завершится путем записи перемещения со счета на рассмотрении, в результате чего подтверждается дебет на счете условного депонирования отправителя, и записи подтвержденного кредита на счет получателя. Объединяя итоговый дневной баланс с подтвержденными кредитами текущего дня и вычитая как суммы на рассмотрении, так и подтвержденные дебеты, сетевой сервер может предоставить Summa-пользователю оперативный баланс денежных средств. Как описано выше, пакетные файлы с итогами за день могут использоваться для установки итоговых депозитов, имеющихся у финансовых учреждений или провайдеров услуг. В этом примере, расчет по итогам дня может включать совокупные подтвержденные дебеты и подтвержденные кредиты, содержащиеся на условных счетах. Любые транзакции на рассмотрении остаются на счете условного депонирования до доставки, отмены или отказа от Summa-сообщения.
Другой важной особенностью настоящего изобретения является то, что с разрешения пользователей провайдеры услуг могут также проследить виды сделанных закупок и добавить их в маркетинговую базу данных, хранящуюся для каждого пользователя. Дополнительную маркетинговую информацию можно собрать путем опроса пользователей. Демографические данные, информация о покупках и данные по опросу могут храниться в сетевом сервере или передаваться в центральную клиринговую палату или в центр сбора данных, в котором хранятся совокупные маркетинговые данные 50. Сбор этих данных и приведение их в доступную форму повышает стоимость маркетингового имени каждого пользователя и таким образом повышает доход, который пользователи смогут получить за счет сборов за получение.
Например, обычно после того, как потребитель купил продукт, он часто будет получать дополнительные предложения на покупку продуктов от этого продавца. Кроме того, информация о контактах с ним и маркетинговый профиль могут быть проданы другим специалистам по маркетингу, к финансовой выгоде продавца, но не потребителя. В отличие от этой ситуации, несмотря на то, что Summa-закупки также приводят к пометке потребителя в качестве "перспективного", финансовая выгода от расширения маркетингового имени, связанного с покупкой, относится и к потребителю, который получит затребованный им сбор за получение для любых дополнительных маркетинговых предложений, доставляемых посредством Summa-сообщений. Для повышения стоимости пользовательского Summa-счета использование маркетинговых данных может быть ограничено предложениями, сделанными через Summa-сообщения. Альтернативно, провайдер услуг может действовать в качестве брокера по продаже маркетинговой информации и кредитовать каждого Summa-пользователя оплатой каждый раз, когда специалист по маркетингу купит данные, включающие почтовый адрес или номер телефона, относящиеся к потребителю. Как только маркетинговые данные собраны в электронную базу данных, очень просто позволить специалистам по маркетингу выбирать списки перспективных клиентов, вводя критерии отбора в программу, которая извлекает желательный список перспективных клиентов. Такой поиск данных является распространенной практикой, известной специалистам в данной области техники, и не нуждается в дальнейшей деталировке. Кроме того, специалисты в области сетевого дизайна немедленно поймут, что клиринговая палата и централизованная база данных для маркетинговой информации может быть как отдельной, так и объединенной без ухудшения функциональных возможностей описанной системы.
Должно быть понятно, что предыдущее описание и последующие подробные описания даны для примера и пояснения, но не ограничивают объема изобретения. На основе общего способа связи финансовых счетов и счетов передачи сообщений, установления сборов за получение и прослеживания кредитов и дебетов специалисты в области программирования вычислительных сетей, программирования баз данных и программирования электронной почты смогут найти большое количество способов осуществления этого процесса.
Развитие базового изобретения
Сущность настоящего изобретения заключается в связывании финансовых счетов через сетевые серверы, при этом финансовыми счетами управляют посредством безопасной электронной службы передачи сообщений, которая позволяет пользователям переводить денежные средства и устанавливать сборы за получение сообщений. Как только будет предоставлен этот механизм, специалистам в данной области техники станут очевидны дополнительные модификации, полезные для специфических приложений. Многие из этих дополнительных признаков могут быть осуществлены с помощью заголовков, входящих в Summa-сообщения и облегчающих этот процесс или обеспечивающих дополнительные функции. С использованием модификаций, например, описанных ниже, можно адаптировать фактически любой бизнес или обслуживание счетов, производимое посредством традиционных документов, и сделать их более эффективными, при этом обеспечивая пользователям больший контроль над их контактами и финансовыми операциями.
Во-первых, как описано выше, заголовок может включать поле, идентифицирующее максимальный сбор, который отправитель желает оплатить в виде сбора за получение сообщения. Если максимальное значение сбора, например десять центов, и плата получателю за доставку сообщений в этой коммерческой категории составляет пять центов, только пять центов снимается со счета отправителя и начисляется получателю. С другой стороны, если сбор получателю за получение сообщения составляет двадцать центов, то сообщение не доставляется, а отправитель уведомляется о более высокой плате за доставку.
Во-вторых, наиболее удобно было бы, если бы заголовок включал идентификацию коммерческой категории, в которую должно классифицироваться Summa-сообщение отправителя. В соответствии с контрактными соглашениями пользователи (как получатели, так и отправители) соглашаются давать информацию, используемую для точной классификации коммерческих предложений, и будут связаны решениями, принятыми этой системой классификации.
В-третьих, элемент заголовка может идентифицировать сумму, которая будет взыскана с получателя, если он решит ответить на сообщение, которое только что принял. Например, в коммерческих приложениях получатель может быть уведомлен, что с него не будет взыскан сбор, если он ответит отправителю с запросом на получение дополнительной информации. Альтернативно, отправитель может включить сбор за ответ в покупную цену продукта, предлагаемого получателю. Таким образом, обмен двумя Summa-сообщениями (предложение и согласие в ответе) может быть использован для совершения финансовой транзакции. Сбор за ответ может отличаться от обычного сбора за получение сообщения и может вернуться к обычному сбору за получение после заданного промежутка времени.
В-четвертых, заголовок может включать дополнительное поле, идентифицирующее полную сумму кредитного трансферта, которая должна быть полностью переведена на Summa-счет получателя. Если такое поле назначено, эта полная сумма кредитного трансферта может быть переведена, даже если сбор за получение у получателя меньше, чем заданная полная сумма кредитного трансферта. Этим способом отправитель может перевести денежные средства любому пользователю Summa-счета для оплаты счета, покупки продукта, возврата денежных средств, посылки денежного подарка или с любой другой целью, включающей перевод денежных средств.
В-пятых, заголовок может включать информацию, идентифицирующую типы сообщений, которые должны быть отображены или обработаны определенными способами. В этом примере сообщение, отмеченное как счет, может иметь такую структуру, что номера элементов, на которые выписан счет, их описание, количество, сбор за единицу и общие сборы могут быть автоматически выявлены приемным программным обеспечением получателя. Для этих целей наиболее легко приспособить языки форматирования XML и XHTML. Summa-клиент распознает заголовок счета и представляет сообщение пользователю в качестве счета с опциями (1) оплатить сбор полностью, санкционируя перевод полной суммы кредита, равный запрашиваемому количеству, или (2) выплатить часть суммы по счету, или (3) ответить сообщением, оспаривающим счет. При использовании информации заголовка в первоначальном сообщении ответное сообщение может автоматически включать номер счета и другую информацию в стандартном формате, который может автоматически интерпретироваться программным обеспечением отправителя по обработке счета для надлежащей корректировки счета. Аналогично, заголовок для типа контрактного документа можно отобразить с кнопкой "подпись и отсылка", предлагающей получателю подписать документ в цифровой форме с цифровой идентификацией и возвратить подписанный документ отправителю. Этим способом можно обрабатывать множество других типов документов, включая заказы, электронные таблицы, социологические исследования, обзоры или опросы, разбитые на страницы электронные книги, анкеты-заявления, налоговые формы, документы, которые полностью или частично представляют собой аудио- или видеофайлы или исполнимые коды, причем можно обрабатывать любое количество типов документов и форм, которые обычно используются в деловых, правительственных, некоммерческих или частных транзакциях.
В-шестых, заголовок можно использовать просто для информирования сетевых серверов о том, что отправитель просит уведомить о сборе за получение для намеченного получателя. Это сообщение "запрос о сборе" не доставляется потенциальному получателю, но просто используется для генерации автоматического ответа подпрограммой Summa-доставки, обеспечивающей уведомление о соответствующем сборе у получателя, даже если этот сбор равен нулю. Провайдер услуг может взимать плату за такой запрос.
В-седьмых, дополнительные признаки можно использовать также в каждой пользовательской базе данных (фиг.2), обеспечивая дополнительный контроль за тем, сколько желательно коммерческих сообщений, сколько квитанций о приходе, и "проталкивание" коммерческих сообщений тогда, когда они необходимы больше всего. Например, пользователи могут задать максимальное количество Summa-сообщений, которые они желают получить в рамках любой специфической коммерческой классификации в течение недели или месяца. Если, например, пользователь получает множество предложений по удобрениям газона в неделю и действительно интересуется ими, но просто ими перегружен, он может внести в поле списка сборов ограничение на получение таких сообщений, например не более шести в неделю. Альтернативно, сетевой сервер может быть проинструктирован помещать все такие Summa-сообщения в очередь каждую неделю и доставлять в конце недели только те шесть сообщений, за которые предложены самые высокие сборы за получение. Таким образом, коммерческим торговцам можно предложить "бороться" за потенциального клиента. Наоборот, пользователь может установить минимальную сумму, которую он желает заработать каждую неделю от сборов за получение. Если желательное количество не достигнуто в течение прошедшего часа, сетевой сервер будет проинструктирован принять сообщение от лиц, предлагающих самую высокую цену из тех, кто санкционировал оплату меньшую, чем сбор за получение, обычно запрашиваемый пользователем, но, кроме того, пожелал поставить свои сообщения в очередь до тех пор, пока получатель не пожелает принять их по предложенному курсу. Аналогично, коммерческие рекламодатели могут заранее разрешить доставку сообщений любому Summa-пользователю, который впоследствии станет соответствовать их критериям отбора. Например, специалист по маркетингу поваренных книг может заранее уполномочить послать рекламу немедленно или в заданном временном интервале, например одного дня, после того, как пользователь сделал покупку предметов для готовки. Заранее санкционированные Summa-сообщения также облегчают возможность пользователям получить маркетинговую информацию, когда в ней имеется потребность. Например, хотя пользователи не всегда интересуются процентными ставками по закладным на недвижимость, иногда они весьма интересуются поиском лучшей процентной ставки по закладной. Обычно, чтобы воспрепятствовать получению информации о закладных, они могут установить высокий сбор за получение. Однако когда они хотят получить информацию от конкурирующих компаний, они могут снизить свой сбор за получение до более приемлемого уровня. Однако, кроме того, Summa-клиент может организовать специальный тип документа, который представляет собой "объявление об интересе" (Al - announcement of interest) или "запрос на предложения", который демонстрирует желание получать информацию, предложения или котировки на идентифицируемую тему. В одной альтернативе это объявление об интересе может транслироваться всем коммерческим Summa-пользователям, которые запрашивают доставку объявления об интересе в области своих интересов. Альтернативно, объявление об интересе может быть обработано центральным сервером, который сопоставляет запрос на объявление об интересе с заранее санкционированными сообщениями, которые коммерческие Summa-пользователи подготовили для ответа на любое подходящее объявление об интересе. Во всех этих обменах потребитель и коммерческий пользователь могут установить максимальные сборы за доставку или сборы за прием, по своему усмотрению. Конечно, провайдеры услуг также могут потребовать дополнительную оплату.
В-восьмых, настоящее изобретение облегчает использование многоуровневых маркетинговых действий. Так, компания, продающая сауны, желает, например, платить только пять центов потенциальному клиенту в так называемых "квалификационных" почтовых отправлениях, рассылаемых миллионам людей. В сообщении поясняется, что компания предлагает и обещает дополнительный кредит в 5 долларов, если получатель после прочтения этого исходного сообщения заинтересуется достаточно, чтобы нажать на приглашение "щелкнуть здесь" [click here] и изучить больший объем материалов, предоставляемых компанией. После активизации отсылочного приглашения "щелкнуть здесь" пользовательский Summa-клиент автоматически производит запрос на получение дополнительной информации, высылаемой отправителю. Тогда отправитель отвечает своим вторым Summa-сообщением, содержащим дополнительную информацию, включающую, возможно, вложенный видеоклип и обещанную полную сумму кредитного перевода в 5 долларов. Альтернативно, клиенту может быть предложено посетить специальную рекламную страницу на сайте компании, на которой отображается партия предлагаемого на рынок товара, а затем пользователю предоставляется форма для заполнения, включающая информацию о его Summa-счете, на который будет послано Summa-сообщение с кредитом в 5 долларов.
В-девятых, еще одна модификация должна позволить пользователям устанавливать сбор за получение равным отрицательному числу. Это свидетельствует об обратной оплате, а именно: получатель санкционирует оплату отправителю за каждое полученное Summa-сообщение. Это было бы полезным, например, в качестве платежного средства за каждый выпуск информационного бюллетеня. Отрицательный сбор за получение сообщения сравнивается с отрицательным значением, установленным отправителем в поле максимального сбора за получение. Если санкционированная оплата получателя не достаточна, то информационный бюллетень не доставляется. Таким образом, пользователи могут легко аннулировать подписку, заменяя отрицательное число положительным, в то время как провайдеры информации также могут быть уверены, что соберут платежи за каждый доставленный выпуск.
В-десятых, для повышения безопасности передача Summa-сообщений обычно включает множество протоколов связи, отличных от РОР3 и SMTP, которые используются стандартными почтовыми клиентами и серверами. В типичном варианте выполнения настоящего изобретения передача сообщений между Summa-клиентами и сетевыми Summa-серверами, а также между сетевыми Summa-серверами может включать шифрование, сжатие, запросы на передачу, разрешения на передачу, вызов и ответ, наличие в сообщении хэш-информации, сертификат о полномочиях, проверку идентичности и другие методики, известные специалистам по компьютерной безопасности. Эти методики могут использоваться индивидуально или в комбинации, обеспечивая, чтобы идентифицированный отправитель действительно санкционировал пересылку денежных средств, и обеспечивая конфиденциальную доставку денежных средств и сообщений намеченному получателю. В то время как специфический Summa-клиент обязан генерировать Summa-сообщения согласно заданному безопасному протоколу, Summa-клиент может также включать программное обеспечение для управления созданием, загрузкой и прочтением электронной почты с протоколом РОР3/SMTP. Эти функциональные возможности с обратной совместимостью позволяют Summa-пользователям продолжать получать электронную почту в формате РОР3 от тех людей, которые внесены в разрешающий список, но не имеют Summa-счетов, а также могут посылать SMTP сообщения этим людям с использованием своего Summa-клиента.
В-одиннадцатых, маркетинговые данные, собранные в базах 34 и 40 данных Summa-счетов, представляют собой ценный товар для поиска данных и группировки данных и позволяют выбрать данные, которые идентифицируют подмножества Summa-пользователей, наиболее желательных, с точки зрения специалистов по маркетингу, для посылки им коммерческих предложений. Согласно настоящему изобретению эти маркетинговые данные или могут быть сделаны доступными через каждый индивидуальный сетевой Summa-сервер, или они могут быть собраны в централизованную базу данных, из которой специалисты по маркетингу смогут эти данные извлечь. Способы компиляции, поиска и распределения данных в такой базе данных известны специалистам в данной области техники и не требуют дополнительного описания в настоящем документе.
В-двенадцатых, аналогично тому, как протокол HTML обеспечивает механизм запуска почтового клиента с целью посылки сообщения по заранее заданному адресу, можно разработать специальную программу web-страницы для создания гиперссылок, запускающих Summa-сообщение, которое переводит заранее заданный кредит заранее заданному пользователю. Просто нужно, чтобы как покупатель, так и продавец имели Summa-счета. Программа для Summa-гиперссылки запускает Summa-сообщение, санкционирующее оплату продавцу, вероятнее всего, включенную в информационное сообщение продавцу, в котором указан артикул купленного товара. В типичном приложении покупатель подтверждает покупку, наиболее вероятно с использованием пароля, и Summa-транзакция совершается. Если требуется адрес доставки, то он может быть взят автоматически из базы данных покупателя. Этот способ обеспечивает средство, облегчающее покупки через Интернет без потребности выдачи контактной информации и номера кредитной карты. Аналогичный способ может использоваться для системы микроплатежей. Например, для получения доступа к web-страницам, содержащим информацию о стоимости, имеется специальная гиперссылка, при активации которой отображается стоимость соответствующего этой гиперссылки товара, одновременно пользователь переходит на желаемую страницу, и санкционируется Summa-оплата нескольких требуемых центов или даже долей центов. В этом примере пользователь, например, устанавливает максимальную сумму, скажем 5 центов, которую он разрешает заплатить без необходимости подтверждения покупки паролем. Таким образом, пользователи Summa-счета могут иметь легкий доступ к веб-сайтам, требующим микроплатежей за просмотр своего содержания.
В-тринадцатых, во многих приложениях может быть полезно предоставить или затребовать цифровой идентификатор (DI - Digital Identification). Например, отправителем может быть предоставлен цифровой идентификатор с предложением о контракте или с файлом и оплатой налогов. В этом случае отправитель просто выбирает опцию присоединения к Summa-сообщению цифрового идентификатора и получатель сможет увидеть, имеет ли какое-либо сообщение цифровой идентификатор или нет. Наоборот, отправители могут затребовать цифровой идентификатор от получателей до доставки Summa-сообщения. Это аналогично посылке заказной корреспонденции или корреспонденции с уведомлением о вручении, когда получатель должен расписаться за доставку или даже предъявить юридический или корпоративный идентификатор. Для реализации этой опции отправитель Summa-сообщения может иметь право выбора, чтобы обусловить доставку предоставлением общего или специфического цифрового идентификатора. Задача доставки цифрового идентификатора может быть автоматизирована или полуавтоматизирована. Наиболее типично, когда получатель с помощью электронных средств вводит один или несколько цифровых идентификаторов в своего Summa-клиента или в свой сетевом сервер, таким образом они будут готовы к использованию в любое время. Например, отправитель может потребовать или цифровой подписи и/или подтверждения идентичности в виде определенного свидетельства о правомочности до доставки Summa-сообщения. В этом примере сообщение помещается в очередь и сетевой сервер посылает запрос о необходимости цифрового идентификатора в сетевой сервер получателя. Если получатель сконфигурировал свое оборудование так, чтобы оно автоматически выполняло все запросы на цифровой идентификатор, то сетевой сервер получателя автоматически высылает цифровой идентификатор в сетевой сервер отправителя. Если это требуется, то отправитель или сетевой сервер отправителя используют открытый ключ данной стороны для подтверждения аутентичности свидетельства о правомочности. После подтверждения идентичности получателя стоящее в очереди Summa-сообщение извлекается для доставки на обычных условиях. Альтернативно, по требованию отправителя или опции получателя цифровой идентификатор поставляется только в том случае, если получатель санкционировал доставку в каждом случае путем подтверждения вручную разрешения выдачи цифрового идентификатора нажатием на соответствующую кнопку или значок. В этом случае получатель не получает исходного Summa-сообщения непосредственно в этот момент, а получает лишь уведомление о запросе цифрового идентификатора, которое может включать имя запрашивающего. Как правило, уведомление о запросе цифрового идентификатора до доставки стоящего в очереди сообщения обрабатывается как специальный тип документа, который после отображения включает кнопки, предусматривающие легкое выполнение запроса. Однако этот запрос можно также обрабатывать как отдельное Summa-сообщение, на которое распространяется соответствующий сбор за получение.
В-четырнадцатых, можно еще больше повысить ценность собранных маркетинговых данных, и таким образом пользователи, получающие доход, могут получать сбор за получение сообщений, собирая дополнительную информацию о привычках покупателя на основе других финансовых транзакций. Например, тип данных, обычно собираемых на продажах по кредитным или дебетным картам в розничной торговле, может быть связан со всеми пользовательскими базами данных. Альтернативно, новый тип кредитной или дебетной карты, выпущенной провайдером услуг, может использоваться в качестве жетона, или интеллектуальной карты, для аутентификации Summa-транзакции в специальном терминале для операций в зоне оплаты учреждения розничной торговли. В этом примере жетон может содержать зашифрованное свидетельство о правомочности, проверяемое терминалом, который может также предусмотреть ввод пользовательского пароля. После подтверждения продажи пользователем терминал генерирует Summa-сообщение, которое оплачивает покупку и загружает список покупок пользователя в сетевой сервер. В этом примере терминал в зоне оплаты действует просто как специализированный Summa-клиент, доступный для любого пользователя, который идентифицирует себя в терминале соответствующим зашифрованным жетоном и паролем. Аналогичные жетоны могут также использоваться в качестве дополнительной меры безопасности всякий раз, когда пользователь хочет обратиться к своему Summa-счету из сетевого устройства, которое Summa-сеть распознает как не являющееся одной из "нормальных" для пользователя точек доступа. Выполнение вышеуказанных и аналогичных схем совершения финансовых транзакций способом, при котором происходит накопление ценных маркетинговых данных, очевидно специалистам в области электроники. Однако уникальность настоящего изобретения заключается в том, что накопление маркетинговых данных происходит к финансовой выгоде потребителя.
Наконец, важно отметить, что хотя эта система может быть эффективно реализована с использованием сетевых серверов и Summa-клиентов, специалистам в области программирования очевидно, что эти же общие способы могут использоваться для реализации настоящего изобретения посредством прикладного серверного программного обеспечения или сетевого сайта, таким же способом, каким сетевой сайт Hotmail обычно используется вместо программы Outlook Express для просмотра электронной почты, хранимой на сетевом сервере.
Дополнительные возможности
Настоящее изобретение открывает перспективы применения множества новых способов и моделей для ведения торговли. Например, провайдеры Интернет-услуг смогут отказаться от платы за подписку для пользователей в обмен на оплату услуг, связанных с взысканием пользователями сборов за получение или перевод денежных средств. Центры технической поддержки смогут использовать Summa-счет для взимания авансовых платежей при запросе о помощи. Компании могут установить сбор за получение для Summa-счетов своих работников и таким образом собирать деньги с посторонних, связывающихся с их работниками. Этот доход способствует возмещению стоимости средств связи для служащих и позволяет получить дополнительный доход от своих служащих.
Как очевидно специалистам в области программирования, Summa-счета можно легко запрограммировать для удовлетворения множества стандартных способов проведения деловых операций. Например, Summa-счета могут быть размножены, то есть несколько финансовых счетов могут быть связаны с одним пользовательским адресом. В этом случае пользователь может использовать одного Summa-клиента для поиска всех своих сообщений, но при посылки Summa-сообщения пользователю будет разрешено выбрать, с какого именно из множества финансовых счетов должны быть сняты денежные средства для оплаты сбора за получение или для другой оплаты. И наоборот, пользовательские адреса для нескольких пользователей, например для мужа и жены, могут быть связаны с объединенным финансовым счетом. Кроме того, систему можно легко изменить, чтобы при оплате требовать ее санкционирования двумя или более пользователями. Например, электронный Summa-инвойс можно направить непосредственно бухгалтеру компании. После проверки счета бухгалтер может разрешить оплату, но сообщение не будет послано непосредственно получателю, а вместо этого будет автоматически направлено лицу, подписывающему этот счет совместно с другими лицами, т.е. владельцу бизнеса. Summa-сообщение, включающее оплату, будет послано только после того, как владелец бизнеса санкционирует его доставку.
Поскольку все записи о Summa-счетах находятся в электронном формате, очевидно, что эту учетную информацию можно легко прочесть или импортировать в программное обеспечение по учету. Альтернативно, программное обеспечение по учету может быть встроено в Summa-клиента. После ознакомления с содержанием этого описания специалисту в области программирования будет очевидно, что любой стандарт для обработки множества счетов, действий множества подписывающих лиц, отслеживания расходов и платежей, сборов "истории" клиента и т.д. может быть реализован или скопирован при незначительных изменениях в программном обеспечении, управляющем общими или специальными Summa-счетами.
Заключение
Методики, раскрытые в настоящем изобретении, дают следующие преимущества:
- они повышают ценность "личности пользователя" и его времени и предоставляют пользователю большие возможности по управлению типом и количеством принимаемых электронных сообщений;
- они компенсируют недостатки, присущие известным техническим решениям, которые не дают никакого практического средства для регулировки количества и качества принимаемых почтовых сообщений и никакого практического способа для извлечения дохода для пользователя;
- они уменьшают желание пользователей сохранять в тайне адреса своей электронной почты из страха, что их наводнят нежелательными почтовыми сообщениями, а в результате обеспечивается более широкая информация об адресах, что облегчает соответствующее взаимодействие;
- они обеспечивают новый способ взаимодействия при финансовых операциях по компьютерной сети через систему технологических и договорных деловых отношений между пользователями и их провайдерами услуг;
- они обеспечивают более открытую структуру для коммерческой передачи почтовых сообщений и идентификации интересов клиента, взаимопонимание между фирмами и клиентами за счет устранения ситуации, при которой пользователей "изводят" нежелательными почтовыми сообщениями; и
- они обеспечивают новый источник дохода для провайдеров услуг, уменьшая стоимость их услуг, и открывают новые направления для коммерческого развития согласно моделям, используемым телефонными компаниями, банками и компаниями по обслуживанию кредитных карт.
Хотя приведенное выше описание содержит множество вариантов выполнения настоящего изобретения и конкретных примеров, они не должны рассматриваться как ограничивающие объем изобретения, а даны просто в качестве иллюстрации некоторых принципиальных путей реализации изобретения. После раскрытия этого изобретения специалистам в данной области техники будут очевидны варианты изменения описанного процесса для удовлетворения индивидуальных потребностей пользователей и провайдеров услуг. Например, Summa-клиент может быть интегрирован в сотовый телефон или другое сетевое электронное устройство. Аналогично, сбор за получение может быть применен к приему телефонных звонков и другого вида электронных сообщений.
Таким образом, все вышеизложенное следует рассматривать как иллюстрацию принципов настоящего изобретения, но ни в коем случае не следует считать ее исчерпывающей. Специалистам в данной области техники очевидны многочисленные модификации и изменения. Поэтому не следует ограничивать настоящее изобретение точной структурой и процессом, рассмотренными и описанными выше, и, соответственно, все модификации и эквиваленты, в которых используется доступный пользователю выключатель, ограничивающий доступ компьютера к периферийным устройствам, находятся в пределах объема настоящего изобретения.