RU2419137C2 - Система и способ передачи документов и управления документооборотом - Google Patents

Abstract

Изобретение относится к средствам обмена сообщениями по электронной почте. Техническим результатом является обеспечение возможности назначать приоритеты, сортировать и управлять электронной почтой. Система и способ используют и дополняют Интернет с помощью почтового сервера и программного обеспечения, подключенных к Интернету. Отправитель и получатель имеют терминалы, также подключенные к Интернету. Для выбора передачи электронной почты с определенными премиум-услугами отправитель использует программное обеспечение отправителя. Система и способ включают функции оплаты и учета использования премиум-услуг. Система и способ могут работать на множестве серверов, находящихся в одном или разных местах. Почтовый сервер и программное обеспечение могут использоваться только для обработки данных о сообщении и/или для его передачи. Связи между отправителем, получателем и почтовым сервером могут создать подобие виртуальной интрасети. Передаваемая электронная почта использует данные сообщения для идентификации отправителя, аутентификации и проверки электронной почты и управления ее обработкой. 2 н. и 40 з.п. ф-лы, 32 ил.

Description

Уровень техники

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

Появление Интернета повлекло за собой революционные перемены в коллективном использовании информации. Объем электронной почты, или e-mail, передаваемой по Интернету, впечатляюще вырос, и такой же сильный его рост прогнозируется в будущем. Рост использования электронной почты носит взрывной характер из-за быстрого увеличения количества вычислительных устройств различных типов, а также из-за большей доступности и увеличения пропускной способности сетей связи. По оценкам в течение 2002 года по электронной почте ежедневно отправлялся 31 миллиард сообщений, и ожидается, что это число, увеличиваясь более чем на 20% в год, к 2006 году превысит значение 60 миллиардов.

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

Взрывной рост количества желательной почты сам по себе вызывает постоянно увеличивающуюся проблему перегрузки. Из 31 миллиарда сообщений e-mail, ежедневно отправляемых в 2002 г., приблизительно 21 миллиард был желательной почтой, т.е. такой, которую получатели посчитали полезной, независимо от того, запрашивалась она или нет.

Ожидается, что к 2006 г. этот объем желательной электронной почты достигнет 36 миллиардов писем в день.

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

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

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

Сегодня большая часть Интернет-рекламы существует в виде баннеров, а не сообщений электронной почты. Из 2.8 миллиардов долларов, потраченных в США в 1999 году на Интернет-рекламу, баннерная реклама составила 50%, тогда как реклама по электронной почте составила лишь 3%. Затраты на рекламу в Интернете продолжили стремительно расти, достигнув 12 миллиардов долларов в 2004 г., и предположительно составят 14.7 миллиардов долларов в 2005 г., увеличившись за 2004 г. на 23%. Однако баннерная реклама известна своей неэффективностью и отличается низким отношением количества «кликов» к числу показов. Поэтому для привлечения внимания публики, передачи сообщений и увеличения процента отклика существует необходимость в более эффективных методах Интернет-маркетинга, таких как прямой маркетинг по электронной почте.

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

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

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

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

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

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

Среди многих недостатков подобных служб и программ фильтрации нежелательной почты следует отметить, что они:

- Блокируют доставку получателю многих желательных писем. Одна организация по исследованию рынка информационных технологий подсчитала, что в 2003 г. данная проблема стоила бизнесу 3,5 миллиардов долларов США.

- Позволяют многим экономически бесполезным, нежелательным, незапрашиваемым и оскорбительным электронным письмам доходить до получателей. И это по оценкам стоило бизнесу в 2003 г. 10 миллиардов долларов США.

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

- Не производят универсальное отсеивание электронной почты по опасности в техническом плане.

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

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

- Не предоставляют никаких встроенных услуг отслеживания электронной почты для отправителей или получателей.

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

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

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

Примером организации, которая стремилась устранить эти недостатки, является Почтовая служба США (U.S.P.S.). Однако способ U.S.P.S. требует от отправителя выйти из своей почтовой программы, зайти на веб-сайт U.S.P.S. и составить письмо на нем. Затем U.S.P.S. распечатывает документ, помещает его в конверт, производит оплату и физически доставляет его. В 2003 г. письмо из одной страницы, созданное таким образом, стоило отправителю 50 центов. Хотя некоторые могут найти эту услугу привлекательной, ее недостаток заключается в том, что отправитель для отправки письма не может воспользоваться удобствами собственного почтового ящика (т.е. собственной почтовой программы). Во-вторых, данная система остается по большей части физическим, а не электронным способом, со всеми ограничениями, свойственными физической доставке почты. В-третьих, получатель не может для приема документа использовать свой электронный почтовый ящик (т.е. почтовую программу).

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

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

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

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

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

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

Краткое описание чертежей

Фиг.1 является блок-схемой системы Интернет-связи ePost Office и ePostal, созданной и используемой в соответствии с настоящим изобретением;

Фиг.2А и 2В являются функциональными блок-схемами операций Отправителя ePostal, включающих программное обеспечение Отправителя ePostal, соответствующих настоящему изобретению и используемых в системе, изображенной на фиг.1;

Фиг.3А-3С являются функциональными блок-схемами программного обеспечения сервера ePostal, соответствующего настоящему изобретению и работающего как связь ePost Office через Интернет между Отправителем и Получателем, как показано на фиг.1;

Фиг.4А-1, 4А-2 и 4В являются функциональными блок-схемами операций Получателя ePostal, соответственно имеющего или не имеющего программное обеспечение Получателя ePostal, соответствующих настоящему изобретению и используемых в системе, изображенной на фиг.1;

Фиг.5 является изображением альтернативных вариантов реализации данного изобретения, соответствующих фиг.1, где Отправитель и Получатель не имеют на используемом ими в данный момент компьютере программного обеспечения ePostal, показанного на фиг.2А, 2В, 4А-1 и 4А-2, но имеют учетные записи ePostal и могут отправлять и получать письма eLetter через систему ePostal в окне ePost Office или на веб-сайте ePostal;

Фиг.6 является функциональной блок-схемой рабочего взаимодействия Отправителя ePostal в «окне» ePost Office или на веб-сайте ePostal, соответствующего настоящему изобретению и используемого в варианте реализации, показанном на фиг.5;

Фиг.7 является функциональной блок-схемой рабочего взаимодействия Получателя ePostal в «окне» ePost Office или на веб-сайте ePostal, соответствующего настоящему изобретению и используемого в варианте реализации, показанном на фиг.5;

Фиг.8 является изображением другого варианта реализации изобретения, соответствующего фиг.1 и 9, где в рамках сети элементы операций ePostal, соответствующих изобретению, совместно используются на уровне Отправителя/Получателя и на уровне сетевого сервера;

Фиг.9 является изображением другого варианта реализации изобретения, соответствующего фиг.1, использующего различные варианты подключения к Интернету;

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

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

Фиг.12 является изображением альтернативных вариантов реализации изобретения, соответствующих фиг.1, для отправки электронной почты ePostal и связанных данных ePostal от ePostal Office Получателю;

Фиг.13 является изображением альтернативных вариантов реализации изобретения, соответствующих фиг.1, для отправки электронной почты ePostal и связанных данных ePostal от Отправителя напрямую к Получателю;

Фиг.14А и 14В являются функциональными блок-схемами примера реализации шагов для загрузки, установки и активизации пользователем программного обеспечения ePostal;

Фиг.15 является изображением примера варианта реализации прямой связи между Клиентским программным обеспечением ePostal (Отправителя и Получателя) и ePost Office;

Фиг.16А и 16В являются функциональными блок-схемами примера варианта реализации прямой связи между Клиентским программным обеспечением и ePost Office;

Фиг.17 является таблицей, показывающей пример реализации структур данных в сообщении для прямой связи между Клиентским программным обеспечением ePostal и ePost Office, соответствующий настоящему изобретению;

Фиг.18А и 18В являются функциональными блок-схемами примера последовательности шагов Отправителя для обработки письма eLetter и его отправки на ePost Office;

Фиг.19 является таблицей, показывающей пример составления специализированного заголовка eLetter для передачи от Отправителя на ePost Office, соответствующий настоящему изобретению;

Фиг.20А и 20В являются функциональными блок-схемами примера последовательности шагов ePost Office для обработки письма eLetter и его отправки Получателю;

Фиг.21 является таблицей, показывающей пример составления специализированных заголовков eLetter для передачи от Отправителя на ePost Office, соответствующий настоящему изобретению; и

Фиг.22А и 22В являются функциональными блок-схемами примера последовательности шагов Получателя для окончательной обработки письма eLetter.

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

На фиг.1 показана система 10 связи, соответствующая настоящему изобретению, которая соединяет множество пользователей системы (хотя показано только два), являющихся относительно какой-либо указанной транзакции или Отправителями 12 электронной почты («email») и прикрепленных документов и файлов, или Получателями 14 этой электронной почты и прикрепленных документов и файлов. Система 10 связи, описанная здесь, является службой "ePostal", а электронная почта, передаваемая в системе 10 и обрабатываемая в соответствии с настоящим изобретением, указывается как «eLetter», «документ» или просто «почта». (Термин «eLetter» используется только в том случае, когда электронная почта должна быть обработана или была обработана в соответствии с настоящим изобретением. Термины «ePostal», «ePost Office» и «eLetter», используемые здесь, являются знаками обслуживания ePostal Services, Inc., Стамфорд, Коннектикут). Указанный Отправитель 12 может отправлять одну и ту же электронную почту одному конкретному Получателю 14 или нескольким Получателям 14. Указанный Получатель с доступом к системе ePostal также может быть Отправителем писем eLetter. Изображенный Отправитель 12 может быть Получателем 14, и наоборот. Система 10 включает известные линии 16 связи между каждым Отправителем или Отправителями 12 и Интернетом 18 через Интернет-провайдера 19 Отправителя и между Интернетом и каждым Получателем или Получателями 14 через Интернет-провайдера 19 Получателя.

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

Помимо этого, как показано на фиг.9, хотя на фиг.1 в качестве посредника между Отправителем/Получателем и Интернетом указан Интернет-провайдер 19, фактический тип соединения с сервером доступа к Интернету и электронной почте может являться любой существующей альтернативой, которая предоставляет подобные услуги Отправителю/Получателю. Такими услугами могут быть серверы доступа к Интернету и электронной почте корпоративных интрасетей или других сетей, таких как экстрасети, локальные сети и т.п. В данной системе обычно присутствуют традиционные сетевые экраны и фильтры. Кроме того, как показано на фиг.9 и 10, конкретный тип физического соединения может использовать ряд альтернативных вариантов, таких как телефонные, сотовые, DSL, кабельные, спутниковые или другие соединения, и даже физическую доставку (фиг.10).

Настоящее изобретение использует, дополняет и расширяет основные известные системы электронной почты по протоколу SMTP и обмена сообщениями по протоколу HTTP. Здесь подразумевается, что термин "Интернет" включает и то, и другое. Отличительным свойством настоящего изобретения является система, называемая здесь ePost Office 20 (фиг.1). В предпочтительном варианте ePost Office 20 является сервером или совокупностью серверов, на которых работает программное обеспечение 24, 24', показанное на фиг.3А-С, 4В, 6 и 7, и которые подключены к Интернету при помощи линий связи 16. Хотя ePost Office 20 будет описано как почтовое программное обеспечение 24, 24', работающее на сервере, необходимо понимать, что сервер может являться несколькими серверами или эквивалентным аппаратным или программным обеспечением. Используемые здесь термины "ePost Office", "ePO", "почтовый сервер", "электронная почтовая служба" и "почтовый сервер и программное обеспечение" заключают в себе все эти варианты и другие известные эквиваленты.

На практике все серверы или группы серверов ePO 20 могут быть расположены в одном физическом месте. Однако в качестве альтернативы отдельные группы серверов могут располагаться в разных местах, в которых каждая такая группа серверов, на которых запущено программное обеспечение 24, 24', может выполнять функции ePO 20 для определенных назначенных Отправителей 12 и Получателей 14, и это распределение может быть изменено. Как предпочтительно в настоящее время, вся группа или сеть географически раздельных групп серверов, на которых выполняется программное обеспечение 24, 24' и которые соединены друг с другом через Интернет и линии связи, скоординирована для обеспечения эффективной работы, доступности и резервирования, масштабируемости, улучшенных услуг для пользователей и преимуществ защиты. При таком объединении вся группа или сеть отдельных групп серверов ePost Office 20 является системой ePost Office 20, показанной на фиг.1.

Система ePost Office 20 осуществляет связь и координацию между ПК Отправителя 12 и Получателя 14, серверами или подобным оборудованием (терминалами отправителя и получателя), на которых выполняется программное обеспечение 22, 26, изображенное на фиг.2А, 2В, 4А-1 и 4А-2. Это программное обеспечение в предпочтительном варианте установлено на ПК Отправителя 12 и Получателя 14 или на сервере соответственно. Работа ePost Office 20 во взаимодействии с программным обеспечением 22, 26 ePostal на терминалах Отправителя 12 и Получателя 14 использует основную систему электронной почты по протоколу SMTP и стандартную систему обмена сообщениями по протоколу HTTP. Программное обеспечение 22, 26 ePostal, установленное или действующее на ПК отправителя и получателя или на серверах, совместимо с операционной системой и прикладными программами (электронная почта и браузер) на этих ПК или серверах.

Имеется множество альтернативных вариантов того, каким образом ePost Office 20 на фиг.1 осуществляет связь и координацию между Отправителем 12 и Получателем 14 для обеспечения работы системы связи, изображенной на фиг.1. Альтернативы включают различные способы изначальной обработки и отправки письма eLetter Отправителем 12, и/или его обработки ePost Office 20, и/или его доставки и окончательной обработки Получателем 14. Одной переменной в этих альтернативных вариантах является то, будет ли сообщение eLetter (его содержимое, в отличие от информации для обработки сообщения) передано через ePost Office 20. Второй переменной являются альтернативные протоколы передачи (и способ, которым они используются) для отправки и доставки сообщения и сопровождающих данных eLetter ePostal, которые необходимы ePost Office 20 и Получателю 14 для обработки eLetter, передаваемого от Отправителя 12 Получателю 14. Здесь «данные eLetter ePostal» также могут упоминаться как «данные ePostal», «данные для обработки ePostal», «данные сообщения eLetter», «данные eLetter», «данные сообщения», «элемент данных сообщения» и т.п.

На фиг.11 показано четыре альтернативных варианта (а)-(d) отправки eLetter Отправителем 12 на ePost Office 20, каждый из которых имеет определенный набор преимуществ и недостатков, описанных ниже. Соединения между Отправителем 12, Интернет-провайдером 19 Отправителя и еРО 20 показаны как упрощенный вариант фиг.1 без линий связи 16. Хотя основной поток информации письма eLetter идет от Отправителя 12 кеРО 20, необходимо понимать, что, как показано на фиг.11, передача данных может происходить в обоих направлениях, что используется для содействия соединениям с Интернетом, которые передают информацию eLetter, и для обмена данными сообщения и защиты.

В альтернативном варианте (а) сообщение eLetter и все данные ePostal, необходимые для отправки, обработки и доставки сообщения eLetter как письма eLetter, отправляются Отправителем 12 вместе при помощи стандартного протокола электронной почты, такого как SMTP, через почтовый сервер Интернет-провайдера 19 отправителя на почтовый сервер еРО 20. Здесь и далее эта группа возможных почтовых протоколов для простоты упоминается как SMTP. Преимущества данного варианта: вся информация находится в одном пакете; количество передач сводится к минимуму, и поэтому возникает меньше связанных с этим неопределенностей; и, так как это наиболее обычная процедура отправки электронной почты, меньше вероятность того, что на пути передачи в еРО 20 возникнут какие-либо проблемы.

В альтернативном варианте (b) сообщение eLetter и большая часть данных для обработки ePostal отправляются как в альтернативе (а). Однако ограниченное количество данных для обработки ePostal, таких как идентификационные и защитные номера для Отправителя 12 и eLetter, будут также передаваться между Отправителем 12 и еРО 20 при помощи стандартного протокола прикладной программы TCP, такого как HTTP, через Интернет-провайдера 19 отправителя. В преимущества данного варианта входит преимущество защиты, приобретаемое за счет того, что сообщение eLetter, которое может содержать зашифрованную информацию, отправляется отдельно от второго соединения с данными для обработки ePostal, которое содержит идентификационные номера и ключи шифрования для зашифрованной информации. Однако имеются и недостатки: требуется больше соединений, и пользователю может потребоваться находиться в режиме онлайн, когда Отправитель 12 обрабатывает eLetter.

В альтернативном варианте (с) Отправитель 12 через протоколы SMTP и почтовый сервер Интернет-провайдера 19 Отправителя посылает в еРО 20 только сообщение eLetter и ограниченные данные для обработки ePostal, такие как идентификационные и защитные номера. Все остальные данные ePostal для обработки eLetter отправляются непосредственно в еРО 20 через HTTP или какой-либо другой подобный протокол. Данный пример подобен варианту (b), за исключением того, что непосредственно в еРО 20 через HTTP отправляется больше данных для обработки ePostal. Он показывает, что в рамках альтернативы (b) может существовать много вариантов для объема данных, который может передаваться раздельно, в зависимости от функций программирования и обработки, примерно с одинаковыми результатами.

В альтернативном варианте (d) вся информация, включая сообщение eLetter и данные для обработки ePostal, отправляют непосредственно в еРО 20 при помощи протокола типа HTTP. Данный вариант не имеет преимуществ eLetter, отправляемого в двух отдельных пакетах. В недостатки входит возможная необходимость Отправителю 12 во время обработки eLetter находиться в режиме онлайн (в зависимости от терминальных систем Отправителя 12) и проблемы ненадежности электронной почты, которые могут возникнуть при отправке электронных писем таким способом.

