финансовые транзакции с оплатой передачи и приема сообщений

Формула изобретения

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

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

(б) обеспечение того, что, по меньшей мере, для одного владельца каждого Summa-аккаунта назначен, по меньшей мере, один сбор за получение, взимаемый за получение, по меньшей мере, одного Summa-сообщения, адресованного указанному аккаунту; и

(в) перевод оплаты указанного сбора от отправителя получателю после доставки Summa-сообщения.

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

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

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

(в) доставку части с сообщением получателю и перевод денежных средств на финансовый счет получателя.

3. Способ по п.2, включающий перед шагом (в):

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

(д) посылку отправителю уведомления о том, что доставка Summa-сообщения была отклонена из-за недостатка денежных средств.

4. Способ по п.2, включающий перед шагом (в) следующие шаги:

(г) обеспечение того, что, по меньшей мере, для одного пользователя Summa-аккаунта назначен, по меньшей мере, один сбор за получение, требуемый за получение, по меньшей мере, одного Summa-сообщения, адресованного указанному счету;

причем шаг (б) включает:

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

5. Способ по п.4, в котором шаг (г) включает:

(е) назначение первого требуемого сбора за получение сообщения для первого набора отправителей, представляющих первую категорию отправителей, и второго требуемого сбора за получение сообщения для второго набора отправителей, представляющих вторую категорию отправителей;

при этом шаг (в) включает:

(ж) после определения того, что отправитель является членом первой категории, перевод оплаты сбора за получение, требуемого для первой категории отправителей, после доставки Summa-сообщения, и

(з) после определения того, что отправитель является членом второй категории, перевод оплаты сбора за получение, требуемого для второй категории отправителей, после доставки Summa-сообщения.

6. Способ по п.5, включающий перед шагом (в):

(и) обеспечение предоставления отправителем информации, используемой для идентификации категории отправителя,

при этом шаги (ж) и (з) выполняют в соответствии с информацией, полученной на шаге (и).

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

(е) отправка обратно на счет отправителя любых лишних денежных средств, разрешенных к дебетованию со счета отправителя.

8. Способ по п.4, включающий перед шагом (в):

(е) обеспечение определения отправителем сообщения максимальной платы за доставку, которую он разрешает применить для оплаты сбора за получение;

(ж) отклонение сообщения всякий раз, когда максимальный разрешенный сбор меньше, чем требуемый сбор за получение; и

(з) продолжение обработки Summa-сообщений, когда максимальный разрешенный сбор достаточен для оплаты требуемого сбора за получение.

9. Способ по п.8, включающий перед шагом (в):

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

(к) обеспечение того, что, по меньшей мере, один владелец каждого Summa-аккаунта назначает первое максимальное количество сообщений, которые получатель желает принять от отправителей из первой категории в течение промежутка времени, заданного получателем, и второе максимальное количество сообщений, которые получатель желает принять от отправителей из второй категории;

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

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

10. Способ по п.4, включающий перед шагом (в):

(е) обеспечение определения отправителем Summa-сообщения максимальной платы за доставку, которая разрешена для оплаты сбора за получение;

(ж) обеспечение того, что, по меньшей мере, один владелец каждого Summa-аккаунта определяет минимальный уровень дохода, который он желает получить в течение заранее заданного промежутка времени за счет платы за доставку, производимой, по меньшей мере, одним заранее заданным набором отправителей;

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

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

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

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

11. Способ по п.2, включающий перед шагом (в):

(г) обеспечение того, что, по меньшей мере, один владелец каждого Summa-аккаунта санкционирует, по меньшей мере, одну плату за получение, по меньшей мере, одного Summa-сообщения, получаемого, по меньшей мере, от одного отправителя; и

на шаге (в) дополнительно включающий:

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

12. Способ по п.2, включающий:

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

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

13. Способ по п.2, включающий перед шагом (в) следующие шаги:

(г) размещение денежных средств, разрешенных для дебетования, на

счете условного депонирования в ожидании доставки Summa-сообщения и

(д) возврат денежных средств, депонированных на счете условного депонирования, на финансовый счет, с которого они были сняты, в случае если Summa-сообщение не доставлено.

14. Способ по п.2, включающий:

(г) хранение в указанных файлах записи о покупках, совершенных, по меньшей мере, одним владельцем каждого Summa-аккаунта.

15. Способ по п.2, включающий:

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

(д) обеспечение того, что, по меньшей мере, один отправитель маркетингового сообщения делает выборки из маркетинговой базы данных для создания списка, по меньшей мере, из одного пользователя, который, по мнению отправителя, с наибольшей вероятностью воспримет, по меньшей мере, одно маркетинговое сообщение; и

(е) посылка Summa-сообщения, представляющего собой маркетинговое сообщение, от отправителя маркетингового сообщения по адресам выбранного списка, включающего, по меньшей мере, одного пользователя.