При отправке eLetter через еРО 20 при помощи любого из этих способов или их комбинации в зависимости от ситуации отправителя динамически выбирается лучший из них. Если пользователь находится в режиме «онлайн» или собирается перейти в этот режим, предпочтительным вариантом является альтернатива (b). Здесь Отправитель 12 осуществляет связь с еРО 20 через HTTP или какой-либо другой подобный протокол, предоставляет для еРО 20 данные ePostal, включающие идентификационный номер eLetter, и дает или получает от еРО одноразовый ключ шифрования. После этого данный ключ используется для шифрования eLetter и других данных для обработки ePostal, которые отправляются в еРО 20 через SMTP и почтовый сервер Интернет-провайдера. Однако, если пользователь не в сети или не собирается переходить в режим «онлайн», предпочтительно использовать альтернативу (а), так как перед обработкой отправителем 12 письма eLetter не требуется соединение с еРО 20. Шифрование eLetter и/или данных для обработки ePostal осуществляется при помощи ключа шифрования, который хранится и зарезервирован для таких целей у Отправителя 12. Альтернатива (d) может использоваться в ситуации, когда Отправитель 12 всегда находится в сети и/или когда условия или требования Отправителя 12, еРО 20 или Получателя 14 гарантируют это.

При отправке eLetter через еРО 20 после его обработки в ePost Office 20 eLetter будет отправлено от еРО 20 Получателю 14. На фиг.12 показано три альтернативных варианта (е)-(g) отправки eLetter от ePost Office 20 Получателю 14, каждый из которых имеет определенный набор преимуществ и недостатков. На фиг.12 соединения между еРО 20, Интернет-провайдером 19 Получателя и получателем показаны как упрощенный вариант фиг.1 без линий связи 16. Хотя основной поток информации письма eLetter идет от еРО 20 к Получателю 14, необходимо понимать, что, как показано на фиг.12, передача данных может происходить в обоих направлениях, что используется для содействия соединениям с Интернетом, которые передают информацию eLetter, и для обмена данными сообщения и защиты. В альтернативном варианте е) сообщение eLetter и все данные ePostal, необходимые для отправки, обработки и доставки сообщения в виде eLetter Получателю 14 отправляются от еРО 20 вместе при помощи SMTP и POP, MAP или других подобных почтовых протоколов на почтовый сервер Интернет-провайдера 19 Получателя, а затем Получателю 14.

Преимущества данного варианта:

- Вся информация находится в одном пакете.

- Минимальное количество передач, что означает меньшее количество связанных с этим неопределенностей.

- Не требуется других соединений кроме приема eLetter от Интернет-провайдера 19 получателя.

Таким образом, Получателю 14 не требуется находиться или переходить в режим «онлайн» для завершения обработки eLetter, и, так как это наиболее обычная процедура отправки электронной почты, меньше вероятность того, что на пути передачи от еРО 20 Получателю 14 возникнут какие-либо проблемы.

Кроме того, вариант (е), так же как и варианты (f) и (g), допускает, что наиболее предпочтительный и простой, а возможно даже единственный способ приема Получателем 14 сообщений eLetter - это их получение с почтового сервера Интернет-провайдера 19 Получателя.

В альтернативном варианте (f) Получателю 14 через почтовый сервер Интернет-провайдера 19 Получателя отправляют только сообщение eLetter и некоторые данные для обработки ePostal, такие как идентификационные и защитные номера. Количество данных ePostal, отправляемых вместе с eLetter, может меняться в зависимости от комбинации системных функций Получателя 14 и Интернет-провайдера 19 Получателя. Когда eLetter доходит до Получателя 14, Получатель 14 напрямую подключается к еРО 20 через HTTP или какой-либо другой подобный протокол, и еРО 20 предоставляет Получателю 14 все оставшиеся данные ePostal, необходимые для завершения обработки eLetter на стороне Получателя 14. В преимущества данного варианта входит преимущество защиты, приобретаемое за счет того, что сообщение eLetter, которое может содержать зашифрованную информацию, отправляется через HTTP отдельно от второго соединения с данными ePostal, которое содержит идентификационные и защитные номера для eLetter. Однако имеются и недостатки: требуется более сложный набор соединений с еРО 20 по сравнению с вариантом (е), а Получатель 14 должен иметь возможность подключения к сети для завершения обработки eLetter. Если Получатель 14 не находится в режиме «онлайн» или не имеет права подключиться к сети, то он не сможет завершить обработку eLetter и должен ждать, пока он не перейдет в режим «онлайн».

В альтернативном варианте (g) еРО 20 сначала посылает Получателю 14 письмо еРО, которое не содержит никаких частей сообщения eLetter Отправителя. Это сообщение еРО 20, отправляемое из еРО, имеет только ограниченные идентификационные и защитные номера eLetter Отправителя 12 и информирует Получателя 14, что eLetter было сохранено для Получателя 14 в еРО 20. После этого Получатель 14 подключается к еРО 20 через HTTP или какой-либо другой подобный протокол, и еРО 20 предоставляет Получателю 14 письмо eLetter Отправителя 12 и все данные ePostal, необходимые для завершения обработки eLetter Отправителя 12 на Получателе 14. Вариант (g) имеет те же недостатки, что и вариант (f), так как Получатель 14 должен перейти в режим «онлайн» для получения от еРО 20 сообщения eLetter и данных ePostal, необходимых для окончательной обработки. Однако вариант (g) имеет некоторые преимущества в защите по сравнению с вариантом (f), так как Получателю 14 не передается от еРО 20 никаких частей сообщения eLetter Отправителя 12 до тех пор, пока Получатель 14 не получит данные ePostal, необходимые для завершения обработки eLetter.

Во многих случаях предпочтительным вариантом системы 10 ePostal среди этих трех альтернативных вариантов является вариант (е). Он наиболее прост, требует минимального количества соединений, имеет гибкость благодаря отсутствию необходимости подключения к сети для получения дополнительной информации и обеспечивает хорошую защиту. Однако имеются комбинации системных функций Получателя 14 и Интернет-провайдера 19, в которых предпочтительны варианты (f) или (g). Такая ситуация имеет место, когда Получатель 14 всегда находится в режиме «онлайн» или с большой вероятностью может перейти в режим «онлайн» при необходимости подключения к еРО 20 для получения данных ePostal. Как говорилось ранее, отдельное соединения для сообщения eLetter и данных для обработки ePostal обеспечивают некоторые преимущества в защите. В качестве другого примера, разновидность варианта (g) используется в случае, когда eLetter отправляется Получателю, не имеющему программного обеспечения 26 Получателя.

На фиг.13 показано два альтернативных варианта (h) и (i) отправки сообщения от Отправителя 12 Получателю 14, но не через ePost Office 20. Каждый вариант имеет свои преимущества и недостатки. Соединения между Отправителем 12, Интернет-провайдером 19 Отправителя, Интернет-провайдером 19 Получателя и Получателем 14 показаны в виде упрощенного варианта фиг.1 без линий связи 16. Хотя основной поток информации письма eLetter и информации о нем идет от Отправителя 12 к Получателю 14 (и некоторая информация от и для еРО 20), необходимо понимать, что, как показано на фиг.13, передача данных может происходить в обоих и/или во всех направлениях между Отправителем 12, Получателем 14 и еРО 20, что используется для содействия соединениям с Интернетом, которые передают информацию eLetter, и для обмена данными сообщения и защиты.

В альтернативном варианте (h) сообщение eLetter и большая часть данных ePostal, необходимых для отправки, обработки и доставки сообщения как письма eLetter, отправляются Отправителем 12 вместе при помощи стандартного протокола электронной почты, такого как SMTP и POP/IMAP, Интернет-провайдеру 19 Получателя и Получателю 14 без подключения к ePost Office 20. Однако ограниченное количество данных для обработки ePostal, таких как идентификационные и защитные номера для отправителя 12 и eLetter, которые необходимы для обработки eLetter, будут также напрямую передаваться между Отправителем 12 и еРО 20 при помощи стандартного протокола прикладной программы TCP, такого как HTTP, через Интернет-провайдера 19 Отправителя. После того как Получатель 14 получит сообщение eLetter и данные ePostal, он напрямую подключается к еРО 20 через Интернет-провайдера 19 Получателя при помощи стандартного протокола прикладной программы TCP, такого как HTTP, для получения от еРО 20 оставшегося и ограниченного количества данных для обработки ePostal, которые не передаются вместе с сообщением eLetter. После этого Получатель 14 завершает обработку eLetter. Преимущества и недостатки данного варианта (h) описаны ниже вместе с преимуществами и недостатками варианта (i).

В альтернативном варианте (i) сообщение eLetter и только ограниченное количество данных для обработки ePostal, таких как идентификационные и защитные номера, отправляются Отправителем 12 вместе при помощи стандартного протокола электронной почты, такого как SMTP и POP/IMAP, Интернет-провайдеру 19 Получателя и Получателю 14 без подключения к ePost Office 20. Однако большая часть данных для обработки ePostal, необходимых для отправки, обработки и доставки сообщения eLetter в качестве eLetter, будут передаваться между Отправителем 12 и еРО 20 при помощи стандартного протокола прикладной программы TCP, такого как HTTP, через Интернет-провайдера 19 Отправителя. После того как Получатель 14 получит сообщение eLetter и ограниченные данные ePostal, он напрямую подключается к еРО 20 через Интернет-провайдера 19 Получателя при помощи стандартного протокола прикладной программы TCP, такого как HTTP, для получения от еРО 20 данных для обработки ePostal, которые не передаются вместе с сообщением eLetter. После этого Получатель 14 завершает обработку eLetter. Преимущества и недостатки данного варианта (i) описаны ниже вместе с преимуществами и недостатками варианта (h).

Альтернативные варианты (h) и (i) одинаковы и отличаются только количеством данных для обработки ePostal, которые отправляются Отправителем 12 вместе с сообщением eLetter при помощи стандартного протокола электронной почты, такого как SMTP и POP/IMAP, Интернет-провайдеру 19 Получателя и Получателю 14 без подключения к ePost Office 20.

Единственное преимущество, которое могут иметь эти альтернативные варианты, появляется в том случае, когда Отправитель 12 и Получатель 14 по какой бы то ни было причине предпочитают не передавать сообщения eLetter через ePost Office 20. Альтернативный вариант (i) имеет некоторые преимущества в защите по сравнению с вариантом (h) за счет того, что данные для обработки ePostal не передаются по тому же соединению, по которому передается сообщение eLetter.

С другой стороны, варианты (h) и (i) имеют множество недостатков. Во-первых, необходимое количество соединений делает эти способы более сложными, из-за чего возникает большая вероятность проблем со связью. Во-вторых, намного более важным является тот факт, что сообщение eLetter не проходит через ePost Office 20, в результате чего возникает множество недостатков, в числе которых:

- еРО 20 не может просматривать eLetter от лица Отправителя 12 и Получателя 14 на наличие опасностей, связанных с содержанием и техническими свойствами.

- еРО 20 не может устанавливать подлинность Отправителя 12, подтверждать сертификацию конкретного Отправителя и оценивать целостность сообщения eLetter с той достоверностью, с которой это может выполнять получатель при связи с еРО 20. В общем случае это делает аутентификацию Отправителя 12, сертификацию конкретного Отправителя и оценку целостности eLetter менее достоверными и поэтому менее защищенными.

- Также еРО 20 не может управлять функциями возврата Отправителю 12. Поэтому возникает утрата возможности предоставлять Отправителю 12 дополнительные преимущества и контролировать общую безопасность системы ePostal.

- еРо 20 не может предоставлять Отправителю 12 и Получателю 14 временные метки отслеживаемых записей о времени обработки сообщения eLetter в еРО 20.

- еРО 20 не может предоставлять Отправителю 12 наиболее официального подтверждения оплаты ePostal за eLetter.

- еРО 20 не может обеспечивать такую же степень невозможности отказа от авторства в отношении eLetter, которое выбирается Отправителем 12 для вложения в официальное хранилище сообщений eLetter в системе ePostal. В стандартах для таких официальных хранилищ требуется копия оригинального eLetter, которое проходит через еРО 20, а не копия, сделанная Отправителем 12 или Получателем 14.

- Отправка зашифрованного eLetter напрямую от Отправителя 12 нескольким Получателям 14, а не через еРО 20, более сложна и менее безопасна, что будет позже подробно описано в разделе про то, как еРО 20 обрабатывает и доставляет зашифрованные сообщения eLetter нескольким Получателям 14.

Из вышеперечисленного ясно, что отправка сообщения eLetter через ePost Office 20, как показано на фиг.11 и 12, имеет множество преимуществ по сравнению с отправкой сообщения eLetter Получателю 14 в обход еРО 20, как показано на фиг.13. В большинстве случаев отправка через еРО 20 является предпочтительным и наиболее гибким вариантом осуществления настоящего изобретения. Однако в некоторых сочетаниях ситуаций Отправителя 12 и Получателя 14 отправка eLetter непосредственно Получателю 14 может быть предпочтительнее. Например, Получатель 14 может являться клиентской рабочей станцией, находящейся в корпоративной сети, в которой Интернет-провайдер 19 Получателя по существу является сервером сетевой почты и доступа к Интернету и в которой сетевое программное обеспечение ePostal, как показано на фиг.8, работает с серверами сетевой почты, доступа в Интернет и другими корпоративными серверами.

Это программное обеспечение 22, 26 установлено, например, в сочетании с открытием пользователем аккаунта в Службе ePostal, например, по меньшей мере частично путем загрузки.

Относительно установки и открытия Аккаунта на ePost Office 20 имеется три альтернативных варианта процедур загрузки, установки и активации программного обеспечения 22, 26 у Отправителя 12 и Получателя 14 (комбинации которых могут также указываться как «Клиентское программное обеспечение» или «Клиентская программа») перед тем, как его можно будет использовать. Процесс загрузки, установки и активации и основные варианты показаны на фиг.14А и 14В. Специалистам необходимо понимать, что конкретные шаги процесса зависят от технических характеристик Клиентского терминала, в том числе от операционной системы и почтовой программы.

Пример процесса, показанный на фиг.14А, начинается с шагов, включенных в фазу D1 загрузки и установки. Пользователь начинает процесс с решения загрузить программное обеспечение и описывает компоненты программного обеспечения пользовательского терминала, важные для еРО, такие как операционная система, почтовая программа и веб-браузер. Загрузка может осуществляться с веб-сайта ePost Office 20, с компакт-диска с программным обеспечением ePostal или любого другого носителя ePostal, содержащего необходимое программное обеспечение, совместимое с операционной системой и программой электронной почты пользовательского терминала. Пользовательский терминал закачивает и сохраняет файл установки Клиентского программного обеспечения 22, 26, который запускается на терминале.

В этот момент пользователю предоставляется лицензионное соглашение на обслуживание конечного пользователя (end user licensing and service agreement, EULSA), который он должен принять перед продолжением загрузки. EULSA может быть показано позже, но вариант его отображения в данный момент времени является лучшим, так как если пользователь не принимает EULSA, процесс загрузки прерывается и на компьютер пользователя не закачивается никакого другого программного обеспечения. Если EULSA принимается, файл установки Клиентской программы закачивает и устанавливает оставшееся программное обеспечение.

Затем Клиентское программное обеспечение 22, 26 напрямую соединяется с еРО 20 при помощи HTTP или другого подобного протокола TCP прикладной программы, проверяя статус «онлайн» еРО 20. На этом завершается фаза D1 загрузки и установки при установке Клиентского программного обеспечения 22, 26.

Начинается фаза D2 регистрации. После идентификации ePOst Office 20 клиентское программное обеспечение 22, 26 готово для соединения, оно предлагает пользователю создать Аккаунт в еРО 20 и показывает ему экран Создания Аккаунта, на котором пользователь вводит запрашиваемую информацию. Затем Клиентская программа передает эти пользовательские данные в еРО 20 при помощи HTTP или какого-либо подобного протокола TCP. ePO 20 сохраняет и обрабатывает пользовательские данные, регистрирует для пользователя новый Аккаунт и передает информацию о регистрации Аккаунта обратно клиентской программе при помощи того же протокола, подобного HTTP, который Клиентская программа использует для связи с ePO 20. На этом завершается фаза D2 регистрации при установке Клиентского программного обеспечения 22, 26.

Начинается фаза D3 верификации. После этого Клиентское программное обеспечение 22, 26 показывает пользователю экран Кредитной Карты, на котором пользователь вводит информацию о кредитной карте. Затем Клиентская программа передает эти пользовательские данные в ePost Office 20 при помощи HTTP или какого-либо подобного протокола TCP. ePO 20 получает данные о Кредитной Карте и проверяет, что это настоящая Кредитная Карта, которой пользователь может оплатить стоимость использования системы связи ePostal. Затем ePO 20 передает в Клиентскую программу при помощи того же протокола, подобного HTTP, который Клиентская программа использует для связи с ePO 20, что аккаунт был подтвержден, наряду с временными данными идентификации и защиты Отправителя 12 и Получателя 14. Альтернативой вышеуказанному является предоставление Клиентской программе временной информации об идентификации и защите Отправителя 12 и Получателя 14 до подтверждения данных о пользовательской Кредитной Карте. Однако первый вариант является предпочтительной формой системы 10 ePostal, так как данные о Кредитной Карте используются как дополнительные средства подтверждения легальности пользователя для получения Аккаунта ePO 20 перед приемом Клиентской программой данных об идентификации и защите, даже если эти данные имеют временный статус. На этом завершается фаза D3 верификации при установке Клиентского программного обеспечения 22, 26.

Затем начинается фаза D4 активации. На этом этапе Клиентское программное обеспечение 22, 25 не рассматривается ePost Office 20 как активное. Клиентская программа полностью установлена на пользовательском терминале, но еще не активирована пользователем с пользовательским программным обеспечением электронной почты для отправки и приема сообщений eLetter. Это режим ожидания. В это время ePO 20 отправляет Активационное eLetter D5 по первичному адресу электронной почты пользователя на тот терминал, на котором установлено, зарегистрировано и верифицировано Клиентское программное обеспечение 22, 26. Клиентская программа проверяет входящую электронную почту, ожидая Активационное письмо eLetter. Когда Активационное eLetter приходит, Клиентская программа определяет его, анализирует данные в нем и сохраняет новые данные об идентификации и защите. Затем Клиентская программа передает в еРО 20 при помощи HTTP или другого подобного протокола TCP прикладной программы сообщение о том, что она получила Активационное eLetter и новые данные. еРО 20 отвечает Клиентской программе при помощи того же протокола, подобного HTTP, который Клиентская программа использует для связи с еРО 20, что еРО 20 записал информацию о том, что новый Аккаунт Активен. На этом завершается фаза D4 Активации при установке Клиентского программного обеспечения 22, 26. Теперь пользователь может использовать Клиентскую программу для доступа ко всем функциям и преимуществам системы ePostal.

Альтернативой этому способу активации Клиентского программного обеспечения является использование прямой связи D6 между Клиентской программой и еРО 20 через HTTP или другой подобный протокол TCP взамен использования Активационного eLetter. Это может быть выполнено после или вместо шага, на котором еРО 20 передает Клиентской программе, что Аккаунт был верифицирован, с временной информацией об идентификации и защите Отправителя 12 и Получателя 14. еРО 20 передает Клиентской программе при помощи того же протокола, подобного HTTP, который Клиентская программа использует для связи с еРО 20, временные данные об идентификации и защите для активации Аккаунта.

Использование Акгивационного eLetter D5 является предпочтительным вариантом системы 10 ePostal, так как оно подтверждает: что первичный адрес электронной почты, указанный пользователем на фазе D2 Регистрации при установке программного обеспечения, и установка программы действительны, обеспечивая дополнительное подтверждение легальности пользователя и, следовательно, Аккаунта.

В двух основных разделах выше, в которых описаны (1) разные альтернативные варианты отправки и приема сообщений eLetter через ePost Office 20 или без его участия и (2) установка, регистрация, верификация и активация Клиентского программного обеспечения 22, 26, было сделано важное упоминание о прямой связи. Эта прямая связь или передача данных происходит между клиентским программным обеспечением 22, 26 Отправителя 12 и Получателя 14 и еРО 20. Имеется два основных способа реализации и осуществления этих соединений. Эти альтернативные варианты показаны на фиг.15.

Первый вариант «N» (нормальный) в общих чертах представляет обычный процесс и компоненты безопасного соединения клиентских компьютеров с веб-серверами двух сторон в Интернете. Веб-браузер клиентского компьютера создает соединение TCP/IP с указанным пользователем URL и использует HTTP (и HTML) как протокол TCP прикладной программы, при помощи которого осуществляется связь с веб-сервером. Это обычно происходит через порт 25 на сервере при помощи использования cookies, в особенности для идентификации веб-сервера, с которым осуществляется связь. Для безопасных соединений при помощи HTTPS шифрование контролируется сервером и позволяет использовать внешние третьи стороны для ключей шифрования и цифровых сертификатов.

Хотя подобный вид процесса может использоваться в системе 10 связи ePostal на фиг.1, он не является предпочтительным. В предпочтительном варианте процесс работы системы 10 ePostal является специализированным и показан как альтернативный вариант «С» (Custom) на фиг.15. Усилена безопасность ключей шифрования и цифровых сертификатов благодаря независимости от любых третьих сторон и использованию управляемого собственного процесса шифрования. Также система является более гибкой, если идентификация Клиентской программы не зависит от использования cookies, которые могут быть удалены, если соединения не зависят только от одного протокола TCP прикладной программы, который может быть недоступен, и если не требуется конкретный веб-браузер. Система 10 связи ePostal может обеспечивать предпочтительный вариант структурирования и реализации этих соединений благодаря структуре системы 10 связи.

Предпочтительный вариант связи, специализированной для использования в настоящем изобретении и показанный как вариант «С» на фиг.15, дает преимущества, в частности в том, что Отправитель 12 и Получатель 14, использующие Клиентское программное обеспечение 22, 26, могут соединяться и передавать данные непосредственно на ePost Office 20 при помощи программного обеспечения 24, 24', и наоборот. В сущности система 10 ePostal может осуществлять соединения внутри самой себя, создавая, таким образом, сеть связи между Клиентским программным обеспечением 22, 26 ePostal, работающим на терминалах Отправителя 12 и Получателя 14, и программным обеспечением 24, 24' ePost Office 20, работающим на серверах ePostal. Во время этих прямых соединений между еРО 20 и Клиентской программой (которая работает как собственный веб-браузер) система 10 ePostal имитирует сеансы HTTPS, использует собственные одноразовые идентификаторы сеанса, вводит собственные одноразовые ключи шифрования/дешифрования сеанса и может использовать множество TCP протоколов прикладных программ благодаря использованию уникальной структуры данных сообщения, пригодной для использования этими протоколами, которая более подробно описана ниже. По существу система создает для своих пользователей виртуальное подобие интрасети, несмотря на то, что она использует Интернет и публично доступна.

Эта непосредственная связь (которая будет указываться как «прямая связь», «связь еРО» или «связь») важна для осуществления множества административных функций, функций помощи и поддержки, функций обслуживания Аккаунта и обработки eLetter между Отправителем 12, ePost Office 20 и Получателем 14, в числе которых:

- Создание нового аккаунта во время регистрации программного обеспечения

- Установка и активация Клиентского программного обеспечения 22, 26 на другом компьютере под уже существующим аккаунтом

- Автоматическое обновление Клиентского программного обеспечения 22, 26 Отправителя 12 и Получателя 14

- Просмотр и редактирование основной информации об аккаунте, хранящейся в еРО 20

- Покупка кредитов eLetter (кредиты eLetter используются для оплаты отправки сообщений eLetter)

- Проверка имеющихся кредитов eLetter и обновление локальных записей Клиентской программы

- Просмотр баланса кредитов eLetter и истории операций с кредитами

- Просмотр записей получателя о поощрительных кредитах, полученных за открытие сообщений eLetter

- Передача отчета в еРО 20 о получении eLetter

- Уведомление отправителя о получении eLetter

- Передача отчета в еРО 20 об открытии eLetter

- Уведомление отправителя об открытии eLetter

- Просмотр истории отправленных сообщений eLetter

- Просмотр всех деталей о конкретном отправленном eLetter

- Просмотр истории принятых сообщений eLetter

- Просмотр всех деталей о конкретном принятом eLetter

- Обновление локального списка расценок на услуги ePostal в Клиентской программе

- Проверка и обновление паролей и ключевых фраз

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

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

Как показано на фиг.16А и 16В, имеется пять основных шагов, которые Клиентская программа и еРО 20 используют для всех этих соединений прямой связи: открытие соединения связи С1, установка защищенного канала С2, аутентификация Клиентской программы С3, передача сообщений С4 и завершение сеанса С5. Каждый шаг состоит из различных подэтапов.

Открытие соединения связи С1

Клиентская программа сохранила URL и информацию о порте для прямой связи с еРО 20. Не всем Отправителям 12 и Получателям 14 требуется использовать одинаковый IP-адрес для еРО 20. Как говорилось ранее, обычно имеется множество групп серверов, работающих в различных местах и осуществляющих связь с Клиентскими программами и друг с другом. Кроме того, IP-адреса для серверов еРО 20 время от времени могут меняться (из соображений безопасности), и Клиентская программа через прямую связь получит от еРО 20 измененную информацию. Хотя может использоваться любой протокол TCP прикладной программы, предпочтительно, чтобы сперва Клиентская программа попыталась соединиться при помощи стандартного соединения HTTP через порт 80, так как наиболее вероятно, что он открыт. Если соединение установлено, Клиентская программа продолжает использовать HTTP для сеанса прямой связи. Если по каким-либо причинам соединение HTTP заканчивается неудачей, Клиентская программа подключается непосредственно к еРО 20 по протоколу SMTP через порт 25 со стандартными и индивидуальными тэгами команд SMTP. Например, при помощи SMTP, когда еРО 20 принимает соединение, клиентская программа проверяет соединение и отправляет еРО стандартную команду SMTP EHLO, которой Клиентская программа идентифицирует себя. еРО 20 понимает и принимает эту команду, после чего проверяет подлинность Клиентской программы. Если эти соединения SMTP установлены, Клиентская программа продолжает использовать SMTP для сеанса прямой связи.

Установка защищенного канала С2

Клиентская программа начинает работу с генерации для этого сеанса пары открытый/секретный ключ. Клиентская программа отправляет в еРО 20 запрос, содержащий открытый ключ из пары ключей. Хотя для шифрования этого первого сообщения запроса ключ еще не был установлен, вместо отправки сообщения в виде открытого текста система 10 ePostal предпочтительно использует перемешивание и замену символов, чтобы сделать сообщение более сложным для прочтения. еРО 20 фиксирует запрос и сохраняет открытый ключ. еРО 20 генерирует и сохраняет уникальный одноразовый идентификатор сеанса и симметричный ключ. Затем еРО 20 при помощи открытого ключа из первого запроса Клиентской программы шифрует идентификатор сеанса и симметричный ключ, переводит их в шестнадцатеричные символы и отправляет в качестве ответа обратно Клиентской программе (в этом примере здесь и далее упоминание перевода зашифрованных данных в шестнадцатеричные символы означает перезапись зашифрованных данных в шестнадцатеричный формат или другую подобную кодировку, такую как UUEncode, для обеспечения передачи зашифрованных данных). Клиентская программа получает от еРО 20 ответ и сохраняет идентификатор сеанса и симметричный ключ. Симметричный ключ, сгенерированный в этих шагах, будет использоваться для шифрования и расшифровки всех данных, передаваемых в оставшейся части сеанса связи. В дальнейших запросах Клиентская программа должна отправлять идентификатор сеанса в еРО 20, чтобы серверы ePostal смогли идентифицировать сеанс и, таким образом, используемый симметричный ключ. Альтернативой шифрования прямой связи является использование фиксированных пар открытого/секретного ключа между еРО 20 и Клиентской программой. Однако в ePostal предпочтительно использовать симметричное шифрование, так как оно быстрее асимметричного, и одноразовые ключи сеанса более безопасны, чем многократно используемые ключи.

Аутентификация клиентской программы С3

Клиентская программа формирует сообщение запроса с идентификатором сеанса и блоком данных, включающим идентификационный номер Клиентской программы, неизвестный даже ее пользователю, и хэш пользовательского пароля. Хэш пароля может храниться в Клиентской программе, или же пароль может запрашиваться у пользователя, после чего создается хэш. Затем блок данных шифруется при помощи симметричного ключа сеанса и переводится в шестнадцатеричный формат. Клиентская программа отправляет сообщение в еРО 20, который считывает идентификатор сеанса, находит соответствующий симметричный ключ и дешифрует блок данных. еРО 20 проверяет идентификационный номер Клиентской программы и хэш пароля исходя из собственных записей и запоминает, что этот сеанс аутентифицирован (или нет). Затем еРО 20 составляет и отправляет Клиентской программе ответ о том, что аутентификация принята (или нет). Это ответное сообщение еРО 20, отправляемое Клиентской программе, не содержит идентификатор сеанса, так как Клиентская программа в отличие от еРО 20, который видит эту прямую связь как асинхронную, отправляет в еРО 20 сообщение и затем ждет ответ. Альтернативные варианты аутентификации включают аутентификацию только одного или более двух параметров. Предпочтительный вариант системы ePostal в большинстве случаев, как описано выше, эффективно обеспечивает двойную аутентификацию Отправителя 12. Также для усиления защиты еРО 20 может периодически менять идентификаторы Клиентской программы.

Передача сообщений С4

До этого момента прямые связи только устанавливали средства для поддержания безопасности последующих соединений в этом сеансе и для аутентификации Клиентской программы в еРО 20. Передаваемые после этого сообщения помогают в фактическом выполнении некоторых рабочих и административных функций, которые влияют на реализацию особенностей премиум-услуг ePostal в системе 10 ePostal. Эти сообщения подготавливаются и передаются таким же образом, как и два сообщения на шаге «Аутентификация Клиентской программы» С3, описанном выше. Клиентская программа составляет и отправляет в еРО 20 сообщение запроса. Сообщение содержит идентификатор сеанса, поле данных, указывающее размер блока зашифрованных данных, и блок зашифрованных данных, зашифрованный при помощи симметричного ключа сеанса и переведенный в шестнадцатеричный формат. Данные в сообщении имеют уникальную для системы 10 связи ePostal структуру, соответствующую ее требованиям к данным, потребностям и возможностям связи и системе 10 связи ePostal в данном изобретении. После получения в еРО 20 сообщения запроса Клиентской программы еРО 20 дешифрует и обрабатывает данные в соответствии с инструкциями, которые содержатся в блоке данных. Затем еРО 20 подготавливает ответное сообщение для Клиентской программы, которое, как и сообщение запроса Клиентской программы, имеет уникальную для системы 10 связи ePostal структуру. Ответное сообщение еРО 20 для Клиентской программы на данном шаге С4, как и на шаге СЗ, и как указывалось выше в описании шага СЗ, не содержит идентификатор сессии, так как Клиентская программа в отличие от еРО 20, который видит эту прямую связь как асинхронную, отправляет в еРО 20 сообщение и затем ждет ответ. Ответ еРО 20 содержит поле данных, указывающее размер блока зашифрованных данных, и блок зашифрованных данных, зашифрованный при помощи симметричного ключа сеанса и переведенный в шестнадцатеричный формат. С этого момента в настоящем описании изобретения, когда данные указываются как зашифрованные для любой передачи, это означает, что блок зашифрованных данных переведен в шестнадцатеричный или подобный формат с целью преобразования зашифрованных данных таким образом, чтобы их можно было передавать по прямой связи, как описывалось ранее. Затем еРО 20 передает ответное сообщение Клиентской программе, которая дешифрует блок данных и обрабатывает данные в соответствии с инструкциями, содержащимися в блоке данных.

Завершение соединения С5

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

Помимо этого для некоторых вариантов прямой связи набор шагов может отличаться от описанных выше. Во многих случаях система 10 ePostal будет работать лучше, когда в ней различными способами сочетаются шаг 3 с шагом 4 и/или шаг 4 с шагом 5. Конкретное сочетание зависит от назначения используемой прямой связи и от того, каким образом можно лучше составить комбинации данных и инструкции для их использования в блоках данных с целью наиболее эффективного и гарантированного выполнения функций ePostal. Например, может быть целесообразно аутентифицировать клиентскую программу и обрабатывать данные от нее и отправляемые ей ответы в одном наборе соединений запроса и ответа между Клиентской программой и еРО 20.

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

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

Структура зашифрованного блока данных для системы 10 связи ePostal также уникальна и показана на фиг.17. Во-первых, в блоке 40 данных содержится блок 42 случайного шума, размер которого известен; эти данные помогают в эффективности защиты шифрования. Во-вторых, используется тип 44 сообщения, который указывает получателю тип или назначение сообщения запроса или ответного сообщения; при помощи этого типа сообщения получателю известно, какие данные следует ожидать в остальном блоке данных и что с ними делать. В-третьих, имеются пары длины 46 строки данных и соответствующей строкой 48 данных; эти строки 46, 48 являются данными, которые обрабатываются для помощи в выполнении рабочих и административных функций, влияющих на реализацию особенностей ePostal; в зависимости от типа сообщения может иметься любое количество пар строк данных и их длин. Эти поля данных, как описывалось ранее, обеспечивают одинаковую структуру сообщений запроса и ответных сообщений. С одинаковыми структурами сообщений в стандартных пакетах протокола TCP их обработка аналогична независимо от того, передаются они по HTTP, SMTP или какому-либо другому протоколу TCP прикладной программы. При использовании HTTP большинство запросов от Клиентской программы к еРО будут использовать команды GET или POST вместе с полем данных, а ответы от еРО будут использовать команду RESPONSE с полем данных, упакованным в стандартные тэги HTML и тела для индикации того, что это сообщения HTML. При использовании SMTP большинство запросов к еРО будут использовать команду EPSA (специализированная команда SMTP для системы 10 связи, известная для еРО 20) с полем данных, заканчивающимся пробелом, строку END и /r/n, a ответы от еРО будут использовать команду RESPONSE с полем данных, заканчивающимся пробелом, строку END и \r\n. Имеется множество возможных альтернативных комбинаций структурирования и обработки данных в сообщениях запроса и ответных сообщениях. В поле данных может содержаться различная информация или данные, их последовательность может отличаться; могут быть альтернативные варианты сообщения получателю, какие данные он должен ожидать в сообщении и что необходимо с ними делать; также могут быть другие способы шифрования этих сообщений. Однако, так как описанный выше способ является наиболее простым, наиболее эффективным и гибким благодаря использованию нескольких протоколов TCP, в настоящее время он является предпочтительной схемой работы системы 10 ePostal.

В вышеприведенном описании прямой связи шаг С3 на фиг.16А является шагом аутентификации Клиентской программы. Это значит, что Отправитель 12, указанный выше как терминал, и его Клиентское программное обеспечение ePostal аутентифицированы. Отдельное лицо или пользователь, который открыл Аккаунт при помощи программного обеспечения ePostal у Отправителя 12, также может подтвердить себя как лицо, в настоящее время отправляющее eLetter из Клиентской программы. Отдельный пользователь может также иметь Аккаунт на более чем одном терминале с Клиентским программным обеспечением ePostal, например на настольном компьютере в офисе и ноутбуке для путешествий. Отдельный пользователь также может иметь несколько Аккаунтов на нескольких терминалах, облегчающих работу с ePOst Office 20 из личного и рабочего Аккаунтов с любого из этих терминалов. Помимо этого, отдельный пользователь может использовать несколько адресов электронной почты на любом из его Аккаунтов ePostal на любом из его терминалов. Для этого в системе 10 ePostal все идентификационные номера Аккаунтов конкретного пользователя, терминалы с Клиентским программным обеспечением и адреса электронной почты должны быть связаны друг с другом в ePost Office 20, таким образом все соединения прямой связи и другие способы систем связи ePostal также могут согласовывать и отслеживать эти идентификационные номера и взаимосвязи. Альтернативой вышеуказанной службе является ограничение количества Аккаунтов, терминалов с Клиентским программным обеспечением и адресов электронной почты, которое отдельный пользователь может иметь в системе 10 ePostal. Хотя эта альтернатива с ограничением более проста для управления и отслеживания, в настоящее время предпочтительной схемой работы системы 10 ePostal является способ с многочисленными Аккаунтами, терминалами и адресами электронной почты, так как он обеспечивает отдельному пользователю намного более надежные и всеобъемлющие услуги.