16. Способ по п.2, включающий перед шагом (в):

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

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

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

17. Способ по п.16, включающий между шагами (д) и (е):

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

18. Способ по п.2, включающий:

(г) обеспечение того, что отправитель идентифицирует, по меньшей мере, одну часть сообщения как сообщение первого типа или как сообщение второго типа; и

включающий после шага (б):

(д) обработку сообщения первого типа способом, заранее заданным для сообщений первого типа; и

(е) обработку сообщения второго типа способом, заранее заданным для сообщений второго типа.

19. Способ по п.2, включающий на шаге (б):

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

20. Способ по п.2, включающий перед шагом (в):

(г) обеспечение того, что каждый отправитель Summa-сообщения определяет сбор за ответ, требуемый отправителем в случае, когда получатель хочет ответить на сообщение отправителя; и включающий после шага (в):

(д) уведомление отправителя о сборе за ответ, требуемом получателем за ответ на сообщение отправителя; и

(е) перевод платы сбора за ответ после доставки ответа.

21. Способ по п.2, включающий перед шагом (в):

(г) разрешение отправителю установить время, в которое следует прекратить попытки доставить Summa-сообщение; и

(д) исключение шага (в), если время, отведенное на доставку, и стекло.

22. Способ по п.2, включающий на шаге (б):

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

23. Способ по п.2, включающий между шагами (б) и (в):

(г) передачу запроса на дополнительное разрешение дебетования финансового счета отправителя, по меньшей мере, одному другому пользователю Summa-аккаунта, с которого должны дебетоваться денежные средства; и

(д) запрещение совершения шага (в) до того, как будет получено дополнительное разрешение.

24. Способ по п.2, включающий:

(г) обеспечение наличия множества Summa-аккаунтов посредством множества сетевых серверов, которыми управляет, по меньшей мере, один провайдер услуг;

(д) идентификация каждого сетевого сервера, по меньшей мере, на одном сервере клиринговой палаты;

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

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

25. Способ по п.2, включающий:

(г) обеспечение наличия множества Summa-аккаунтов с помощью множества сетевых серверов, которыми управляет, по меньшей мере, один провайдер услуг;

(д) обеспечение того, что каждый провайдер услуг хранит нетто-активы, депонированные на Summa-аккаунтах, обслуживаемых, по меньшей мере, одним сетевым сервером, по меньшей мере, на одном электронном денежном счете;

(е) идентификацию каждого сетевого сервера, по меньшей мере, на одном сервере клиринговой палаты;

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

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

26. Способ по п.2, включающий:

(г) обеспечение того, что первый набор пользователей имеет Summa-аккаунты, связанные с финансовыми счетами в первом финансовом учреждении, а второй набор пользователей имеет Summa-аккаунты, связанные с финансовыми счетами во втором финансовом учреждении;

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

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

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

(з) когда получатель Summa-сообщения из первого набора получает денежные средства, их дебетуют с первого финансового счета провайдера услуг; и

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

27. Способ по п.2, включающий перед шагом (в):

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

(д) чтение жетона сетевым электронным устройством для извлечения информации, по меньшей мере, об одном Summa-аккаунте; и

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

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

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

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

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

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

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

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

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

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

29. Система по п.28, в которой заранее заданные условия включают сбор за получение, требуемый за получение, по меньшей мере, одного Summa-сообщения, адресованного получателю, и плату за отправку Summa-сообщения с Summa-аккаунта отправителя, посредством чего сообщение доставляется с Summa-аккаунта отправителя на Summa-аккаунт получателя, а оплата сбора за получение передается с финансового счета отправителя на финансовый счет получателя после доставки Summa-сообщения, когда сбор за получение не превышает плату за отправку, и уведомление о том, что сообщение не было доставлено, возвращается на Summa-аккаунт отправителя, когда сбор за получение превышает плату за отправку.

30. Способ проведения финансовых транзакций между Summa-аккаунтами, включающий:

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

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

31. Способ по п.30, также включающий:

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

32. Способ по п.30, также включающий:

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

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

33. Способ по п.30, также включающий:

обеспечение наличия множества Summa-аккаунтов посредством множества сетевых серверов, управляемых, по меньшей мере, одним провайдером услуг,

идентификацию каждого сетевого сервера для, по меньшей мере, одного сервера клиринговой палаты,

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

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

34. Способ проведения финансовых транзакций между Summa-аккаунтами, включающий:

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

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

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

35. Способ по п.34, также включающий:

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

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

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

36. Способ по п.35, также включающий:

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

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

37. Способ по п.36, также включающий:

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

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

Описание изобретения к патенту

Предпосылки создания изобретения

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-клиент может быть интегрирован в сотовый телефон или другое сетевое электронное устройство. Аналогично, сбор за получение может быть применен к приему телефонных звонков и другого вида электронных сообщений.

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