Отправитель 12 на фиг.1 может выбрать отправку электронной почты через Интернет или традиционным способом, или при помощи ePost Office 20. Для использования ePost Office 20, описанного в настоящем изобретении, пользователям в варианте изобретения на фиг.1 требуется выполнить немного больше действий по сравнению с тем, что они делают при отправке или получении традиционной электронной почты. Например, ссылаясь на фиг.2А и 2В, пользователь отправителя 12 открывает почтовую программу S1 и создает электронное письмо, шаг S2, обычным образом (с вложением или без него). Пользователю Отправителя 12 требуется только нажать (шаг S3) на значок и пройти (шаг S4) простую последовательность вариантов выбора услуг, которые он хочет использовать для электронной почты в системе ePostal, делая щелчки «мышью» для продолжения, подтверждения и отправки eLetter с собственного ПК отправителя (все выполняется электронным образом и внешне одинаково для пользователя отправителя) через собственного Интернет-провайдера 19 Отправителя, Интернет 18 и Интернет-провайдера 19 Получателя пользователю Получателя 14, как показано на фиг.1.

На фиг.2А и 2В показан и описан пример программного обеспечения 22 Отправителя, соответствующего настоящему изобретению, которое установлено или выполняется на ПК Отправителя или подобном устройстве. Программное обеспечение 22 Отправителя отображает, что пользователь Отправителя 12 зарегистрирован в службе ePostal и имеет в ней аккаунт. На фиг.2А, 2В, 3А-С, 4В, 6 и 7 соответственно показаны и описаны примеры программного обеспечения 24, 24', соответствующего настоящему изобретению, которое реализует ePost Office 20 согласно данному изобретению. На фиг.4А-1 и 4А-2 показан и описан пример программного обеспечения 26 Получателя, соответствующего настоящему изобретению, которое установлено или выполняется на ПК Получателя 14 или подобном устройстве. Программное обеспечение 26 Получателя отображает, что пользователь Получателя 14 зарегистрирован в службе ePostal и имеет в ней аккаунт. Специалисты должны понимать, что конкретная реализация кода программного обеспечения 22, 24, 24' и 26 будет зависеть от рабочей среды, например от типа аппаратного обеспечения, системного и прикладного программного обеспечения, типа системы связи и ее рабочего протокола, интерфейсов и использования функциональных возможностей, таких как шифрование, фильтры и сетевые экраны. Пользователи Системы ePostal могут иметь различные сочетания операционных систем, браузеров и почтовых программ. Данное изобретение использует интерфейсы, дополнения или различные наборы процедур и программ, каждая из которых предназначена для различных комбинаций операционных систем и прикладных программ (электронная почта и браузер) отправителя и получателя и которые также действуют для согласования через линии связи с почтовым сервером 20.

Как показано на фиг.1, 2А, 2В, 3А-3С, 4А-1,4А-2, 4В, 6 и 7 или со ссылкой на них, ePost Office 20 и его программное обеспечение 24, 24' в сочетании с программным обеспечением 22 и 26 выполняет функции обработки почты традиционных почтовых серверов в виде полностью электронного процесса. Более конкретно, настоящее изобретение, как изображено на фиг.2А, 2В, 3А-3С, 4А-1, 4А-2, 4В, 6 и 7, работает для обеспечения следующего:

- Помощь пользователям Отправителя 12 в выборе предоставляемых услуг

-Сбор сообщений eLetter от Отправителей 12 и их доставка на ePost Office 20

- Получение и одобрение сообщений eLetter системой ePost Office 20

- Тщательная проверка eLetter в целях безопасности

- Аутентификация Отправителя 12 и сертификация пользователя Отправителя 12

- Сбор оплаты для обработки системой сообщений eLetter

- Использование услуг и обработка сообщений eLetter

- Уменьшение или фильтрация количества потенциальных сообщений eLetter

- Идентификация, маркировка и назначение приоритетов сообщений eLetter

- Индикация и маркировка даты и времени обработки ePost Office 20

- Защита процесса получения, передачи и доставки сообщений eLetter

- Доставка сообщений eLetter Получателям 14

- Сертификация открытия сообщений пользователем Получателя 14

- Сбор ответов/отчетов о получении от Получателей 14, если это необходимо

- Уведомление Отправителей 12 об ответах Получателей 14, если это необходимо

- Другие специальные услуги, такие как:

- Хранение сообщений eLetter, пока пользователь Получателя 14 длительное время находится вдалеке от своего почтового ящика/компьютера и почтовой программы

- Предоставление опций для доступа к ePost Office 20, таких как переход к «окну» или веб-сайту ePost Office 20 вместо работы через собственный почтовый ящик/почтовую программу

- Обеспечение компаниям возможности измерять, собирать и контролировать аспекты процесса ePostal на их собственных сайтах.

Более конкретно, функции программного обеспечения 22 Отправителя 12, как описано на фиг.2А и 2 В или со ссылкой на них, включают следующее:

- Помощь пользователю Отправителя 12 на шаге S4 в его собственной почтовой программе в выборе услуг ePostal, которые будут применены к его электронной почте, таких как:

- Специальные индикаторы маркировки, ценности и приоритета ePostal, которые дифференцируют сообщения eLetter от всей остальной электронной почты

- Шифрование

- Сертификация пользователя Отправителя 12 в отличие от сертификации только Отправителя (Аутентификация Отправителя 12 стандартна для всех сообщений eLetter)

- Уведомление Отправителя 12 о получении и открытии сообщений eLetter Получателем 14

- Сертификация открытия сообщений пользователем Получателя 14

- Заранее оплаченные ответы для отправки ответа пользователя Получателя 14 на eLetter Отправителя 12 обратно через систему ePostal

- Доставка пользователю Получателя 14 печатной копии

- Подготовка и обработка сообщений eLetter для отправки на ePost Office 20

- Осуществление необходимой и подходящей связи с ePost Office 20

- Определение наличия у Получателя аккаунта в системе ePostal и, в случае его отсутствия, определение выбора Отправителя 12

- Проверка наличия у Отправителя 12 достаточного количества кредитов для использования системы ePostal и, если их не хватает, получение большего количества кредитов

- Маркировка сообщений eLetter информацией о выбранных услугах и другой информацией для ePost Office 20

- Шифрование сообщений eLetter, если это необходимо

- Осуществление сертификации пользователя Отправителя 12, если это необходимо

- Определение соответствующего процесса для отправки сообщений eLetter и/или данных eLetter на ePost Office 20, например, на основе обычной электронной почты SMTP или стандартного обмена сообщениями по HTTP

- Поддержка хранилища зашифрованных сообщений eLetter для подтверждения их содержимого, если это указано Отправителем 12

- Отправка сообщений eLetter на ePost Office 20

- Сортировка отправленных сообщений eLetter в специальных папках ePostal

- Отслеживание вернувшихся уведомлений со связанными отправленными сообщениями eLetter

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

- Помощь Отправителю 12 в управлении связью и взаимодействием ePostal с ePost Office 20

- Бесшовная работа с веб-браузером и почтовой программой Отправителя 12.

Относительно примера программного обеспечения 22 Отправителя, описанного выше и показанного на фиг.2А и 2В, ниже со ссылкой на фиг.18А и 18В описан пример последовательности шагов обработки и структура предпочтительной в настоящее время системы.

Альтернативные варианты того, как начать использовать услуги ePostal на шаге S1 фиг.18А из почтовой программы и как выбрать конкретные услуги, включают следующее:

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

- Также в окне нового сообщения имеются варианты способа выбора использования услуг ePostal - щелчком по значку на панели инструментов или по строке в списке выпадающего меню. Предпочтительно система 10 ePostal объединяет оба варианта для обеспечения более гибкого и простого использования услуг пользователем.

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

Надо заметить, что, как говорилось ранее, доступные варианты выбора из нескольких альтернативных вариантов для выполнения функций ePostal зависят от сочетания конкретной операционной системы, почтовой программы и веб-браузера Отправителя 12 и Получателя 14. Конкретная имеющаяся версия программного обеспечения 22 и 24 ePostal должна работать с существующей комбинацией операционной системы, почтовой программы и веб-браузера. Как упоминалось ранее, правильная версия программного обеспечения ePostal определяется во время установки программного обеспечения 22 и 24 после того, как ePost Office 20 проанализирует информацию, предоставленную пользователем о его операционной системе, почтовой программе и веб-браузере, и выполнит какую-либо контрольную проверку этих данных.

Относительно примера программного обеспечения 22 отправителя (описано выше и показано на фиг.2А и 2В) и последовательности операций отправителя и предпочтительных вариантов (показано на фиг.18А и 18В) Отправитель 12 начинает обрабатывать на шаге SP2 новое eLetter после того, как пользователь выберет используемые услуги и щелкнет «мышью» для отправки электронного письма через систему ePostal. Опять же, здесь имеются альтернативы и варианты выбора способа осуществления Отправителем 12 этой обработки.

Альтернативные варианты реализации обработки данных Отправителем 12 включают способ, которым Отправитель 12 определяет стоимость выбранных услуг и количество необходимых кредитов ePostal. В еРО 20 имеется официальный банк записей о балансе и истории кредитов ePostal для каждого аккаунта Отправителя 12. Во время обработки данных Отправитель 12 может использовать прямую связь, чтобы в банке кредитов в еРО 20 проверить, имеет ли Отправитель 12 достаточно кредитов ePostal для обработки eLetter на шаге S3. В качестве альтернативы Отправитель 12 может иметь локальный банк кредитов ePostal, который отслеживает на шаге S4 баланс и историю использования кредитов ePOstal для каждого Аккаунта на Отправителе 12. Предпочтительно система 10 ePostal имеет и локальный банк у Отправителя 12, и официальный банк кредитов в еРО 20, так как Отправитель 12 может не быть в режиме «онлайн» или может не иметь возможности выйти в «онлайн», чтобы проверить баланс кредитов Аккаунтов Отправителя 12 в еРО 20. При помощи локального банка у Отправителя 12 появляется возможность оценки официального баланса кредитов Аккаунта, который хранится в еРО 20, без перехода в режим «онлайн». Предпочтительно Отправитель 12 проверяет баланс кредитов в еРО 20 при помощи прямой связи, и если Отправитель 12 не может подключиться к сети, он имеет локальный банк кредитов для оценки баланса кредитов Аккаунта для нового eLetter. Если баланс кредитов недостаточен для нового eLetter на шаге S5, программное обеспечение 22 Отправителя 12 информирует пользователя о необходимости приобрести новые кредиты и запускает процесс приобретения кредитов ePostal при помощи прямой связи с еРО 20. Согласно другому альтернативному варианту пользователь приобретает кредиты ePostal, переходя на веб-сайт еРО 20 при помощи веб-браузера, а затем использует программное обеспечение 24 ePost Office 20, как показано на фиг.3А-С. Предпочтительно пользователю должны быть доступны обе альтернативы приобретения кредитов - через прямую связь и на веб-сайте.

В другом альтернативном варианте обработки Отправителем 12 нового eLetter Отправитель 12 определяет, связан ли адрес электронной почты каждого получателя eLetter с аккаунтом какого-либо пользователя на ePostal 20, например, посредством использования Отправителем 12 прямой связи с еРО 20. Альтернативой проверке статуса каждого получателя в еРО 20 является отсутствие проверки статуса почтового адреса получателя на шаге SP6. Выбранный вариант работы системы 10 ePostal зависит от политики конфиденциальности руководства системы 10 ePostal, относящейся к раскрытию информации о пользователе другим пользователям.

Другим альтернативным вариантом реализации настоящего изобретения является изменение порядка проверки - сначала проверяется адрес электронной почты получателя, а затем кредиты ePostal. Во многих случаях порядок, в котором выполняются отдельные шаги обработки сообщения eLetter, не имеет большого значения. Фактически, как должно быть ясно специалистам, имеется много вариантов осуществления этого. С другой стороны, имеется несколько шагов обработки, которые имеют свойственный им порядок, иначе они не смогут быть выполнены. Важность последовательности зависит от конкретного шага обработки, который может зависеть от версии программного обеспечения 22, установленного у Отправителя 12, выбранных пользователем услуг ePostal и других переменных параметров, которые должны быть понятны специалистам, как показано на шаге SP7.

Относительно примера программного обеспечения 22 Отправителя (описано выше и показано на фиг.2А и 2В) и последовательности операций Отправителя и предпочтительных способов (показано на фиг.18А и 18В), обработка eLetter Отправителем 12 также зависит на шаге SP7 от выбранных шагов отправки, обработки и доставки сообщения eLetter от Отправителя 12 Получателю 14, как описывалось ранее. Подводя краткий итог, имеется два основных альтернативных варианта отправки сообщения eLetter - или через ePost Office 20, или обходя еРО 20 и отправляя сообщение eLetter непосредственно Получателю 14. Другие альтернативы, которые являются подвариантами этих основных альтернатив, отличаются количеством данных ePostal, которые отправляются вместе с сообщением eLetter и необходимы для обработки eLetter после отправки Отправителем 12 и для доставки Получателю 14. Во многих случаях система 10 ePostal предпочтительно реализуется исходя из нижеуказанных соображений, таких как:

- Отправитель 12 посылает в еРО 20 сообщение eLetter и большую часть (если не все) данных для обработки ePostal через почтовый сервер Интернет-провайдера 19 Отправителя, а их оставшуюся часть он посылает в еРО 20 через прямую связь ePostal.

- Затем еРО 20 посылает сообщение eLetter и большую часть (если не все) данных для обработки ePostal Получателю 14 через почтовый сервер Интернет-провайдера 19 Получателя, а их оставшуюся часть он посылает Получателю 14 через прямую связь ePostal.

Типичные шаги обработки eLetter у Отправителя 12 на шаге SP8 описаны ниже и показаны на фиг.18А и 18В. Они в основном относятся ко всем возможным альтернативным вариантам отправки eLetter от Отправителя 12 Получателю 14, включая основной предпочтительный вариант реализации, которым является отправка сообщений eLetter и большей части (если не всех) данных для обработки ePostal от Отправителя 12 Получателю 14 через еРО 20.

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

- структура системы для реализации описанных выше и ниже функциональных возможностей для обработки eLetter у Отправителя 12;

- структура системы для реализации описанных выше и ниже функциональных возможностей обработки в еРО 20;

- структура системы для реализации описанных выше и ниже функциональных возможностей для получения и обработки eLetter Получателем 14;

- реализация операций для прямой связи, которые были описаны выше; и

- информация, передаваемая из еРО 20 Отправителю 12 и Получателю 14 по прямой связи, через eLetter или другое средство связи ePostal, относительно того, какой конкретный вариант отправки eLetter Получателю 14 должен использовать Отправитель 12.

Отправитель 12 обрабатывает eLetter таким образом, что eLetter подготавливается с достаточными данными и инструкциями ePostal, благодаря которым ePost Office 20 и система 10 ePostal (включая Получателя 14) будут знать, как продолжить обработку и доставку eLetter Получателю 14. Эти данные могут быть включены в различные места eLetter, такие как тема или тело сообщения, в качестве вложения (которое может восприниматься как часть тела сообщения) или в качестве специализированного заголовка. Предпочтительно система 10 использует специализированный заголовок или несколько специализированных заголовков на шаге SP9. Если конкретная почтовая программа Отправителя 12 не допускает использование специализированных заголовков или требует, чтобы данные находились в одном месте, то в этом случае будет использоваться другое место.

Отправитель 12 на шаге SP9 подготавливает специализированный заголовок для включения в него не только данных для обработки eLetter в еРО 20, но и данных для проверки и аутентификации eLetter. Проверка показывает, что сообщение eLetter не было изменено при передаче от Отправителя 12 в еРО 20, а аутентификация показывает, что письмо eLetter действительно создано Отправителем 12. Имеется множество последовательностей, в которых eLetter может быть обработано в еРО 20, и это значит, что есть много различных способов компоновки данных в специализированном заголовке. В предпочтительном варианте реализации настоящего изобретения последовательность действий еРО 20 включает первоначальную идентификацию, проверку и аутентификацию eLetter и последующее выполнение остальных действий по обработке. Так делается потому, что нет смысла полностью обрабатывать электронное письмо в еРО 20, если оно исходит не от подлинного пользовательского Аккаунта ePostal; такое письмо не будет являться сообщением eLetter. Поэтому данные в специализированном заголовке для идентификации, проверки и аутентификации должны быть доступны до, или хотя бы во время, обработки данных.

Пример структуры специализированного заголовка показан и описан на фиг.19 как части 1-3. Имеется три части - 19-1, 19-2 и 19-3. Альтернативно эти три части могут формировать один специализированный заголовок или являться тремя или более специализированными заголовками. Предпочтительно имеется один специализированный заголовок, состоящий из трех частей. Физическая последовательность трех частей специализированного заголовка обычно не имеет значения. Однако предпочтительно, чтобы они располагались в той логической последовательности, в которой они используются.

Часть 1, фиг.19-1 содержит идентификационные номера Отправителя 12. Эти номера идентифицируют Отправителя 12 в еРО 20 при поступлении eLetter в еРО 20. Эти номера сообщают еРО 20, какой ключ шифрования необходимо использовать для дешифрования 2-й части специализированного заголовка.

Часть 2, фиг.19-2 содержит код дайджеста сообщения MDC (Message Digest Code) и ключ шифрования для дешифрования 3-й Части специализированного заголовка. MDC используется для проверки eLetter, когда оно поступает в еРО 20. Также это один из способов определения того, что eLetter пришло от Отправителя 12.

Часть 3, фиг.19-3 содержит данные для обработки ePostal, включающие:

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

- Данные, указывающие услуги ePostal, которые были выбраны Отправителем 12.

- Данные об Отправителе 12 и Получателе 14, такие как идентификационные номера и адреса электронной почты. Информация «Кому», «копия» и «скрытая копия» удаляется из заголовков eLetter и помещается в 3-ю Часть вместе с ее хэшем. Информация «От кого» и «Адрес для ответа» также помещается в 3-ю часть вместе с ее хэшем. Адрес электронной почты SMTP на ePost Office 20 для этого Отправителя 12 заменяет настоящий адрес электронной почты получателя в заголовке «Кому», позволяя перенаправлять eLetter в ePost Office 20. Хэши этих данных обеспечивают возможность дополнительных способов проверки защиты eLetter и аутентификации Отправителя 12.

- Ключ шифрования для дешифрования тела сообщения eLetter, если услуга шифрования была выбрана.

Хотя это не показано на фиг.19, необходимо понимать, что любые данные в Частях 1, 2 и 3 должны содержать размер данных, если еРО 20 не будет получать эту информацию каким-либо другим способом. Кроме того, хотя это также не показано на фиг.19, из соображений защиты в Частях 2 и 3 перед тем, как они будут зашифрованы, может быть добавлен случайный шум. Как указывалось в описании прямых связей, так как в специализированном заголовке будут находиться зашифрованные данные, он должен быть переведен для передачи в шестнадцатеричный формат.

В альтернативном варианте заголовок может содержать только две части, а не три, или более трех частей. Две части - это минимальное количество, так как одна часть должна быть в открытом тексте, чтобы еРО 20 смог прочесть идентификационные номера Отправителя 12 и таким образом узнать, какой ключ шифрования необходим для дешифрования остальной части заголовка. Однако три части обеспечивают дополнительную защиту, так как это позволяет использовать другое шифрование данных в 3-й Части с другим ключом шифрования, который усиливает защиту и при дешифровании может обеспечить дополнительное подтверждение проверки и аутентификации, в отличие от использования данных только во 2-й Части. Наличие более 3-х частей и большего количества этапов шифрования может обеспечить лучшую защиту, но такая структура не является необходимой за исключением нестандартных ситуаций. Предпочтительная структура заголовка и способ работы системы 10 ePostal - это использование специализированного заголовка из трех частей, как показано на фиг.19, на шаге SP9 фиг.18 А и как описано выше.

В примере программного обеспечения 22 Отправителя (описан выше со ссылками на фиг.2А и 2В) и примере обработки данных отправителем (описан выше со ссылкой на фиг.18А и 18В) специализированный заголовок используется как часть обработки eLetter; исходная информация «Кому/копия/скрытая копия» удалена из заголовков и помещена в 3-ю Часть специализированного заголовка на шаге SP10, фиг.18А. Затем на шаге SP11 в заголовок «Кому» помещается адрес электронной почты еРО 20, направляющий eLetter в еРО 20. Альтернативой SMTP для отправки eLetter является использование ретрансляционной маршрутизации SMTP, при которой в заголовках «Кому», «копия» и «скрытая копия» сохраняются оригинальные адреса Получателя 14. В данном варианте сообщение eLetter для каждого Получателя 14 принимается в еРО 20 по отдельности, и затем еРО 20 обрабатывает и перенаправляет каждое из них Получателям 14. Этот вариант, как будет подробнее описано позже, может упростить некоторую обработку в еРО 20 сообщений eLetter для нескольких получателей, но доставка сообщений eLetter в еРО 20 намного более ненадежна, так как нет гарантий, что Интернет-провайдер 19 Отправителя будет ретранслировать каждое или какое-либо из сообщений eLetter с разными адресами получателей в еРО 20. Поэтому система 10 ePostal предпочтительно отправляет сообщения, как указывалось выше, посредством удаления адресов Получателей 14 из заголовков «Кому», «копия» и «скрытая копия», помещая их в 3-ю часть специализированного заголовка на шаге SP10 и заменяя на шаге SP11 в заголовок «Кому» заданным адресом еРО 20 для этого Отправителя 12, в результате чего eLetter отправляется непосредственно в еРО 20. При использовании предпочтительной структуры система ePostal обеспечивает простую адресацию информации, соответствующую реальному маршруту передачи. Это предотвращает другие потенциальные проблемы, которые может вызвать ретрансляция.

В следующем далее обсуждении примера программного обеспечения 22 Отправителя (фиг.2А и 2В), выполнения обработки отправителем и предпочтительных вариантов реализации (фиг.18А и 18В) и вышеприведенном обсуждении подготовки Отправителем 12 специализированного заголовка, как части обработки eLetter, описывается использование ключей шифрования и дешифрования. Фактически, шифрование необходимо во многих местах в системе 10 связи ePostal, в числе которых:

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

- специализированные заголовки eLetter, которые содержат данные для обработки ePostal

- соединения прямой связи

- системные данные ePostal, хранящиеся в Клиентской программе, на сетевом уровне и в ePost Office 20.

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

Средства для любого из процессов шифрования и дешифрования, реализуемые программным обеспечением системы 10 ePostal, в Клиентском программном обеспечении, на сетевом уровне или на ePost Office 20 зависят от Клиентского программного обеспечения, программной операционной среды сети ePostal (на фиг.8) и потребностей и ресурсов системы 10 ePostal для совместимости криптографических систем. Предпочтительный вариант также зависит от относительной безопасности и скорости выбранного алгоритма шифрования/дешифрования. Чаще всего предпочтительным вариантом системы 10 ePostal для шифрования тела сообщения eLetter является использование симметричного алгоритма и достаточно длинного ключа, выбранного для предоставления необходимого уровня защиты. Система 10 ePostal использует алгоритм, который может быть вызван из операционной системы Отправителя 12. Если такой алгоритм или библиотека недоступны, в программном обеспечении 22 Отправителя предоставляется достаточный симметричный алгоритм. Эти алгоритмы и преимущества могут быть применены для всех криптографических функций, выполняемых системой 10 ePostal, таких как шифрование, дешифрование и функции хэширования. Также бывают ситуации, в которых отдельные функции системы 10 ePostal могут потребовать использования какой-либо другой предпочтительной альтернативы. Например, когда в прямой связи между Клиентской программой и еРО 20 используется пара открытого/секретного ключей. Также, как указывалось ранее, необходимо понимать, что всякий раз при передаче системой 10 ePostal зашифрованных данных по Интернету зашифрованные данные переводятся в шестнадцатеричный формат или другую подобную форму, такую как UUEncode, для обеспечения возможности их передачи.

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

Как описано выше, Отправитель 12 выполняет шифрование при помощи одноразового, достаточно сложного симметричного ключа и алгоритма посредством использования в качестве ресурса криптографической библиотеки операционной системы Отправителя 12. Эти библиотека и алгоритм известны в еРО 20. После шифрования сообщения на шаге SP13 Отправитель 12 помещает симметричный ключ в 3-ю часть специализированного заголовка eLetter на шаге SP14. Необходимо заметить, что перед шифрованием тела сообщения eLetter Отправитель 12 также создает хэш MDC тела сообщения на шаге SP12.

Отправитель 12 завершает составление 3-й Части специализированного заголовка на шаге SP15, включая все данные, показанные в качестве примера на фиг.19. Отправитель 12 предпочтительно шифрует всю 3-ю Часть при помощи одноразового, достаточно сложного симметричного ключа и алгоритма посредством использования в качестве ресурса криптографической библиотеки операционной системы Отправителя 12 на шаге SP16.

После шифрования 3-й Части Отправитель 12 составляет 2-ю Часть специализированного заголовка на шаге SP17, помещая в него симметричный ключ, используемый для шифрования 3-й Части, на шаге SP 18. Отправитель 12 заполняет 2-ю Часть, как показано на фиг.19 и описано выше, данными MDC на шаге SP18. Затем Отправитель 12 шифрует 2-ю Часть специализированного заголовка на шаге SP21.

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

В первом варианте во время активации клиентского программного обеспечения на Отправителе 12 клиентская программа сохраняет на Отправителе 12 ключ шифрования, который может быть использован для шифрования 2-й Части. Это может быть или пара из открытого/секретного ключей, где 2-я Часть шифруется при помощи открытого ключа Отправителя 12, соответствующего секретному ключу еРО 20 для дешифрования, или это может быть симметричный ключ, где еРО 20 также имеет симметричный ключ. Преимущественно в системе 10 ePostal, при выборе между асимметричным и симметричным вариантами, используется симметричный ключ, так как симметричные алгоритмы быстрее и относительно сильнее.

Во втором альтернативном варианте Отправитель 12, если он находится в режиме «онлайн», использует прямую связь с еРО 20 для получения от еРО 20 одноразового симметричного ключа, который будет использоваться для шифрования 2-й Части специализированного заголовка конкретно этого eLetter.

Предпочтительно система 10 ePostal может использовать обе альтернативы. Если Отправитель 12 находится в режиме «онлайн», он на шаге SP19 использует прямую связь с еРО 20 для получения одноразового симметричного ключа и предоставляет еРО 20 определенные идентификационные номера Отправителя 12, связанные с конкретным одноразовым ключом и eLetter. Если Отправитель 12 не может перейти в «онлайн», он использует сохраненный симметричный ключ на шаге SP20 для шифрования 2-й Части специализированного заголовка. В обоих случаях идентификационные номера Отправителя 12 в 1-й Части специализированного заголовка указывают еРО 20, какой ключ шифрования должен использоваться для дешифрования 2-й Части, когда eLetter и данные для его обработки ePostal в специализированном заголовке поступают в еРО 20. Симметричный ключ, хранящийся в Клиентской программе и в еРО, предназначенный для шифрования и дешифрования 2-й Части, может регулярно меняться из соображений безопасности.

Отправитель 12 завершает обработку eLetter, помещая идентификационные номера Отправителя 12 в 1-ю Часть специализированного заголовка на шаге SP22. Отправитель 12 на шаге SP23 помещает специализированный заголовок в eLetter и отправляет по-новому обработанное eLetter в папку «исходящие» почтовой программы Отправителя 12 или папку хранения исходящей почты на шаге SP24. Почтовая программа ожидает «транспортного» события отправки/получения электронной почты на шаге SP26, при котором почтовая программа соединяется с почтовым сервером Интернет-провайдера 19 Отправителя для выполнения «транспортной» отправки eLetter из папки «исходящие». Альтернатива этому процессу такова, что, если это возможно, Отправитель 12 помещает eLetter в папку «исходящие» почтовой программы до обработки его Отправителем 12. Затем, когда возникает «транспортное» событие отправки/получения, Отправитель 12 обрабатывает eLetter, и оно передается Интернет-провайдеру 19 Отправителя.

Альтернатива ожидания события отправки/получения для обработки eLetter является предпочтительной, так как:

после этого eLetter, находящееся в обработанном состоянии в папке «отправленные» почтовой программы, не зависит от времени и не может быть просмотрено,

терминал Отправителя 12 в действующем «транспортном» состоянии находится в режиме «онлайн», и Отправитель 12 может использовать преимущества обработки eLetter, которая требует подключения к сети терминала Отправителя 12.

Хотя предпочтительным вариантом является ожидание, некоторые сочетания операционных систем, почтовых программ и веб-браузеров не позволяют Клиентской программе обрабатывать eLetter во время «транспортного» события. Поэтому первая альтернатива обработки перед «транспортным» событием является выбираемой опцией. При необходимости выполнения обработки перед «транспортным» событием обработанное eLetter какое-то время будет находиться в папке «отправленные» почтовой программы. На протяжении этого времени Отправитель 12 может по запросу пользователя извлечь обработанное письмо из папки «отправленные» почтовой программы и обеспечить пользователю возможность изменить получателей, тему, тело сообщения eLetter, а также выбранные для него услуги ePostal, включая отмену услуг ePostal для eLetter, на шаге SP25.

После того как eLetter будет отправлено Интернет-провайдеру 19 Отправителя, Отправитель 12 идентифицирует отправленное eLetter на шаге SP27, восстанавливает исходные данные для адресов электронной почты «кому», «копия» и «скрытая копия» на шаге SP28, дешифрует тело сообщения eLetter, если оно было зашифровано, на шаге SP 29 и сортирует сообщения eLetter в соответствующей папке отправленных элементов ePostal на шаге SP30. Также он осуществляет любую специальную сортировку, которая может быть предложена пользователю посредством элементов меню настроек и параметров пользователя. Кроме того, Отправитель 12 обновляет локальный банк кредитов для кредитов ePostal, используемых для отправки eLetter.

Относительно примера программного обеспечения 22 Отправителя (фиг.2А и 2В) и предпочтительных шагов обработки отправителя (фиг.18А и 18В), далее описываются типичные и предпочтительные конструкции и варианты реализации системы для сортировки, перемещения и хранения сообщений eLetter в специальных папках ePostal на шаге SP31. Эти папки ePostal являются теми папками, в которые у Отправителя 12 помещается копия отправленного eLetter, а у Получателя 14 - принятое eLetter после его обработки. Следовательно, основными специальными папками ePostal являются «отправленные» и «входящие». Другие специальные папки могут быть созданы или Отправителем 12 при помощи экранов настроек и параметров ePostal, или еРО 20 во время установки Клиентской программы, или через прямую связь и сообщения eLetter от еРО. После того как eLetter на первое время будет помещено в папку ePostal, появляются альтернативные варианты перемещения eLetter в другие папки. Одним вариантом является обеспечение возможности перемещения eLetter из этой папки в любую другую папку (включая папки не для eLetter) и обратно. Другим вариантом является запрет на перемещение eLetter из его исходной папки. Предпочтительным вариантом реализации системы 10 ePostal для гарантии безопасности папок ePostal и обеспечения оптимальной гибкости перемещения сообщений eLetter и их сортировки пользователем ePostal является:

- Обеспечение возможности перемещения сообщений eLetter в любую другую папку ePostal

- Обеспечение возможности перемещения сообщений eLetter из папок ePostal в другие папки электронной почты

- Обеспечение возможности перемещения сообщений eLetter, которые были перемещены из папки ePostal обратно в папку ePostal, если они не изменялись

- Запрет на перемещение не-ePostal электронной почты в любую папку ePostal на шаге SP32.

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

Относительно примера программного обеспечения 22 Отправителя (фиг.2А и 2В) и предпочтительных шагов обработки отправителя (фиг.18А и 18В), когда выбор услуг у Отправителя 12 включает уведомление Отправителя 12 о получении и открытии (Notification Of the Receipt and Opening, NORO) Получателем 14 сообщения eLetter и сертификацию пользователей Получателей 14 как тех, кто открыл eLetter на шаге SP33, далее описывается пример альтернативной конструкции и варианта реализации системы для доставки этих уведомлений. Альтернативные варианты включают различное количество уведомлений Отправителя 12, возникающих для одного eLetter, например уведомление в обоих случаях, когда eLetter принимается и открывается, или только одно уведомление, когда eLetter открывается. Альтернативные варианты также включают способы, которыми уведомления отсылаются Отправителю 12. Уведомления могут выполняться посредством отправки ответного сообщения eLetter Отправителю 12 и/или проверки Отправителем 12 истории отправленных eLetter при помощи элемента меню ePostal в почтовой программе или путем перехода на веб-сайт еРО 20, регистрации на нем и запроса информации. Предпочтительным вариантом системы 10 ePostal является отображение пользователю различных возможных параметров в разделе настроек и параметров меню ePostal почтовой программы и предоставление пользователю возможности выбора на шаге SP34.

Относительно примера программного обеспечения 22 Отправителя (фиг.2А и 2В) и предпочтительных шагов обработки отправителя (фиг.18А и 18В) далее описываются примеры альтернативных конструкций и вариантов реализации системы для предоставления Получателю 14 поощрительных кредитов ePostal за открытие сообщений eLetter от Отправителя 12. Некоторые из многих альтернативных вариантов включают: отсутствие каких-либо поощрений; предоставление каждому Получателю 14 одинаковых поощрений за открытие eLetter; индивидуальные и групповые поощрения, меняющиеся по решению администрации системы 10 ePostal; предоставление Отправителю 12 возможности самостоятельно определить размер поощрений, которые он даст Получателю 14 за открытие eLetter. В идеальном варианте система 10 ePostal обеспечивает функционирование всех этих и других альтернативных режимов, так как при этом система 10 ePostal и Отправитель 12 имеют наибольшую гибкость в использовании функции «поощрений для открытия eLetter».

Относительно примера программного обеспечения 22 Отправителя (фиг.2А и 2В) и предпочтительных шагов обработки Отправителя (фиг.18А и 18В), далее описываются примеры альтернативных конструкций системы и способов для услуг шифрования ePostal. Перед шифрованием eLetter Отправитель 12 может требовать или не требовать от пользователя ввода его пароля. Также при получении зашифрованного eLetter Получатель 14 может требовать или не требовать от пользователя ввода его пароля перед дешифрованием входящего eLetter. Предпочтительно система 10 ePostal устанавливает Клиентское программное обеспечение таким образом, чтобы по умолчанию система ePostal не требовала пароля для шифрования, но требовала его при дешифровании. Кроме того, пользователю предоставляется возможность выбора других указанных альтернативных вариантов в меню пользовательских настроек и параметров ePostal на шаге SP34.

Более конкретно, функции примера программного обеспечения 24, 24' ePost Office 20 («ePO» является сокращением от ePost Office), как описано со ссылкой на фиг.3А-С, 4В, 6 и 7, содержат управление всеми обрабатывающими и административными операциями в ePost Office 20, среди которых:

- Прием электронной почты Отправителей 12

- Просмотр электронной почты на наличие технических опасностей

- Выполнение проверки Отправителя 12

- Просмотр аккаунта Отправителя 12 для одобрения обработки электронной почты отправителя

- Снятие средств с аккаунта Отправителя 12 для необходимой оплаты почтовых услуг

- Выполнение просмотра содержимого

- Официальное получение и сортировка электронной почты Отправителя 12

- Определение наличия у получателя аккаунта в службе ePostal

- Подготовка eLetter Отправителя 12 для доставки Получателю 14

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

- Выполнение других специальных указаний по доставке

- Создание метки даты/времени обработки на ePost Office 20

- Отправка eLetter Отправителя 12 Получателю 14

- Администрирование аккаунтов Отправителя 12 и Получателя 14 относительно обработанных сообщений eLetter

- Получение/запись подтверждения от Получателя 14 о получении и открытии eLetter, а также, при необходимости, о сертификации отдельного получателя

- Зачисление на аккаунт Получателя 14 поощрений за открытие сообщений eLetter

- Пересылка уведомлений от Получателя 14 Отправителю 12

- Непрерывное обслуживание аккаунтов Отправителя 12 и Получателя 14

- Связь с пользователями Отправителей 12 и Получателей 14 и их программным обеспечением 22, 26 ePostal по мере необходимости

- Обновление программного обеспечения 22, 26 ePostal у Отправителя 12 и Получателя 14

- Помощь новым пользователям в открытии аккаунтов в системе ePostal и получении и установке программного обеспечения Отправителя/Получателя

- Помощь Отправителям 12 в доставке сообщений eLetter получателям, не имеющим аккаунтов и программного обеспечения ePostal

- Помощь получателям, не имеющим аккаунтов и программного обеспечения ePostal, в доступе к сообщениям eLetter через окно или веб-сайт еРО

- Выполнение при необходимости официальных аналитических исследований времени/даты обработки сообщений eLetter

- Выполнение при необходимости аналитической проверки защищенного содержимого eLetter.

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

Помимо этого, как было упомянуто выше и изображено на фиг.10, настоящее изобретение может предложить Отправителю 12 возможность распечатать eLetter на бумаге после того, как оно будет обработано на ePost Office 20 любым из указанных здесь способов, запечатать в конверт и физически доставить Получателю 14.

Программное обеспечение 24, 24' ePost Office, описанное на фиг.3А-С, 4В, 6, 7 и со ссылкой на них, может быть реализовано в различных альтернативных вариантах работы. Пример последовательности шагов обработки и предпочтительные в настоящее время конструкции системы для программного обеспечения 24, 24' еРО описаны ниже и изображены на фиг.20А и 20В.

- Конкретный вариат реализации зависит от еРО 20 и способа, выбранного для отправки, обработки и доставки eLetter от Отправителя 12 Получателю 14, как описано для отправки, обработки и доставки сообщения eLetter.

Альтернативные примеры конструкций системы и шагов обработки eLetter на ePost Office 20 изображены на фиг.20А и 20В и описаны ниже со ссылкой на них. Они в основном относятся к множеству альтернативных вариантов отправки eLetter от Отправителя 12 Получателю 14. Кроме того, они, в частности, относятся к предпочтительному в большинстве случаев варианту, в котором сообщения eLetter и большая часть (если не все) данных для обработки ePostal от Отправителя 12 посылаются через еРО 20 Получателю 14.

Необходимо заметить, что все альтернативы отправки и доставки (включая использование или обход еРО) могут быть реализованы в соответствии со всеми или некоторыми из этих пунктов:

- различные описанные выше альтернативные варианты обработки eLetter на Отправителе 12

- различные описанные выше альтернативные варианты обработки eLetter в еРО 20

- различные описанные выше альтернативные варианты обработки eLetter у Получателя 14

- различные описанные выше альтернативные варианты прямой связи

- информация, передаваемая еРО 20 Отправителю 12 и Получателю 14 по прямой связи, ePostal eLetter или другое средство связи ePostal, относительно которой Отправитель 12 должен использовать конкретный вариант отправки eLetter Получателю 14.

В альтернативных вариантах, в которых eLetter не проходит через еРО 20, большая часть операций (если не все эти операции) примера программного обеспечения 24, 24" ePost Office, которые описаны выше, изображены на фиг.3А-С, 4В, 6, 7 и описаны со ссылкой на них, также выполняется. Однако в этих альтернативных вариантах ePost Office 20, вместо управления и выполнения всей обработки при прохождении eLetter через еРО 20, еРО 20 продолжает выполнять обработку, но поручает некоторые действия по обработке Отправителю 12, Получателю 14 и/или программному обеспечению 28 сети ePostal, показанному на фиг.8. еРО 20 управляет порученными действиями по обработке и делится результатами обработки еРО 20 с Отправителем 12, Получателем 14 и программным обеспечением 28 сети ePostal через прямую связь системы ePostal, которая обсуждалась ранее.

ePost Office 20 обрабатывает eLetter при помощи программного обеспечения 24, 24 ePost Office. Последовательность шагов, изображенная на фиг.20А и 20 В и описанная ниже со ссылкой на них, является примером и может меняться в зависимости от таких факторов, как способ, используемый для отправки и доставки eLetter от Отправителя 12 Получателю 14, объем обработки eLetter, осуществляемой еРО 20, и услуги, выбранные Отправителем 12.

еРО 20 начинает обработку входящего eLetter на шаге ЕР1 с идентификации входящей электронной почты как сообщения eLetter. Необходимо понимать, что если на любом этапе обработки еРО 20 ожидаемые данные для обработки отсутствуют или некорректны, электронная почта отклоняется от обработки и рассматривается на основании конкретной ситуации. еРО 20, работающий с типовыми предпочтительными вариантами, которые описаны выше для программного обеспечения 22 Отправителя, ищет в eLetter, а именно в специализированном заголовке SMTP (фиг.19) данные для обработки ePostal. Затем еРО начинает предпочтительную последовательность операций для идентификации на шаге ЕР2, проверки и аутентификации на шаге ЕР4 и затем основной обработки на шаге ЕР4.

На шаге ЕР5 еРО 20 анализирует 1-ю часть специализированного заголовка. Здесь снова делается ссылка на фиг.19. В 1-й части на шаге ЕР6 еРО 20 находит идентификационные номера отправителя 12, которые указывают еРО 20 симметричный ключ для дешифрования 2-й части специализированного заголовка на шаге ЕР7. Создание и обмен ключами шифрования, используемыми Отправителем 12 при обработке eLetter, обсуждались в связи с программным обеспечением 22 Отправителя.

Система 10 ePostal, описанная выше, предпочтительно использует еРО 20 для дешифрования 2-й Части при помощи описанного ранее симметричного ключа на шаге ЕР8, сохранения хэша MDC тела сообщения на шаге ЕР9 и получения симметричного ключа для дешифрования 3-й Части на шаге ЕР10.

Вышеперечисленные шаги по сути идентифицируют электронное письмо как eLetter, как показано в части «Идентификация» функциональной блок схемы на фиг.20. Во-первых, существует специализированный заголовок с по меньшей мере двумя частями, которые действуют как специализированный заголовок сообщения eLetter системы ePostal. Во-вторых, имеется идентификационный номер Отправителя, который распознается как Отправитель 12 с Аккаунтом в системе ePostal. В-третьих, в еРО имеется симметричный ключ для дешифрования 2-й Части, который соответствует идентификационному номеру отправителя.

Для дешифрования 3-й Части при помощи симметричного ключа из 2-й части на шаге ЕР11 система 10 ePostal предпочтительно использует еРО 20.

На шаге ЕР12 еРО определяет услуги ePostal, выбранные Отправителем 12. Даже если обработка некоторых услуг ePostal не указана ниже, необходимо понимать, что специалисты могут изменить еРО 20 для выполнения услуг по мере необходимости.

еРО 20 дешифрует тело сообщения eLetter на шаге ЕР13 при помощи симметричного ключа, хранящегося в Части 3 специализированного заголовка, если Отправителем 12 была выбрана услуга шифрования ePostal.

В настоящем изобретении возможна альтернатива дешифрованию зашифрованного тела сообщения eLetter во время обработки в еРО 20, а именно отсутствие дешифрования зашифрованного eLetter. Мнение, что преимуществом этого варианта является лучшая защита и конфиденциальность eLetter при его обработке еРО 20, если оно не дешифруется, неправильно. Дешифрование, обработка открытого текста и повторное шифрование выполняются в условиях «черного ящика», в которых никто не может получить доступ к системе ePostal во время обработки eLetter, когда оно находится в виде открытого текста. Кроме того, у варианта отсутствия дешифрования зашифрованного eLetter при его обработке в еРО имеются серьезные недостатки. В их число входит необходимость дешифрования eLetter для его просмотра на наличие опасностей, связанных с содержанием и техническими свойствами, и возможность более точной проверки достоверности хэша MDC тела сообщения при дешифровании eLetter. И то и другое влияет на проверку сообщения и аутентификацию Отправителя 12 в еРО 20. Поэтому предпочитается, чтобы система 10 ePostal производила дешифрование всех входящих зашифрованных сообщений eLetter, чтобы они могли быть надлежащим образом просмотрены на наличие опасностей, связанных с содержанием и техническими свойствами и чтобы могла быть выполнена правильная проверка достоверности хэша MDC тела сообщения.

На шаге ЕР14 еРО 20 просматривает eLetter на наличие опасностей, связанных с его содержанием и техническими свойствами.

На шаге ЕР15 еРО 20 создает хэш MDC тела сообщения и на шаге ЕР16 сравнивает этот хэш MDC с хэшем MDC, хранящимся во 2-й Части специализированного заголовка. Если результат одинаков, то на шаге ЕР17 происходит подтверждение того, что содержимое eLetter было отправлено Отправителем 12.

На шаге ЕР18 еРО 20 производит аутентификацию Отправителя 12. Для этого имеется много способов. В одном варианте в еРО 20 могут храниться различные данные, которые связаны только с Отправителем 12, и, когда данные передаются Отправителем 12 в еРО 20 и защищаются при передаче шифрованием, эти данные аутентифицируют в еРО 20 Отправителя 12. В предпочтительном в настоящее время варианте система 10 ePostal использует MDC не только для проверки сообщения, но и для аутентификации Отправителя 12. MDC аутентифицирует Отправителя 12, так как только Отправитель 12 может знать идентификационные номера Отправителя 12 в 1-й части специализированного заголовка, которые (1) указывают еРО 20 симметричный ключ, имеющийся помимо Отправителя 12 только в еРО 20, и (2) подтверждают хэш MDC тела сообщения. Помимо этого в 3-й Части специализированного заголовка имеется по меньшей мере два других набора идентификационных номеров Отправителя 12, которые после дешифрования или хэширования совпадают с соответствующими идентификационными номерами Отправителя 12, которые хранятся в еРО 20. Эти два варианта предоставляют два дополнительных способа аутентификации Отправителя 12 на шаге ЕР19. Как отмечалось ранее, также рассматривается вариант усиления защиты системы 10 ePostal посредством периодического изменения не только симметричных ключей, которые используются во 2-й и 3-й Частях, но и последовательностей данных в этих частях.

еРО 20 на шаге ЕР20 помещает в eLetter любые административные сообщения для Получателя, включая информацию для обработки и сообщения для получателей, не имеющих программное обеспечение Получателя 26.

На шаге ЕР21 еРО 20 создает новый хэш MDC тела сообщения, если оно было изменено из-за добавления каких-либо административных сообщений.

На шаге ЕР22 еРО 20 заново шифрует тело сообщения eLetter, если Отправителем 12 была выбрана услуга шифрования ePostal. В одном варианте при повторном шифровании тела сообщения используется тот же симметричный ключ, который использовался для исходной его шифрования и содержится в 3-й Части специализированного заголовка eLetter от Отправителя 12. В другом варианте при повторном шифровании используется новый симметричный ключ. Предпочтительно еРО 20 снова использует исходный симметричный ключ, так как при этом защита шифрования не ослабляется, и при отсутствии необходимости генерирования нового ключа тратится меньше времени.

На шаге ЕР23 еРО определяет услуги ePostal, выбранные Отправителем 12, подсчитывает кредиты ePostal, необходимые для eLetter, и на шаге ЕР25 соответствующим образом регулирует баланс кредитов на Аккаунте Отправителя 12. Как обсуждалось ранее со ссылкой на программное обеспечение 22 Отправителя, еРО 20 предпочтительно хранит официальный банк кредитов для всех Аккаунтов ePostal. Если кредитов недостаточно, еРО 20 на шаге ЕР26 запускает процесс, предлагающий пользователю Отправителя 12 во время обработки eLetter приобрести большее количество кредитов. В такой ситуации деловая политика определяет не хватающее Отправителю 12 количество кредитов.

В настоящем изобретении рассмотрены альтернативные варианты установки цен на услуги ePostal и способов оплаты услуг. Основные варианты ценообразования включают: периодическую оплату подписки, одноразовый платеж за eLetter, не зависящий от выбранных услуг, и дифференцированную плату за eLetter, зависящую от выбранных услуг. В настоящее время на шаге ЕР24 предпочитается дифференцированная оплата услуг ePostal, выбранных для каждого eLetter. Этот вариант, конечно же, может меняться в соответствии с типом клиента и условиями бизнеса. Альтернативные варианты оплаты услуг включают: периодическую выписку счета пользователям за предоставленные услуги, оплату услуг по мере их использования, предварительную оплату различными способами определенного количества кредитов ePostal, которые затем расходуются по мере использования услуг. Предпочтительно система 10 ePostal использует предварительную оплату определенного количества кредитов, которые расходуются по мере использования услуг. Широко распространенные экономные модели этого решения включают приобретение почтовых марок и пополнение кредитов в почтовом отделении.

еРО на шаге ЕР27 осуществляет административную проверку при помощи данных, сохраненных в 3-й Части, таких как версия Клиентской программы Отправителя 12, и по мере необходимости подготавливает на шаге ЕР 28 связь с клиентской программой Отправителя 12.

Затем еРО 20 на шаге ЕР29 начинает обработку исходящего eLetter в соответствии с примером последовательности шагов обработки еРО и предпочтительными способами, описанными ранее и изображенными на фиг.20А и 20В. еРО 20 обрабатывает исходящее eLetter таким образом, чтобы оно подготавливалось с достаточными данными и инструкциями ePostal, доставлялось Получателю 14 через Интернет-провайдера 19 Получателя, и чтобы Получатель 14 знал, каким образом следует принять и завершить обработку eLetter. Имеются различные альтернативные варианты реализации шагов обработки исходящего сообщения.

По тем же причинам, что и при обработке Отправителем 12, система 10 ePostal на шаге ЕРЗО предпочтительно использует специализированные заголовки. Опять же количество специализированных заголовков не имеет значения. Однако для сообщений eLetter, отправляемых от еРО 20 Получателю 14, предпочтительным вариантом в системе 10 ePostal является использование двух заголовков или заголовка, состоящего из двух частей. В остальном обсуждении данного примера будет делаться ссылка на два заголовка. Вариант с двумя заголовками может меняться, если содержимое или обработка у Получателя 14 требуют большего их количества. Как и в случае с Отправителем 12, если конкретная почтовая программа Получателя 14 не позволяет использовать специализированные заголовки, требует, чтобы данные находились в одном месте eLetter, или не обеспечивает возможности доставки данных для обработки ePostal таким способом, то используется другое место размещения данных или вариант доставки. еРО 20 имеет сведения об операционной системе и почтовой программе Получателя 14 и поэтому знает о таких ограничениях.

еРО 20 подготавливает специализированные заголовки таким образом, чтобы они содержали не только данные для обработки eLetter на Получателе 14, но и данные для проверки и аутентификации eLetter. Проверка, как и в случае с Отправителем 12, показывает, что сообщение eLetter не изменялось во время передачи от еРО 20 Получателю 14. Аутентификация показывает, что eLetter для Получателя 14 действительно пришло от еРО 20 и поэтому является исходным сообщением Отправителя 12. Как при обработке Отправителем 12, Получатель 14 может обрабатывать eLetter в многочисленных альтернативных последовательностях. Это значит, что данные в специализированных заголовках могут быть скомпонованы множеством различных способов. Однако в отличие от обработки Отправителем 12 входящее eLetter для Получателя 14 может иметь почтовые адреса нескольких получателей, в то время как eLetter, отсылаемое Отправителем 12 в еРО 20, имеет только один адрес - адрес еРО 20. Поэтому для последовательности операций Получателя 14 в предпочтительном варианте Получатель 14 сначала определяет себя в сообщении eLetter. Затем он проверяет и аутентифицирует eLetter. После этого он выполняет остальную обработку. Так происходит потому, что, если идентификация, проверка или аутентификация не будут пройдены, желательно, чтобы Получатель 14 не обрабатывал электронное письмо. Такое электронное письмо может не являться сообщением eLetter. По этой причине данные в специализированном заголовке, позволяющие Получателю идентифицировать себя в eLetter, предпочтительно должны быть доступны раньше остальных данных. Затем данные для проверки и аутентификации предпочтительно должны быть доступны в специализированных заголовках до, или хотя бы во время, обработки данных.

Примеры структур специализированных заголовков показаны и описаны на фиг.21. Имеется два специализированных заголовка 1, 2. Необходимо заметить, что в альтернативных вариантах эти два заголовка могут считаться одним специализированным заголовком, состоящим из двух частей, или могут быть объединены в три или более специализированных заголовка. Предпочтительно система 10 ePostal использует два специализированных заголовка. Кроме того, физическая последовательность двух заголовков не имеет ключевого значения. Однако они должны быть расположены в той логической последовательности, в которой они используются.

Специализированный Заголовок 1 имеет структуру, оптимальную для вмещения многочисленных получателей eLetter (включая Получателя 14, адрес электронной почты которых связан с пользовательским Аккаунтом в еРО 20, и получателя, адрес которого не связан с пользовательским Аккаунтом). Альтернативные варианты объединения многочисленных получателей включают использование других типов структур данных в специализированном заголовке и eLetter и отправку из еРО 20 отдельных eLetter для каждого получателя.

Предпочтительный в настоящее время вариант системы 10 ePostal показан на фиг.21. Он позволяет еРО 20 принимать и отправлять одно eLetter для каждого eLetter, отправленного Отправителем 12, что обеспечивает преимущества в функциональности и защите.

На фиг.21 показан Специализированный Заголовок 2, сформированный на шаге ЕР31, сданными для обработки, в числе которых:

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

- MDC для проверки того, что eLetter не изменялось во время передачи Получателю. Также это один из способов определения Получателем того, что eLetter пришло от еРО 20 и, следовательно, от Отправителя 12.

- Данные об Отправителе 12, еРО 20 и Получателях, такие как идентификационные номера и адреса электронной почты. Информация «Кому», «копия» и «скрытая копия» удаляется из 2-й Части специализированного заголовка eLetter Отправителя 12 и помещается в Специализированный Заголовок 2 вместе с ее хэшем. Информация «От кого» и «Адрес для ответа» также помещается в Специализированный Заголовок 2 вместе с ее хэшем. Хэши этих данных обеспечивают возможность дополнительных способов проверки защиты eLetter и аутентификации еРО 20 и Отправителя 12.

- Данные, указывающие услуги ePostal, которые были выбраны Отправителем 12.

- Ключ шифрования для дешифрования тела сообщения eLetter, если услуга шифрования была выбрана. Предпочтительно система 10 ePostal повторно использует в еРО 20 симметричный ключ, который был сохранен в 3-й Части специализированного заголовка eLetter, отправленного Отправителем 12.

Затем на шаге ЕР32 Специализированный Заголовок 2 шифруется при помощи ключа шифрования, сгенерированного еРО 20. Предпочтительно система 10 ePostal использует симметричный ключ.

На шаге ЕР33 формируется Специализированный Заголовок 1 с данными для обработки ePostal, как показано на фиг.21. Этот заголовок состоит из последовательности пар чисел, одна пара соответствует одному адресу электронной почты получателя, независимо от того, связан адрес электронной почты с Аккаунтом ePostal, или нет. На шаге ЕР 34 пара чисел состоит из идентификационного номера Получателя и ключа дешифрования.

Для адреса электронной почты получателя, который не связан с Аккаунтом ePostal, еРО 20 создает запись и дает получателю идентификационный номер, используемый в Специализированном Заголовке 1. Эта запись позволяет еРО 20 отслеживать eLetter для этого электронного адреса получателя и все будущие сообщения eLetter и действия системы 10 ePostal, относящиеся к этому получателю.

Ключ дешифрования, который сохранен в Специализированном Заголовке 1, используется Получателем 14 для дешифрования Специализированного Заголовка 2. Предпочтительно этот ключ дешифрования является тем же самым симметричным ключом, который был сгенерирован еРО 20 (как обсуждалось ранее) и использовался для шифрования Специализированного Заголовка 2. Этот ключ дешифрования одинаков для каждого Получателя, так как зашифрованный Специализированный Заголовок 2 одинаков для всех получателей.

Идентификационный номер Получателя распознается Получателем 14 как принадлежащий Получателю 14, так как идентификационный номер Получателя также хранится на Получателе 14. Получатель без Аккаунта в еРО не распознает идентификационный номер; фактически, такой получатель не будет знать, что делать со Специализированным Заголовком eLetter, так как он не имеет программного обеспечения 26 Получателя. Эта ситуация более подробно описана ниже со ссылкой на программное обеспечение 26 Получателя.

Затем еРО 20 для каждой пары чисел на шаге ЕР35 шифрует симметричный ключ в Специализированном Заголовке 1. Предпочтительно для каждой пары в Специализированном Заголовке 1 симметричный ключ для усиления защиты шифрования смешивается со случайным шумом. Помимо этого еРО 20 предпочтительно использует разные симметричные ключи шифрования для шифрования симметричного ключа в паре чисел каждого Получателя. Ключ шифрования, используемый для каждого идентификационного номера Получателя, соответствует данному идентификационному номеру Получателя в записях еРО 20. (Необходимо заметить, что когда eLetter приходит Получателю 14 и Получатель 14 находит в Специализированном Заголовке 1 идентификационный номер Получателя, который соответствует идентификационному номеру Получателя из собственного списка таких номеров Получателя 14, Получатель 14 для дешифрования симметричного ключа в Специализированном Заголовке 1 использует ключ дешифрования, хранящийся вместе с этим идентификационным номером Получателя).

Затем еРО 20 на шаге ЕР36 помещает Специализированные Заголовки 1 и 2 в eLetter. Хотя это не показано на фиг.21, необходимо понимать, что любые данные в Специализированных Заголовках 1 и 2 должны содержать размер данных, пока еРО 20 не будет получать эту информацию каким-либо другим способом. Также, хотя это не показано на фиг.21, ссылаясь на предшествующие описания альтернативных вариантов и предпочтительных технологий шифрования, система 10 ePostal в целях усиления защиты предпочтительно использует случайный шум, добавляемый к данным в Специализированном Заголовке 2 (как указывалось ранее для Специализированного Заголовка 1) перед его шифрованием. Кроме того, хотя это не показано на фиг.21, структура данных в Специализированном Заголовке 2 меняется для усиления будущей защиты шифрования. Как указывалось ранее в описании прямых связей, так как в специализированных заголовках будут находиться зашифрованные данные, они должны быть переведены в шестнадцатеричный формат или какой-либо другой подобный код, чтобы их можно было передать.

На данном этапе, если это еще не было сделано, еРО 20 на шаге ЕР37 копирует исходную информацию «Кому», «копия» и «скрытая копия» из 3-й Части специализированного заголовка eLetter Отправителя 12 в заголовки eLetter «Кому», «копия» и «скрытая копия». еРО 20, если это еще не было выполнено, и на шаге ЕР38 удаляет из eLetter специализированный заголовок, который был помещен в eLetter Отправителем 12.

Затем в предпочтительном в настоящее время варианте изобретения еРО 20 на шаге ЕР39 посылает исходящее сообщение eLetter с его Специализированными Заголовками 1 и 2 для отправки и доставки eLetter от Отправителя 12 Получателю 14 со всеми данными для обработки ePostal, необходимыми Получателю 14 для получения, идентификации, проверки, аутентификации и завершения обработки eLetter.

В заключение еРО 20 на шаге ЕР40 завершает сохранение всех необходимых данных, относящихся к eLetter, на данном этапе его обработки и доставки.

Более конкретно, функции примера программного обеспечения 26 Получателя 14, как описано на фиг.4А-1 и 4А-2 или со ссылкой на них, включают следующее:

- Идентификация всех сообщений eLetter по мере их приема Получателем 14

- Сохранение и отделение сообщений eLetter от всей другой электронной почты по умолчанию или в соответствии со специальными инструкциями Получателя 14, например, в папку «Входящие» ePostal

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

- Осуществление специальной сортировки не-ePostal электронной почты на почту от известных и неизвестных отправителей, если это указано Получателем 14

- Осуществление управления остальной электронной почтой и ее уничтожение, например удаление не-ePostal электронной почты и почты от неизвестных отправителей, если это указано Получателем 14

- Помощь Получателю 14 в просмотре всех услуг ePostal, выбранных Отправителем 12

- Дешифрование сообщений eLetter, если это необходимо

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

- Идентификация пользователей Отправителей 12, которые себя сертифицировали

- Идентификация открытых сообщений eLetter

- Администрирование кредитов Получателя 14 для открытия сообщений eLetter

- Отправка на ePost Office 20 уведомлений о получении и открытии сообщений eLetter

- Осуществление и отправка на ePost Office 20 сертификации пользователя Получателя

- Помощь получателю в ответе на сообщения eLetter Отправителя 12 с предварительно оплаченным ответом

- Помощь Получателю 14 в осуществлении связи и выполнении различных задач по администрированию относительно ePost Office 20, который хранит текущие данные об аккаунте Получателя

- Бесшовная работа с веб-браузером и почтовой программой Получателя 14.

Получатели 14, не имеющие аккаунтов ePostal и программного обеспечения 26, как описано на фиг.4А-1 и 4А-2 или со ссылкой на них, также могут получать электронную почту и иметь доступ к сообщениям eLetter, обработанным в ePost Office 20, как показано на фиг.3 и 4В. Электронная почта от Отправителя 12, принимаемая получателем без аккаунта и программного обеспечения ePostal, не обладает всеми преимуществами системы ePostal, связанными с просмотром наличия опасностей технического и содержательного плана. Например, получатель без аккаунта не может проверить, действительно ли электронная почта была обработана в ePost Office 20 или пришла от Отправителя 12. Поэтому электронная почта теряет преимущества безопасности системы 10 ePostal и во многом становится похожа на обычную электронную почту. Однако такая электронная почта может предоставить получателям, не имеющим аккаунта, возможность проверки, действительно ли письмо пришло от Отправителя 12 и было обработано ePost Office 20. Электронная почта может предоставить получателям без аккаунта код, позволяющий просмотреть eLetter Отправителя 12 в окне или на веб-сайте ePost Office 20. Эти сообщения eLetter имеют много особенностей и преимуществ системы ePostal, таких как просмотр наличия опасностей, связанных с содержанием и техническими свойствами, индикаторы ценности и приоритета, аутентификация терминала Отправителя 12, сертификация пользователя Отправителя 12, шифрование и заранее оплаченные ответы Отправителю 12, но также имеют и значительные ограничения; связанные с тем, что сообщения не принимаются и не сохраняются в собственной почтовой программе получателя.

Настоящее изобретение включает различные альтернативны программного обеспечения и варианты работы, относящиеся к программному обеспечению 26 Получателя (описано выше и показано на фиг.4А-1 и 4А-2 или со ссылкой на них) и к последовательности предпочтительных шагов обработки Получателем (описана выше и показана на фиг.22А и 22В).

Эти альтернативы для Получателя 14 зависят от вариантов, выбранных для отправки, обработки и доставки eLetter от Отправителя 12 Получателю 14, как описано выше относительно вариантов отправки, обработки и доставки сообщения eLetter. Альтернативные варианты обработки eLetter Получателем 14, которые описаны ниже и показаны на фиг.22А и 22В, в основном относятся ко всем возможным альтернативам отправки eLetter от Отправителя 12 Получателю 14. Кроме того, описан предпочтительный в большинстве случаев вариант, когда само сообщение eLetter и большая часть (если не все) данных для обработки ePostal от Отправителя 12 посылаются через еРО 20 Получателю 14.

Получатель 14 принимает и обрабатывает eLetter при помощи программного обеспечения 26 Получателя. Последовательность RP1 шагов Получателя 14 (описана ниже и показана на фиг.22А и 22В) является примерной. Она может меняться, например, в зависимости от варианта, используемого для отправки и доставки eLetter от Отправителя 12 Получателю 14, объема обработки eLetter, осуществляемой еРО 20, выбранных Отправителем 12 услуг и типа операционной системы и почтовой программы Получателя 14.

В предпочтительном в настоящее время варианте системы 10 ePostal имеется три основных этапа обработки Получателем 14 - это идентификация RP2, проверка и аутентификация RP3 и затем основная обработка RP4. Необходимо понимать, что если на любом этапе обработки ожидаемые данные для обработки отсутствуют или некорректны, электронная почта отклоняется от дальнейшей обработки и рассматривается на основании конкретной ситуации на шаге RP10.

Шаг идентификации RP2 на Получателе 14 начинается с поступления электронной почты в почтовую программу Получателя 14 через какой-либо протокол TCP, такой как РОР3. Однако, если Получатель 14 не пользуется такой почтовой программой, а использует для электронной почты другое прикладное программное обеспечение, такое как веб-браузер, программное обеспечение 26 Получателя работает с этой программой, хотя по несколько иной технологии, которая описана ниже (как указано относительно предпочтительного варианта установки и активации программного обеспечения ePostal). To, каким образом, где и когда Получатель 14 узнает о поступлении новой электронной почты, зависит от типа операционной системы и почтовой программы Получателя 14. До и после помещения электронной почты в папки почтовой программы может пройти некоторое время. Если Получатель 14 узнает о поступлении электронной почты после того, как она будет помещена в папку почтовой программы, Получатель 14 просматривает наличие вновь пришедшей почты в папках почтовой программы.

В предпочтительном варианте, когда Получатель 14 обнаруживает новую почту, он сначала проверяет на шаге RP5, является ли пришедшая почта сообщением eLetter, определяя, является ли адрес «От кого» отправителя электронного письма известным ему адресом отправителя, авторизированным в ePost Office 20. Затем Получатель 14 на шаге RP6, как следует из предпочтительных способов, которые описаны в разделе об исходящих eLetter, обрабатываемых программным обеспечением 24, 24' ePost Office, ищет наличие в eLetter данных для обработки, а именно наличия Специализированного Заголовка 1 SMTP. Если такой заголовок имеется, письмо рассматривается для дальнейшей обработки как eLetter.

Как показано на фиг.21, шаг RP3 проверки и аутентификации начинается с анализа Получателем 14 заголовков и Специализированных Заголовков сообщения eLetter.

Получатель 14 на шаге RP7 проверяет совпадение адреса в электронном письме «Доставлено по адресу» с полями данных «Оригинальное сообщение по адресу» и «Кому/копия/скрытая копия». Если совпадение отсутствует, на шаге RP8 имеется вероятность вымышленного адреса. Предпочтительно в системе 10 ePostal при вероятности вымышленного адреса Получатель 14 по прямой связи передает в еРО 20 данные, указывающие на вымышленный адрес. еРО 20 отвечает по прямой связи Получателю и в ответе передает дальнейшие инструкции, такие как правильные идентификационные номера Получателя и ключ дешифрования, необходимые для дальнейшей обработки eLetter.

Затем Получатель 14 находит на шаге RP11 идентификационный номер Получателя в записях данных Получателя 14, которые объединены в пары с адресом «Доставлено по адресу» электронной почты. На шаге RP12 Получатель 14 сравнивает этот идентификационный номер Получателя с каждым из идентификационных номеров Получателей в Специализированном Заголовке 1, чтобы найти связанный зашифрованный симметричный ключ. Как обсуждалось выше, Получатель 14 на шаге RP13 находит на шаге RP14 в записях данных Получателя 14 симметричный ключ дешифрования, связанный с соответствующим идентификационным номером Получателя в Специализированном Заголовке 1. При помощи этого симметричного ключа дешифрования Получатель 14 дешифрует на шаге RP15 зашифрованный симметричный ключ, который хранится в Специализированном Заголовке 1 и объединен в пару с соответствующим идентификационным номером Получателя. Также Получатель 14 удаляет из симметричного ключа случайный шум, который был добавлен к нему перед шифрованием в еРО 20 для усиления защиты, как предпочтительный этап работы системы 10 ePostal.

Принимая во внимание ранее описанное шифрование, Получатель 14 при помощи дешифрованного симметричного ключа из Специализированного Заголовка 1 на шаге RP16 дешифрует Специализированный Заголовок 2, делая доступными для использования все данные из Специализированного Заголовка 2, такие как список услуг ePostal, выбранных Отправителем 12.

На шаге RP17 Получатель 14 определяет услуги ePostal, выбранные Отправителем 12. Даже если обработка некоторых услуг ePostal не указана ниже в отдельном порядке, еРО 20 выполняет эти услуги по мере необходимости, когда это требуется для обработки Получателем 14, используя известные специалистам технологии.

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

На шаге RP19 Получатель 14 создает хэш MDC тела сообщения et-etter и на шаге RP20 сравнивает его с хэшем MDC тела сообщения, который хранится в Специализированном Заголовке 2. Совпадение двух хэшей MDC подтверждает на шаге RP21, что сообщение не изменялось во время передачи от еРО 20 Получателю 14.

На данном этапе Получатель 14 может также аутентифицировать еРО 20 в качестве отправителя eLetter, пришедшего Получателю 14. Как и при аутентификации eLetter Отправителя 12 в еРО 20, имеется много альтернативных вариантов осуществления данной функции. У Получателя 14 могут храниться различные данные, которые связаны только с еРО 20, и когда эти данные передаются от еРО 20 Получателю 14 и защищаются при передаче шифрованием, они аутентифицируют еРО 20 у Получателя 14. Предпочтительный в настоящее время вариант включает использование MDC не только для проверки сообщения, но и для аутентификации еРО 20 на шаге RP21, Совпадение хэша MDC тела сообщения, который создал Получатель 14, с хэшем MDC, хранящимся в Специализированном Заголовке 2, аутентифицирует еРО 20, а также подтверждает подлинность сообщения. Так происходит потому, что только еРО 20 может знать идентификационный номер Получателя в Специализированном Заголовке 1, который указывает Получателю 14 на симметричный ключ, который может иметь только Получатель 14 (отличный от ключа в еРО 20). Помимо этого во 2-й части специализированного заголовка имеется по меньшей мере два других набора идентификационных номеров отправителя 10, которые после дешифрования или хэширования совпадают с соответствующими идентификационными номерами отправителя 20, которые хранятся в еРО 14. В системе 10 ePostal предпочтительно использование двух идентификационных номеров. Эти два варианта предоставляют два дополнительных способа аутентификации отправителя 12 на шаге RP22. Также предпочтительно усиление защиты данных для обработки ePostal посредством периодического изменения не только симметричных ключей, которые используются со Специализированными Заголовками 1 и 2, но и последовательностей данных в Специализированных Заголовках.

Теперь, см. фиг.22, у Получателя 14 начинается этап основной обработки.

Получатель 14 подготавливает eLetter для отображения пользователю Аккаунта ePostal путем обновления информации «От кого» и «Адрес для ответа» в eLetter на шаге RP23 исходными данными «От кого», которые хранятся в Специализированном Заголовке 2.

Получатель 14 подготавливает eLetter для отображения посредством обработки Административного содержимого на шаге RP24, которое было добавлено в тело сообщения в еРО 20. Предпочтительно Административное сообщение ePostal помещается в начале всех тел сообщений eLetter, которые доставляются на шаге RP38 получателям, не имеющим программного обеспечения 26 Получателя. Так как без программного обеспечения Получателя 14 почтовая программа получателя помещает eLetter на шаге RP39 в обычную папку для входящей почты и не отделяет eLetter от остальной электронной почты, причины использования Административного сообщения ePostal весьма важны и включают:

- объяснение получателю без программного обеспечения 26 на шаге RP40, что eLetter было отправлено ему из еРО 20 от имени пользователя Получателя 12

- предоставление получателю информации о сообщении eLetter ePostal на шаге RP41

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

- предоставление получателю 14 на шаге RP43 важной информации, гарантирующей соответствие услуг ePostal правовым нормам.

Примеры альтернативных вариантов обработки Получателем включают: отправку отдельных сообщений eLetter Получателям 14 без данного Административного содержимого и получателям (не имеющим программного обеспечения Получателя) с Административным содержимым; отправку одинакового Административного содержимого всем Получателям независимо от того, имеют они программное обеспечение 26 Получателя или нет, и обеспечение возможности Получателям обоих типов просматривать Административное содержимое; и предпочтительно добавление Административного содержимого ко всем сообщениям eLetter, когда они обрабатываются в еРО 20, и затем удаление Получателем 14 (с программным обеспечением 26) этого содержимого до того, как пользователь Получателя 14 увидит отображенное eLetter. Получатель без программного обеспечения 26 не имеет возможности удаления Административного содержимого; такой пользователь-получатель при отображении eLetter увидит Административное сообщение.

На шаге RP25 Получатель 14 добавляет к телу сообщения eLetter для отображения пользователю Получателя 14 другое Административное содержимое, которое определяется данными в Специализированном Заголовке 2. Это содержимое включает информацию для пользователя Получателя 14, такую как:

- время и дата обработки eLetter на еРО

- услуги ePostal, которые были использованы для eLetter по запросу Отправителя 12 (включая индикатор класса приоритета ePostal, уведомление о получении и открытии eLetter, какие-либо специальные поощрения, предоставляемые пользователю Получателя 14 за открытие eLetter, шифрование, сертификацию пользователя Отправителя 12 и заранее оплаченные ответы)

- способ, которым Получатель 14 может использовать услугу заранее оплаченных ответов или другие особенности ePostal, использованные для письма на шаге RP37.

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

Продолжая подготовку eLetter для отображения, Получатель 14 на шаге RP26 при помощи информации в Специализированном Заголовке 2 устанавливает класс почтового сообщения для этого eLetter таким образом, чтобы отображался индикатор класса приоритета ePostal, выбранный Отправителем 12. Этапы этого процесса будут зависеть от почтовой программы на Получателе 14.

На данном этапе Получателем 14 завершена обработка, достаточная для отображения eLetter в его папке ePostal.

Получатель 14 на шаге RP27 сортирует eLetter в своей папке ePostal. Как подобным образом указывалось ранее в разделе об обработке Отправителем 12 в отношении программного обеспечения 26 Получателя, описанного выше и показанного на фиг.4А-1 и 4А-2, имеются альтернативные варианты сортировки, перемещения и хранения eLetter в папках ePostal. Эти папки ePostal для входящих писем получают копию принятого Получателем 14 eLetter после того, как оно будет обработано Получателем 14. Основная папка ePostal для входящих писем - это папка ePostal «Входящие». Другие специальные папки ePostal могут быть созданы или Получателем 14 при помощи экранов настроек и параметров ePostal, или еРО 20 во время установки клиентской программы, или через прямую связь и сообщения eLetter от еРО. Кроме того, как указывалось в этом документе, Получатель 14 помимо сортировки всех сообщений eLetter в папках ePostal может также по выбору пользователя Получателя 14 сортировать всю остальную электронную почту, адрес отправителя которой не имеет совпадений с записями в адресной книге пользователя Получателя 14, в отдельную папку, что обеспечивает возможность легкого удаления всей такой электронной почты.

Как обсуждалось ранее относительно обработки Отправителем 12, после того как eLetter на первое время будет помещено в папку ePostal, на шаге RP30 появляются альтернативные варианты перемещения eLetter в другие папки. Одним вариантом является обеспечение возможности перемещения eLetter из этой папки в любую другую папку (включая папки не для eLetter) и обратно. Другим вариантом является запрет перемещения eLetter из его исходной папки. Предпочтительно для гарантии безопасности папок ePostal и обеспечения оптимальной гибкости перемещения сообщений eLetter и их сортировки пользователем ePostal, реализуется следующее:

- Обеспечение возможности перемещения сообщений eLetter в любую другую папку ePostal.

- Обеспечение возможности перемещения сообщений eLetter из папок ePostal в другие папки электронной почты.

- Обеспечение возможности перемещения сообщений eLetter, которые были перемещены из папки ePostal, обратно в папку ePostal, если они не изменялись.

- Запрет перемещения не-ePostal электронной почты в любую папку ePostal на шаге RP31.

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

- Уведомление пользователя Получателя 14 на шаге RP28 всплывающим сообщением или звуковым сигналом о том, что поступило новое eLetter, когда eLetter было помещено в папку ePostal, или отсутствие уведомления. Хотя в системе ePostal по умолчанию используется всплывающее сообщение, предпочтительно система 10 ePostal позволяет пользователю Получателя выбирать различные варианты при помощи экранов настроек и параметров ePostal.

Если Отправитель 12 выбрал услугу шифрования ePostal, Получатель помещает eLetter в свою папку ePostal таким образом, чтобы тело сообщения не могло быть прочитано. Видна только информация «Кому/копия/скрытая копия», «От кого» и «Тема». Когда пользователь Получателя 14 на шаге RP32 выбирает eLetter, перед тем как Получатель 14 отобразит eLetter в читаемом открытом тексте, он попросит пользователя Получателя 14 ввести его пароль для идентификации и в целях безопасности. Когда пользователь введет свой пароль, Получатель 14 на шаге RP33 отобразит зашифрованное eLetter в читаемом открытом тексте. Получатель 14, так же как и Отправитель 12, может запросить у еРО 20 на шаге RP34 сохранение этого eLetter в хранилище сообщений eLetter в еРО 20, как и любого другого eLetter. Предпочтительно, хотя перед просмотром зашифрованного eLetter в читаемом формате пользователю требуется ввести его пароль, система 10 ePostal позволяет пользователю при помощи экранов настроек и параметров ePostal выбрать, нужен ввод пароля или нет. Помимо альтернативы отображения дешифрованного eLetter в папке ePostal, предпочтительно система 10 ePOstal позволяет Получателю 14 (и Отправителю 12) при помощи экранов настроек и параметров ePostal сохранять зашифрованный вариант eLetter в папках ePostal, которые предназначены для таких зашифрованных сообщений eLetter. Эти сохраненные зашифрованные сообщения eLetter могут быть открыты Получателем 14 позднее, когда пользователь Получателя 14 введет свой пароль.

По завершении идентификации, проверки, аутентификации и основной обработки eLetter Получатель 14, если он находится в режиме «онлайн» или сразу после перехода в этот режим, предпочтительно использует прямую связь, как описывалось ранее, чтобы уведомить еРО 20 о приходе eLetter Получателю 14 на шаге RP29. Эта прямая связь дает еРО 20 подтверждение, что eLetter было доставлено и успешно обработано Получателем 14. еРО 20 записывает данную информацию.

Когда пользователь Получателя 14 открывает eLetter, Получатель 14, если он находится в режиме «онлайн» или сразу после перехода в этот режим, предпочтительно использует прямую связь, как описывалось ранее, чтобы уведомить еРО 20 об открытии eLetter на шаге RP36. Если пользователь Отправителя 12 запросил сертификацию пользователя Получателя 14 как лица, открывшего eLetter, Получатель 14 при открытии eLetter выполняет сертификацию и также на шаге RP36 по прямой связи передает отчет в еРО 20. еРО 20 записывает данную информацию.

Как и при связи, относящейся к получению и открытию eLetter, Получатель 14 использует прямую связь для уведомления еРО 20 о получении и открытии eLetter, независимо от того, выбрал ли Отправитель 12 опцию приема таких уведомлений. Если Отправитель 12 включил услугу уведомления о получении и открытии (NORO), имеются альтернативные варианты способов предоставления этих уведомлений Отправителю 12. В эти альтернативы входят варианты передачи уведомлений Отправителю 12 от еРО 20 или от Получателя 14. Предпочтительно передача уведомления о получении и открытии Отправителю 12 выполняется от еРО 20, так как это намного более простая и безопасная альтернатива. В других вариантах Отправитель 12 получает отдельные уведомления о получении и открытии, или же одно уведомление о получении и открытии после того, как eLetter будет открыто. В предпочтительном варианте система 10 ePostal позволяет Отправителю 12 сделать этот выбор во время включения данной услуги ePostal.

Также, когда пользователь Получателя 14 открывает eLetter, Получатель 14, предпочтительно во время открытия, оценивает кредит поощрения ePostal за открытие (incentive to open, ITO), который будет начислен на Аккаунт пользователя Получателя 14 в еРО 20 (после использования Получателем 14 прямой связи для уведомления еРО 20 об открытии eLetter) и добавляет этот рассчитанный кредит на шаге RP35 в локальный банк кредитов ePostal Получателя 14. Также Получатель 14 добавляет в локальный банк кредитов любые вознаграждения за открытие, которые Отправитель 12 выбрал для этого eLetter.

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

Другой особенностью настоящего изобретения, как показано на фиг.5, является то, что Отправитель 12 может зайти в ePost Office 20 для отправки сообщений eLetter, а Получатель 14 может зайти в ePost Office 20 для сбора сообщений eLetter из «ящика» еРО, как и в обычных почтовых службах. Примером того, где это может быть полезно, является ситуация, в которой пользователи Отправителя 12 и Получателя 14 находятся вдали от своих терминалов с программным обеспечением 22, 26 ePostal. При помощи любого терминала с веб-браузером, как показано на фиг.6 и 7, они могут зайти на веб-сайт еРО, войти в систему и получить доступ к информации и инструментам своих аккаунтов для отправки сообщений eLetter, просмотра, пересылки или выполнения иных действий с сообщениями eLetter, хранящимися для них в еРО, так, как будто они используют собственные терминалы со своей почтовой программой, браузером и программным обеспечением ePostal.

Вариантом особенности, описанной в предыдущем абзаце и показанной на фиг.5, является возможность пользователей зайти в ePost Office 20 для отправки и сбора сообщений eLetter из «ящика» до тех пор, пока будут открыты их аккаунты на веб-сайте еРО, даже в том случае, если они не имеют на каком-либо терминале установленного программного обеспечения ePostal. В этой ситуации, так же как и в описанной выше, пользователи при помощи любого терминала с веб-браузером, как показано на фиг.6 и 7, могут зайти на веб-сайт еРО, войти в систему и получить доступ к информации и инструментам своих аккаунтов для отправки сообщений eLetter, просмотра, пересылки или выполнения иных действий с сообщениями eLetter, хранящимися для них в еРО.

Как указывалось ранее и показано на фиг.9, Отправители 12 и получатели могут иметь соединение с услугами электронной почты и доступа в Интернет иным способом, нежели через Интернет-провайдера, например из корпоративной интрасети или какой-либо другой организационной сети. На фиг.8 показан пример корпоративной интрасети при соединении не через Интернет-провайдера, в котором программное обеспечение ePostal может работать не только на отдельных терминалах отправителей, но и на корпоративных серверах. Хотя организации используют типовые решения для таких сетей и серверов, во многих случаях, как хорошо известно, используются сети различных размеров, с различными возможностями и работающие по различным протоколам. Для удобства они упоминаются в данном документе с использованием терминов «корпоративный», «корпоративная сеть», «корпоративная интрасеть» и «корпоративный сервер».

Отправители 12 на фиг.8, как показано на фиг.2А и 2В, могут отправлять электронную почту как с использованием услуг ePostal, так и без них. Однако в сети Отправителей, пользующихся услугами ePostal, управление операциями ePostal для всей организации осуществляется намного лучше, если Сетевое программное обеспечение 28 ePostal работает и с программным обеспечением ePostal Отправителя на Отправителях 12, и с Корпоративными Серверами 13 eMail в отличие от варианта, когда программное обеспечение ePostal имеется только на отдельных компьютерах Отправителей 12. Такая конфигурация системы включает: управление доступными функциями ePostal, администрирование общего количества кредитов ePostal организации, связь с ePOst Office 20 и операции по сохранению и накоплению различных сопутствующих данных.

Корпоративные пользователи Отправителей 12 являются не только людьми, но и группами систем деловой информации, такими как бухгалтерские и расчетные системы. Например, Сетевое программное обеспечение 28 ePostal должно помогать этим Информационным Системам 17 и Корпоративным Почтовым Серверам 13 в подготовке, отправке и использовании услуг ePostal (включая «почтовый учет» ePostal) для деловых документов, отправляемых в виде eLetter, таких как счета и извещения для клиентов.

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

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

Как обсуждалось ранее со ссылкой на фиг.1 и 9, настоящее изобретение может работать с Отправителями и получателями в сети Интернет-провайдера или какой-либо другой сети, такой как деловая интрасеть. Сетевое программное обеспечение 28 ePostal, упоминаемое на фиг.8 и описанное выше, может совместно работать на уровне сетевых серверов не только в деловых интрасетях, но и с другими организационными сетями или сетями Интернет-провайдеров, в которых конкретные функции и особенности программирования Сетевого программного обеспечения ePostal для конкретной сети будут меняться в зависимости от технической конфигурации сети и организационных потребностей.

Другим существенным аспектом настоящего изобретения является то, что отправитель платит за пользование услугами ePostal так же, как и в обычных почтовых службах, и за разную плату может получить различные наборы услуг. Изобретение имеет преимущество возможности назначения приоритетов электронной почты среди сообщений eLetter самой системы ePostal, а не только для их отделения от всей обычной электронной почты. Помимо этого, аспект оплаты ограничивает использование системы, что обеспечивает автоматическое рыночное решение проблемы растущего трафика «бесплатной» электронной почты; как обсуждалось ранее, этот трафик имеет две составляющие: 1) перегрузка легальной и желательной электронной почтой и 2) перегрузка нежелательной, мешающей электронной почтой. Кроме того, отправители заинтересованы в решении проблем, связанных не только с объемами электронной почты, но и с ее качеством. Отправители ищут лучшие варианты защиты, которые свойственны системе ePostal, а также получают ее дополнительные возможности; также они могут пользоваться преимуществами дифференцируемых, безопасных/ шифрованных и отслеживаемых электронных писем, более продуктивного управления электронной почтой, простоты использования, общей доступности и обеспечения поддержки деловых и прочих сетей.

Некоторые отправители будут оплачивать обработку их наиболее важной электронной почты в системе ePostal, потому что ее ценность важна не только для отправителей, но и для Получателей 14.

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

- Получатель 14 знает, что отправитель считает eLetter достаточно важным, чтобы оплатить его доставку получателю, в отличие от другой обычной бесплатной почты для получателя. То есть отправитель готов понести затраты, чтобы получатель открыл его eLetter, в отличие от отправителей остальной обычной «бесплатной» электронной почты.

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

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

- Кроме того, получатели находят такой вариант более простым и быстрым для просмотра, обзора, чтения и управления сообщениями eLetter благодаря следующим особенностям:

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

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

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

- Если получатель длительное время находится вдали от собственного терминала, он может арендовать почтовый ящик ePostal на веб-сайте ePost Office, в котором в течение этого времени будут храниться входящие сообщения eLetter. При помощи другого терминала с веб-браузером получатель может получить доступ к своему аккаунту и инструментам веб-сайта ePostal, чтобы прочесть (или отправить) свои сообщения eLetter.

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

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

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

- Все эти функции работают легко и "бесшовно" в собственных почтовых программах получателей.

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

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

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

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

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

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

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

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

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

Хотя изобретение было описано в отношении предпочтительных вариантов его осуществления, необходимо понимать, что специалисты, исходя из предшествующего подробного описания и приложенных чертежей, могут предложить различные его модификации и альтернативы. Например, хотя изобретение было описано касательно конкретного программного обеспечения, действующего на конкретном аппаратном обеспечении в конкретных местах, необходимо понимать, что описанные функции могут быть распределены между аппаратным, программным и встроенным программным обеспечением способом, хорошо известным в этой области техники. Кроме того, хотя описанные функции оплаты и учета выполняются сервером и программным обеспечением ePostal, они могут целиком или частично выполняться через связи ePost Office 20 и/или других компонентов системы 10 ePostal с традиционными онлайновыми службами кредитования и банковских услуг. Эти модификации и альтернативы находятся в объеме приложенной формулы изобретения.

Claims (42)

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

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

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

4. Система связи по п.3, в которой Интернет имеет прикладное программное обеспечение для работы с электронной почтой и функционирует на множестве терминалов отправителей и получателей, и указанное программное обеспечение отправителя и получателя работает внутри указанного прикладного программного обеспечения для работы с электронной почтой.

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

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

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

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

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

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

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

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

13. Система связи по п.12, в которой указанное назначение приоритетов представляет собой установление различий между почтой, обработанной указанными почтовыми сервером и программным обеспечением, и остальной электронной почтой, передаваемой в Интернете.

14. Система связи по п.12, в которой указанное назначение приоритетов включает установление различий внутри почты, обработанной указанными почтовыми сервером и программным обеспечением.

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

16. Система связи по любому из пп.1-15, в которой указанный почтовый сервер включает несколько серверов по меньшей мере в одном месте.

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

18. Система связи по п.17, в которой указанная прямая связь использует HTTP, SMTP или другие сокет-протоколы.

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

20. Система связи по п.19, в которой указанное содержимое сообщения передают при помощи протоколов SMTP/POP и/или IMAP через почтовые серверы Интернета, а указанные данные сообщения по меньшей мере частично передают при помощи HTTP, SMTP или других сокет-протоколов.

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

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

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

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

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

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

27. Способ по п.26, также включающий:
взаимодействие получателя с указанной электронной почтовой службой в ответ на указанный выбор или сообщение по электронной почте со стороны отправителя.

28. Способ по п.27, в котором указанная связь включает дальнюю связь.

29. Способ по п.27, в котором указанная связь включает объединение в сеть множества терминалов отправителей или получателей.

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

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

32. Способ по любому из пп.26-31, в котором по меньшей мере часть той части сообщения электронной почты, в которой находятся данные, передается в электронную почтовую службу и из нее при помощи прямой связи.

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

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

35. Способ по п.32, в котором указанная прямая связь использует HTTP, SMTP или другие сокет-протоколы.

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

37. Способ по п.36, в котором указанный компонент с содержимым сообщения передают при помощи протоколов SMTP/POP и/или IMAP через почтовые серверы Интернета, а указанный компонент с данными сообщения по меньшей мере частично передают при помощи HTTP, SMTP или других сокет-протоколов.

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

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

40. Способ по п.32, в котором указанная прямая связь в обоих направлениях с указанной электронной почтовой службой является обычным использованием протокола сеансов HTTPS с использованием cookies, сертификатов/ключей третьих сторон и единого протокола передачи.

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

42. Способ по п.30, в котором указанные авторизация и учет платы включают загрузку и установку файла установки программного обеспечения отправителя/получателя, установку указанного программного обеспечения отправителя и получателя на указанные терминалы отправителя и получателя, регистрацию аккаунта отправителя/получателя, проверку аккаунта и информации о кредитах для отправителя/получателя и активацию при помощи eLetter или прямой связи.

Images