УСТРОЙСТВО ПЕРЕДАЧИ, УСТРОЙСТВО ПРИЕМА, СПОСОБ УПРАВЛЕНИЯ ИМИ, СИСТЕМА СВЯЗИ И ПРОГРАММА Российский патент 2011 года по МПК H04N1/00 

Область техники, к которой относится изобретение

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

Предшествующий уровень техники

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

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

IFAX является технологией для связи между устройствами. Т.е., устройство передачи считывает изображение сканером, преобразует его в TIFF-изображение и передает данные получателю. Устройство приема декодирует TIFF-изображение из принятых данных и печатает его.

Относительно этой технологии японский выложенный патент № 2002-27193 раскрывает устройство для передачи данных изображения посредством использования протокола электронной почты. Это устройство передает данные изображения непосредственно устройству приема без вмешательства почтового сервера.

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

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

В системе, которая инструктирует устройство передачи передавать данные изображения устройству приема без вмешательства почтового сервера в соответствии со стандартом полного режима, конструкции, раскрытые в японских выложенных патентах №№ 2002-27193 и 2003-233558, могут непосредственно передавать данные изображения из устройства передачи устройству приема.

Однако устройство приема, которое должно передавать MDN-результат устройству передачи, не может определить, разрешает или нет прямую передачу получатель MDN-передачи.

Устройство приема всегда передает MDN через почтовый сервер, который, следовательно, является необходимым.

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

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

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

Сущность изобретения

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

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

модуль формирования, выполненный с возможностью формировать электронную почту;

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

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

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

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

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

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

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

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

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

В предпочтительном варианте осуществления, когда информация, представляющая собой способ ответа на запрос подтверждения передачи, установлена в "вмешательство сервера ВЫКЛЮЧЕНО", модуль передачи передает без вмешательства почтового сервера результат подтверждения передачи получателю ответа, представленному информацией о получателе ответа, описанной в электронной почте.

В предпочтительном варианте осуществления, когда информация, представляющая способ ответа на запрос подтверждения передачи, установлена в "вмешательство сервера ВЫКЛЮЧЕНО", модуль передачи получает информацию о получателе ответа результата подтверждения передачи в ответ на электронную почту от внешнего сервера и передает, без вмешательства почтового сервера, результат подтверждения передачи получателю ответа, представленному полученной информацией о получателе ответа.

В предпочтительном варианте осуществления модуль передачи содержит:

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

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

В предпочтительном варианте осуществления, когда результат анализа модулем анализа указывает, что информация, представляющая способ ответа на запрос подтверждения передачи, установлена в "вмешательство сервера ВЫКЛЮЧЕНО" в электронной почте, и описана информация о получателе ответа результата подтверждения передачи в ответ на электронную почту, модуль передачи передает без вмешательства почтового сервера результат подтверждения передачи, сформированный модулем формирования, получателю ответа, представленному информацией о получателе ответа.

В предпочтительном варианте осуществления, когда результат анализа модулем анализа указывает, что информация, представляющая способ ответа на запрос подтверждения передачи, установлена в "вмешательство сервера ВЫКЛЮЧЕНО" в электронной почте, и не описана информация о получателе ответа результата подтверждения передачи в ответ на электронную почту, модуль передачи получает информацию о получателе ответа результата подтверждения передачи в ответ на электронную почту от внешнего сервера и передает без вмешательства почтового сервера результат подтверждения передачи получателю ответа, представленному полученной информацией о получателе ответа.

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

устройство передачи, которое содержит:

модуль формирования, выполненный с возможностью формировать электронную почту;

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

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

устройство приема, которое содержит:

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

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

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

этап формирования электронной почты;

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

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

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

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

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

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

этап формирования электронной почты;

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

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

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

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

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

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

Перечень чертежей

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

Фиг. 2 является блок-схемой, показывающей размещение MFP согласно первому варианту осуществления настоящего изобретения;

Фиг. 3 является видом для объяснения конфигурации сетевой программы, установленной в MFP согласно первому варианту осуществления настоящего изобретения;

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

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

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

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

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

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

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

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

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

Оптимальный режим осуществления изобретения

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

<Первый вариант осуществления>

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

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

MFP 100 и 101 соединены с сетью с доменным именем, например, "xyz.co.jp" и с множеством компьютеров и сетевых устройств, включающих в себя сервер 103 и клиентский PC 104.

Эта сеть соединяется с Интернетом 110, который покрывает весь мир.

MFP 100 имеет HOST-имя "copy1.xyz.co.jp" и адрес электронной почты "ifax@copy1.xyz.co.jp" для устройства. MFP 101 имеет HOST-имя "copy2.xyz.co.jp" и адрес электронной почты "ifax@copy2.xyz.co.jp" для устройства.

PC 104 включает в себя программное обеспечение электронной почты общего назначения и имеет почтовый адрес "yamada@xyz.co.jp".

Сервер 103 имеет функцию почтового сервера (SMTP-сервера) и функцию POP-сервера. Сервер 103 имеет имя узла "pulser.xyz.co.jp" и также функцию DNS-сервера.

Отдельные терминалы могут быть подготовлены в качестве сервера, имеющего функцию почтового сервера, сервера, имеющего POP-функцию, и сервера, имеющего функцию DNS-сервера. Также может использоваться соответствующим образом интегрированный терминал. Коллективно руководящий сервер, имеющий DNS-функцию, в качестве терминала, независимого от MFP 100, предоставляет возможность различным видам MFP совместно использовать терминал, который взаимно преобразует доменные имена и IP-адреса.

Если доменное имя или IP-адрес изменяется, серверу нужно только изменить настройки. MFP 100 может включать в себя функцию DNS-сервера. В этом случае эффективность процесса, как предполагается, возрастет, так как соединение через сеть не выполняется.

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

Передача/прием данных делается посредством использования протоколов SMTP и POP3.

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

Например, чтобы передавать электронную почту клиенту 104 с почтовым адресом "yamada@xyz.co.jp", электронная почта, содержащая вложенные данные изображения, передается серверу 103 в соответствии с протоколом SMTP. Клиентский PC 104 может принять электронную почту в соответствии с протоколом POP3 и отобразить вложенное изображение в программе просмотра изображений общего назначения.

Режим передачи IFAX передает изображение, считанное функцией сканера MFP, или данные изображения, принятые функцией приема IFAX/FAX как TIFF-изображение на основе RFC2301. Принимающая сторона MFP печатает принятые данные изображения посредством своей функции принтера.

Компоновка MFP 100 будет описана далее со ссылкой на фиг. 2.

Компоновка MFP 100 будет приведена в качестве примера ниже. MFP 101 имеет ту же схему, что и MFP 100.

Фиг. 2 является блок-схемой, показывающей компоновку MFP согласно первому варианту осуществления настоящего изобретения.

CPU 130 управляет всей системой, используя RAM 132 и программы, сохраненные в ROM 131.

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

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

Отраженный от документа свет направляется через зеркала и линзы к CCD-датчику изображения, преобразуется в электрический сигнал и затем преобразуется в цифровые данные схемой аналого-цифрового (A/D) преобразования. После окончания операции считывания документа документ на стеклянном столе снимается.

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

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

Схема 136 обработки изображения, включающая в себя различные виды схем, таких как массовая память для хранения изображений, схема вращения изображения, схема масштабирования изображения и схемы кодирования/декодирования MH, MR, MMR, JBIG и JPEG, может выполнять различные виды обработки изображения, такие как затенение, подрезка и маскирование.

Жесткий диск 137 является массовым носителем записи, соединенным через I/F, такой как SCSI или IDE.

Сетевой интерфейс I/F 138 реализует линию передачи данных по сети, чтобы соединиться с сетевой линией, такой как Ethernet®, представленный посредством 10BASE-T, или 100BASE-T, или маркерным кольцом.

Модуль 139 форматирования принимает данные от внешнего устройства (например, клиентский PC 104) через I/F 142 PC, включающий в себя параллельный интерфейс, основанный на IEEE1284, и последовательный интерфейс, такой как USB, или сетевой I/F 138. Модуль 139 форматирования создает данные изображения из принятых данных (например, PDL (язык описания страниц)) и выполняет воспроизведение изображения, чтобы заставить схему 136 обработки изображений обработать данные, а принтер 135 распечатать их.

Модуль 140 факса является схемой I/F факса, соединенной с телефонной линией, и включает в себя схемы, такие как NCU (модуль управления сетью) и модем (модулятор/демодулятор).

Модуль 140 факса инструктирует схему 136 обработки изображений обрабатывать данные изображения, считанные сканером 134, и передает данные другому факс-устройству через телефонную линию. Модуль 140 факса также принимает данные, переданные от другого факс-устройства и инструктирует схему 136 обработки изображений обрабатывать данные, а принтеру 135 распечатывать их.

Сканер 134, принтер 135, схема 136 обработки изображений, модуль 139 форматирования и модуль 140 факса соединены с высокоскоростной шиной 142 видео, отличной от шины 141 CPU от CPU 130, чтобы передавать данные изображений с высокой скоростью.

Функция копирования осуществляется посредством инструктирования схемы 136 обработки изображений обрабатывать данные изображения, считанные сканером 134, и инструктирования принтера 135 печатать обработанные данные изображения.

Функция отправки (передача данных/передача файла) осуществляется посредством инструктирования схемы 136 обработки изображений обрабатывать данные изображения, считанные сканером 134, и передачи данных из сетевого I/F 138 в сеть. Функция IFAX осуществляется посредством инструктирования схемы 136 обработки изображений создавать изображение, согласующееся с RFC2301, и передачи/приема данных в соответствии с протоколом электронной почты.

Конфигурация сетевой программы, установленной в MFP 100, будет описана далее со ссылкой на фиг. 3.

Фиг. 3 является видом для объяснения конфигурации сетевой программы, установленной в MFP согласно первому варианту осуществления настоящего изобретения.

Сетевая программа грубо делится на IP-уровень 200, TCP/UDP-уровень 201 и прикладной уровень 202.

IP - это сокращение для "протокола Интернета". TCP - сокращение для "протокола управления передачей". UDP - сокращение для "протокола пользовательских дейтаграмм".

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

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

TCP/UDP-уровень 201 - это транспортный уровень, который предоставляет службу, чтобы отправить сообщение от службы приложений источника службе приложений приемника.

TCP - это служба соединения, которая гарантирует высокую надежность связи. UDP - это бессвязная служба, которая не гарантирует надежность.

Прикладной уровень 202 определяет множество протоколов. Примерами протоколов являются следующие.

FTP (протокол передачи файлов) - это служба передачи файлов. SNMP - это протокол управления сетью. LPD - это серверный протокол для печати с помощью принтера. HTTP - это протокол WWW (всемирная паутина) сервера.

SMTP (простой протокол пересылки почты) - это протокол передачи/приема электронной почты. POP3 (протокол почтового офиса версии 3) - это протокол загрузки электронной почты. LDAP (облегченный протокол доступа к каталогам) - это протокол для доступа к базе данных каталогов, которая управляет, например, адресом электронной почты пользователя. RFC1510 определяет программу Kerberos-аутентификации.

Пример рабочего окна операционного модуля 133 MFP 100 будет описан далее со ссылкой на фиг. 4.

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

Это окно регистрации таблицы получателей предоставляет возможность пользователю зарегистрировать различные виды получателей, включая IFAX-получателя MFP 101.

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

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

Поле 251 адреса является элементом для того, чтобы ввести адрес. В этом примере, в поле 251 адреса вводится адрес электронной почты "ifax@copy2.xyz.co.jp" MFP 101.

Поле 252 обозначения вмешательства сервера является переключателем для того, чтобы выбрать, передавать ли данные почтовому серверу и затем передавать их из почтового сервера к MFP 101 как намеченному получателю или непосредственно передавать данные к MFP 101. В этом примере установлено "ВЫКЛЮЧЕН", чтобы представить, что почтовый сервер не вмешивается. Чтобы заставить почтовый сервер вмешаться, устанавливается "ВКЛЮЧЕН".

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

Поля 253-256 обозначения разрешения являются переключателями, чтобы обозначить разрешения, которые могут приниматься посредством MFP 101.

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

На фиг. 4 выбраны поля 254 и 255 обозначения разрешения, указывающие, что разрешения, которые могут быть получены посредством MFP 101, это 200×400 точек на дюйм и 400×400 точек на дюйм.

Например, MFP 101 не может непосредственно принять изображение, отсканированное в разрешении 600×600 точек на дюйм. В этом случае разрешение отсканированного изображения преобразуется в наивысшее разрешение, которое может быть получено посредством MFP 101, т.е., 400×400 точек на дюйм.

Поля 257 и 258 обозначения размера бумаги - это переключатели, чтобы обозначить размеры бумаги, принимаемые MFP 101. Любое устройство может нормально принимать изображение размера A4, таким образом, пользователь не может выбрать A4.

MFP 101 может принимать изображения размеров B4 и A3. Следовательно, выбираются поля 257 и 258 обозначения размера бумаги.

Например, изображение, считанное в размере A3 в момент сканирования, передается к MFP 101 как изображение размера A3. Если принимающая сторона не может принять изображение размера A3, изображение передается после масштабирования к максимальному размеру бумаги, принимаемого принимающей стороной.

Поля 259 и 260 обозначения способа сжатия - это переключатели, чтобы выбрать форматы сжатых изображений, принимаемые MFP 101. В этом примере пользователь может определить MR и MMR. Коэффициент сжатия изображения документа, содержащего текст, становится больше в порядке MH<MR<MMR.

Любое устройство может нормально принять данные MH-сжатого изображения, таким образом, пользователь не может выбрать MH.

MFP 101 может принимать MR- и MMR-закодированные изображения. Следовательно, выбираются поля 259 и 260 определения способа сжатия.

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

Когда различные виды настроек в окне регистрации таблицы получателей выполнены, пользователь управляет кнопкой 270 ОК, чтобы закончить настройки, так что различные установленные значения сохраняются, например в RAM 132, в виде таблицы получателя. Чтобы отменить операцию настройки, пользователь может сбросить различные установленные значения, управляя кнопкой 271 отмены.

Структурный пример данных электронной почты согласно первому варианту осуществления будет описан далее со ссылкой на фиг. 5.

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

Фиг. 5 показывает структуру данных электронной почты, когда изображение, сканированное посредством MFP 100, вкладывается в электронную почту и передается к MFP 101.

Поле 300 "Дата" имеет информацию о времени, указывающую время передачи из MFP 100. Поле 301 "От" имеет адрес электронной почты MFP 100. Поле 302 "Кому" имеет адрес электронной почты MFP 101. Поле 303 "Тема" имеет символьную строку "изображение".

Поле 304 "Доставка-Уведомление-Кому" («Disposition-Notification-To») обозначает почтовый адрес для приема почтового сообщения подтверждения передачи (MDN-данные), переданное в ответ на запрос подтверждения передачи от MFP 100. В этом примере поле 304 содержит почтовый адрес MFP 100.

Поле 305 ID сообщения имеет число, представляющее ID, уникальный для почтового сообщения. Число содержит почтовый адрес и данные о времени, чтобы предотвратить существование почтовых сообщений с одинаковым номером. Поле 306 MIME-версии имеет номер версии MIME.

Поле 307 типа содержимого указывает, что данные электронной почты сегментированы на множество блоков, посредством символьной строки "-----_422E51E54FF704D75EF8_". Поле 308 представляет число битов, используемых для кодирования.

Поля 310-316 составляют один блок. Поле 311 указывает, что следующая часть содержит символьную строку, написанную JIS-кодами. Поле 314 содержит символьную строку данных, т.е. текст данных электронной почты.

Поля 316-330 составляют другой блок. Части информации в полях 317-219 показывают, что эта часть является TIFF-файлом изображения с именем файла "GS2005.tif". Поля 321-328 имеют данные, полученные посредством BASE64-кодирования файла.

Последовательность процесса SMTP-протокола в передаче данных электронной почты, показанная на фиг. 5 согласно первому варианту осуществления непосредственно от MFP 100 к MFP 101, будет описана далее со ссылкой на фиг. 6.

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

Как показано на фиг. 4, информация "вмешательство сервера ВЫКЛЮЧЕНО" в поле 252 обозначения вмешательства сервера таблицы получателя MFP 100 указывает, что MFP 100 может непосредственно передавать данные к MFP 101 без вмешательства почтового сервера.

Следовательно, для передачи к MFP 101, MFP 100 непосредственно соединяется по SMTP с MFP 101 (400).

Соединенный по SMTP MFP 101 отвечает символьной строкой (401), содержащей информацию о доменном имени.

Когда MFP 100 отправляет EHLO-команду (402), MFP 101 отвечает командами расширения SMTP, совместимыми с ним, вместе с символьными строками, начинающимися с "250-" (403).

Подробные команды расширения SMTP (команды, представляющие функции MFP 101) указаны ссылочными номерами 404-406. MFP 101 имеет функцию приема 8-битных данных электронной почты, функцию шифрования маршрута связи посредством TLS-шифрования и функцию прямого ответа для непосредственного ответа MDN.

В этом случае MFP 101 передает к MFP 100 команду (404) 8BITMIME, представляющую функцию приема 8-битных данных электронной почты, и команду (405) STARTTLS, представляющую функцию шифрования маршрута связи посредством TLS-шифрования. MFP 101 также передает к MFP 100 команду (406) DIRECTMDN, представляющую функцию прямого MDN-ответа (способ ответа).

MFP 101 имеет переключатель, чтобы установить "ВКЛЮЧЕНИЕ/ВЫКЛЮЧЕНИЕ прямого MDN-ответа" в качестве настройки устройства. Только когда функция прямого MDN-ответа установлена во "ВКЛЮЧЕНО", MFP 101 непосредственно отвечает посредством MDN в ответ на команду (407) DIRECTMDN от MFP 100. Если функция установлена в "ВЫКЛЮЧЕНО", MFP 101 непосредственно не отвечает посредством MDN в ответ на команду (407) DIRECTMDN от MFP 100.

Команда (407) DIRECTMDN от MFP 100 является командой для того, чтобы запросить прямой MDN-ответ. Прямой MDN-ответ указывает непосредственный MDN-ответ получателю передачи без вмешательства почтового сервера.

Если таблица получателя MFP 100 зарегистрирована в таблице получателя в MFP 101, содержимое установки ("вмешательство сервера ВКЛЮЧЕНО/ВЫКЛЮЧЕНО) поля 25 обозначения вмешательства сервера (фиг. 4) может быть получено из таблицы получателя. В этом случае, разрешать ли прямой MDN-ответ, может быть определено на основе содержимого установки. Т.е., если "вмешательство сервера ВЫКЛЮЧЕНО" установлено в качестве содержимого установки, MDN может быть отправлен в ответ непосредственно.

Фиг. 6 снова будет описан.

При нормальном приеме команды (407) DIRECTMDN от MFP 100, MFP 101 отвечает обычным ответным сообщением (408), начинающимся с "250".

Далее MFP 100 передает к MFP 101 команду (409) MAIL, представляющую отправителя почты. При нормальном ее приеме MFP 101 отвечает обычным ответным сообщением (410), начинающимся с "250". MFP 100 передает команду (411) RCPT, представляющую получателя почты. При нормальном ее приеме MFP 101 отвечает обычным ответным сообщением (412), начинающимся с "250".

MFP 100 передает команду (413) DATA, указывающую, что передача данных электронной почты будет начата, и затем передает данные электронной почты (данные, указанные полями 300-329 на фиг. 5). После этого MFP 100 передает "." (414), указывая окончание данных электронной почты.

При нормальном приеме данных электронной почты от MFP 100, MFP 101 отвечает обычным ответным сообщением (415), начинающимся с "354".

MFP 100 передает команду (416) QUIT для того, чтобы разъединиться. Отвечая на это, MFP 101 отвечает сообщением (417), начинающимся с "221".

С вышеописанным процессом SMTP-соединение между MFP 100 и 101 заканчивается.

Процесс SMTP-приема посредством функции SMTP-приема MFP 101 будет описан далее со ссылкой на фиг. 7.

Фиг. 7 является блок-схемой, показывающей процесс SMTP-приема согласно первому варианту осуществления настоящего изобретения.

Этот процесс SMTP-приема реализуется для того, чтобы принять, например, данные электронной почты, переданные по SMTP, от MFP 100 или клиентского PC 104.

При включении питания активируется функция SMTP-приема. На этапе S501 MFP 101 ожидает соединения.

Когда SMTP-соединение начинается, процесс продвигается от этапа S501 к S502, чтобы выполнить процесс (401 на фиг. 6) отправки ответа на соединения для отправки ответа на SMTP-соединение.

После отправки ответа на соединение MFP 101 проверяет принятую команду, чтобы определить на этапе S503, является ли команда командой EHLO. Если команда является командой EHLO (ДА на этапе S503), процесс переходит к этапу S506. Если команда не является командой EHLO (НЕТ на этапе S503), MFP 101 определяет на этапе S504, является ли команда командой HELO.

Если команда является командой HELO (ДА на этапе S504), процесс переходит к этапу S515. Если команда не является командой HELO (НЕТ на этапе S504), процесс переходит к этапу S505, чтобы рассмотреть состояние как ошибку команды, и ожидать новый прием команды.

Если принятая команда является командой HELO, на этапе S504, MFP 101 выполняет процесс отправки ответа на команду HELO на этапе S515, и процесс переходит к этапу S516.

Если принятая команда является командой EHLO на этапе S503, MFP 101 выполняет процесс отправки ответа на команду EHLO на этапе S506, чтобы отправить в ответ, в качестве ответов на команду EHLO, сообщения, содержащие функции выполнения SMTP, подготовленные в MFP 101.

Сообщениями являются 8BITMIME 404, STARTTLS 405 и DIRECTMDN 406 на фиг. 6.

MFP 101 проверяет команды, производимыми своими функциями расширения SMTP. Сначала MFP 101 определяет на этапе S507, воспроизводима ли команда 8BITMIME. Если команда 8BITMIME невоспроизводима (НЕТ на этапе S507), процесс переходит к этапу S509. Если команда 8BITMIME воспроизводима (ДА на этапе S507), процесс переходит к этапу S508, чтобы выполнить процесс отправки в ответ OK для отправки символьной строки "250 ОК".

MFP 101 определяет на этапе S509, воспроизводима ли команда DIRECTMDN. Если команда DIRECTMDN невоспроизводима (НЕТ на этапе S509), процесс переходит к этапу S512. Если команда DIRCTMDN воспроизводима (ДА на этапе S509), процесс переходит к этапу S510, чтобы выполнить процесс отправки в ответ OK для отправки символьной строки "250 ОК". На этапе S511 MFP 101 сохраняет в RAM 132 IP-адрес источника выдачи запроса соединения.

MFP 101 определяет на этапе S512, воспроизводима ли команда STARTTLS. Если команда STARTTLS невоспроизводима (НЕТ на этапе S512), процесс переходит к этапу S516. Если команда STARTTLS воспроизводима (ДА на этапе S512), процесс переходит к этапу S513, чтобы выполнить процесс отправки в ответ OK для отправки символьной строки "250 ОК". На этапе S514 MFP 101 выполняет процесс TLS-шифрования.

На этапе S516 MFP 101 выполняет обработку команды MAIL. MFP 101 принимает адресную информацию об отправителе почты, установленную в нем как команда (409 на фиг. 6) MAIL и передает ответ (410 на фиг. 6) на команду MAIL, содержащий символьную строку, начинающуюся с "250".

На этапе S517 MFP 101 выполняет обработку команды RCPT. MFP 101 принимает команду (411 на фиг. 6) RCPT, содержащую информацию об адресе почты получателя передачи, и передает ответ (412 на фиг. 6) на команду RCPT, содержащий символьную строку, начинающуюся с "250".

На этапе S518 MFP 101 выполняет процесс приема команды DATA. MFP 101 принимает команду (413 на фиг.6) DATA, указывающую, что передача данных электронной почты на фиг. 5 будет начата. MFP 101 затем принимает переданные данные электронной почты (300-329 и 414 на фиг. 6) и передает ответ (415 на фиг. 6) на команду DATA, содержащий символьную строку, начинающуюся с "354".

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

На этапе S519 MFP 101 выполняет обработку команды QUIT. MFP 101 принимает команду QUIT (416 на фиг. 6), чтобы разъединиться, и отправляет в ответ команду QUIT (417 на фиг. 6), содержащую символьную строку, начинающуюся с "221", чтобы разъединить SMTP-соединение.

Когда вышеописанный процесс заканчивается, SMTP-прием заканчивается.

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

Часть данных изображения (321-328) данных электронной почты является BASE64-декодированной в TIFF-файл. Данные изображения каждой страницы извлекаются из TIFF-файла и подвергаются процессу декодирования изображения. Когда процесс декодирования изображения всех страниц нормально завершен, создаются MDN-данные, показанные на фиг. 8.

Структурный пример MDN-данных согласно первому варианту осуществления будет описан далее.

Фиг. 8 является видом, показывающим структурный пример MDN-данных по первому варианту осуществления настоящего изобретения.

Поля 600-607 на фиг. 8 соответствуют почтовому заголовку почты.

Поле 600 "Дата" имеет информацию о времени, указывающую время передачи данных. Поле 601 "От" имеет адрес электронной почты MFP 101 в качестве источника передачи почты. Поле 602 "Тема" имеет символьную строку "Уведомление о доставке сообщения".

Поле 603 "Кому" содержит получателя, установленного в поле 304 "Доставка-Уведомление-Кому" почты с вложенным изображением, описанном со ссылкой на фиг. 5. Следовательно, MDN-данные передаются этому получателю.

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

Поле 605 MIME-версии имеет номер версии MIME. Поле 606 типа содержимого содержит информацию, указывающую, что почта является почтовым уведомлением отчетного типа.

Поле 607 имеет информацию, указывающую, что почта сегментирована по границе "xiSCzkWI5qcO+uiWI6qaM+ueTIB6". В этом примере почта сегментирована полями 609, 615 и 622. Почта сегментирована на первую часть, соответствующую полям 610-614, и вторую часть, соответствующую полям 616-621.

Поле 610 указывает, что первая часть является текстовыми данными. Поля 612 и 613 содержат символьную строку данных.

Поле 616 указывает, что вторая часть является уведомляющим сообщением. Поле 618 описывает имя узла и доменное имя MFP 101, которое создало это сообщение.

Поле 619 ID оригинального сообщения содержит ID 304 почтового сообщения с вложенным изображением, описанного со ссылкой на фиг. 5, чтобы сделать возможным определение почтового сообщения, которому это уведомление будет соответствовать.

Поле 620 "Доставка" указывает, что это уведомляющее почтовое сообщение отправляется в ответ автоматически, а результат нормально обрабатывается.

Процесс MDN-передачи, заставляющий MFP 101 передавать MDN-данные, будет описан далее со ссылкой на фиг. 9.

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

Этот процесс начинается, чтобы передавать MDN.

На этапе S701 MFP 101 определяет, имеет ли отправитель назначенный "MDNDIRECT", обращаясь к содержимому команды DIRECTMDN (407 на фиг. 6). Если "MDNDIRECT" обозначен (ДА на этапе S701), процесс переходит к этапу S702, чтобы передавать MDN-данные на фиг. 8 получателю, соответствующему IP-адресу, сохраненному на этапе S511, и закончить процесс.

Если "MDNDIRECT" не обозначен (НЕТ на этапе S701), процесс переходит к этапу S703, чтобы передавать MDN-данные почтовому серверу (например, серверу 103) и закончить процесс. MDN-данные, переданные почтовому серверу, окончательно передаются, через почтовый сервер, получателю, указанному полем "Доставка-Уведомление-Кому" почтового сообщения с вложенным изображением, описанным со ссылкой на фиг. 5.

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

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

<Второй вариант осуществления>

Во втором варианте осуществления будет описан пример применения процесса MDN-передачи первого варианта осуществления.

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

Этот процесс начинается, чтобы передавать MDN.

На этапе S801 MFP 101 определяет, имеет ли отправитель назначенный "MDNDIRECT", обращаясь к содержимому команды DIRECTMDN (407 на фиг. 6). Если "MDNDIRECT" назначен (ДА на этапе S801), процесс переходит к этапу S802. На этапе S802 MFP 101 запрашивает DNS-сервер (сервер 103) о получателе, указанном полем "Доставка-Уведомление-Кому" почтового сообщения с вложенным изображением, описанном со ссылкой на фиг. 5, и запрашивает IP-адрес получателя передачи.

DNS-сервер получает IP-адрес получателя, используя запись A имени хоста или запись MX (почтовый коммутатор), предназначенную для передачи почты.

На этапе S803 MFP 101 передает MDN-данные, показанные на фиг. 8, получателю, соответствующему IP-адресу, полученному на этапе S802, используя протокол SMTP, и заканчивает процесс.

Если "MDNDIRECT" не обозначен (НЕТ на этапе S801), процесс переходит к этапу S804, чтобы передавать MDN-данные почтовому серверу (например, серверу 103) и закончить процесс. MDN-данные, переданные почтовому серверу, окончательно передаются, через почтовый сервер, получателю, указанному полем "Доставка-Уведомление-Кому" почтового сообщения с вложенным изображением, описанным со ссылкой на фиг. 5.

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

<Третий вариант осуществления>

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

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

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

Фиг. 11 показывает структуру данных электронной почты, когда изображение, сканированное посредством MFP 100, вкладывается в электронную почту и передается к MFP 101.

Поле 900 "Дата" имеет информацию о времени, указывающую время передачи из MFP 100. Поле 901 "От" имеет адрес электронной почты MFP 100. Поле 902 "Кому" имеет адрес электронной почты MFP 101. Поле 903 "Тема" имеет символьную строку "изображение".

Поле 904 "Доставка-Уведомление-Кому" обозначает почтовый адрес, чтобы принять почтовое сообщение подтверждения передачи (MDN-данные), переданное в ответ на запрос подтверждения передачи от MFP 100. В этом примере поле 904 содержит почтовый адрес MFP 100.

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

Поле 906 ID сообщения имеет число, представляющее ID, уникальный для почтового сообщения. Число содержит почтовый адрес и данные о времени, чтобы предотвратить существование почтовых сообщений с одинаковым номером. Поле 907 MIME-версии имеет номер версии MIME.

Поле 908 типа содержимого указывает, что данные электронной почты сегментированы на множество блоков посредством символьной строки "-----_422E51E54FF704D75EF8_".

Поля 911-916 составляют один блок. Поле 911 указывает, что следующая часть содержит символьную строку, написанную JIS-кодами. Поле 915 содержит символьную строку данных.

Поля 917-931 составляют другой блок. Части информации в полях 917-920 показывают, что эта часть является TIFF-файлом изображения с именем файла "GS2005.tif". Поля 922-929 имеют данные, полученные BASE64-кодированием файла.

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

Процесс анализа данных электронной почты, когда MFP 101 принимает данные электронной почты, показанные на фиг. 11, будет описан далее со ссылкой на фиг. 12.

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

По приему данных электронной почты MFP 101 выполняет процесс извлечения изображения на этапе S951. Текстовые данные почтового сообщения (915 на фиг. 11) преобразуются из текстовой информации JIS-кодов в текстовую информацию SJIS-кодов и затем растрируются в данные изображения.

Часть данных изображения (922-929 на фиг. 11) данных электронной почты является BASE64-декодированной в TIFF-файл. Данные изображения каждой страницы извлекаются из TIFF-файла и подвергаются процессу декодирования изображения.

MFP 101 определяет на этапе S952, существует ли получатель в поле "Доставка-Уведомление-Кому" (904 на фиг. 11).

Если получатель существует (ДА на этапе S952), процесс переходит к этапу S953, чтобы извлечь информацию ("ifax@copy1.co.jp"), чтобы передавать MDN-данные. На этапе S954 MFP 101 создает MDN-данные для информации о получателе и передает MDN-данные.

Если получатель не существует (НЕТ на этапе S952), процесс переходит к этапу S955, чтобы определить, существует ли поле X-MDNDIRECT (905 на фиг. 11).

Если процесс переходит к этапу S955 при определении на этапе S952, что получатель не существует в поле "Доставка-Уведомление-Кому", процесс переходит к этапу S959. Вот почему отсутствие поля "Доставка-Уведомление-Кому" указывает отсутствие запроса MDN, и, следовательно, поле X-MDNDIRECT не существует в принципе. Наоборот, чтобы запросить MDN, необходимо добавить поле "Доставка-Уведомление-Кому".

Если поле X-MDNDIRECT существует (ДА на этапе S955), процесс переходит к этапу S956, чтобы запросить DNS-сервер о получателе, указанном полем "Доставка-Уведомление-Кому", и получить IP-адрес получателя передачи.

DNS-сервер получает IP-адрес, указанный полем "Доставка-Уведомление-Кому", используя запись A имени узла или запись MX (почтовый коммутатор), предназначенную для передачи почты. На этапе S957 MFP 101 передает MDN-данные получателю, соответствующему IP-адресу, полученному на этапе S956, используя протокол SMTP.

Если поле X-MDNDIRECT не существует (НЕТ на этапе S955), MFP 101 передает MDN-данные почтовому серверу (например, серверу 103) на этапе S958.

На этапе S959 MFP 101 определяет присутствие/отсутствие установки печати для данных изображения, извлеченных из принятых данных электронной почты. Если установка печати существует (ДА на этапе S959), процесс переходит к этапу S960, чтобы выполнить печать в соответствии с установкой печати. Если установка печати не существует (НЕТ на этапе S959), процесс переходит к этапу S961, чтобы определить присутствие/отсутствие передачи.

Если установка передачи существует (ДА на этапе S961), процесс переходит к этапу S962, чтобы выполнить передачу в соответствии с установкой передачи. Примерами получателя передачи на основе установки передачи являются получатели передачи файлов FAX, IFAX, FTP и SMB.

Если установка передачи не существует (НЕТ на этапе S961), процесс заканчивается.

Присутствие/отсутствие установки печати и установки передачи на этапах S956 и 961 определяется на основе, например, информации атрибутов, установленной в данных электронной почты после ее приема.

SMTP и POP-приемы были описаны выше в качестве способа приема электронной почты. Данные электронной почты могут быть приняты посредством другого предварительно определенного протокола передачи, такого как IMAP.

Как описано выше, третий вариант осуществления описывает информацию, указывающую запрос MDN-данных в данных электронной почты вместо передачи запроса MDN-данных в соответствии с протоколом SMTP.

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

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

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

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

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

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

Примерами носителей записи, которые могут использоваться для поставки программы, являются гибкий диск, жесткий диск, оптический диск, магнитно-оптический диск, CD-ROM, CD-R, CD-RW, магнитная лента, карта памяти энергонезависимого типа, ROM и DVD (DVD-ROM и DVD-R).

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

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

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

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

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

Эта заявка заявляет приоритет японской патентной заявки № 2005-373519, поданной 26 декабря 2005 г., которая при этом включена в настоящий документ в своей полноте посредством ссылки.

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

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

2. Устройство передачи по п.1, в котором запрашивающий модуль выполняет упомянутое запрашивание, когда модуль передачи передает электронную почту на устройство приема не через почтовый сервер.

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

4. Устройство передачи по п.3, в котором протоколом связи является SMTP.

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

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

7. Устройство приема по п.6, в котором модуль передачи передает результат подтверждения передачи через почтовый сервер в случае, когда модулем определения определено, что устройство приема не запрошено устройством передачи передать результат подтверждения передачи не через почтовый сервер.

8. Устройство приема по п.6, в котором модуль определения определяет, что устройство приема запрошено устройством передачи передать, не через почтовый сервер, результат подтверждения передачи в случае, когда информация запроса для запрашивания устройства приема передать, не через почтовый сервер, результат подтверждения передачи принята в виде команды в протоколе связи, используемом при приеме электронной почты модулем приема.

9. Устройство передачи по п.8, в котором протоколом связи является SMTP.

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

11. Устройство приема по п.6, в котором модуль передачи передает результат подтверждения передачи на устройство передачи.

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

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

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

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

16. Устройство приема для приема электронной почты через сеть, содержащее:
модуль приема, выполненный с возможностью принимать от устройства передачи электронную почту;
модуль определения, выполненный с возможностью определять, в случае когда модуль приема принимает электронную почту, возможно ли передать, не через почтовый сервер, результат подтверждения передачи касаемо электронной почты от устройства передачи; и
модуль передачи, выполненный с возможностью передавать, не через почтовый сервер, результат подтверждения передачи, в случае когда модулем определения определено, что возможно передать, не через почтовый сервер, результат подтверждения передачи.

17. Устройство приема по п.16, в котором модуль передачи передает результат подтверждения передачи через почтовый сервер в случае, когда модулем определения определено, что невозможно передать результат подтверждения передачи не через почтовый сервер.

18. Устройство приема по п.16, в котором модуль определения определяет, что возможно передать, не через почтовый сервер, результат подтверждения передачи в случае, когда информация запроса для запрашивания устройства приема передать, не через почтовый сервер, результат подтверждения передачи принята в виде команды в протоколе связи, используемом при приеме электронной почты модулем приема.

19. Устройство приема по п.18, в котором протоколом связи является SMTP.

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

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

22. Устройство приема для приема электронной почты через сеть, содержащее:
модуль приема, выполненный с возможностью принимать от устройства передачи электронную почту;
модуль определения, выполненный с возможностью определять, в случае когда модуль приема принимает электронную почту, что результат подтверждения передачи касаемо электронной почты от устройства передачи следует передать не через почтовый сервер или что этот результат подтверждения передачи следует передать через почтовый сервер; и
модуль передачи, выполненный с возможностью передавать результат подтверждения передачи не через почтовый сервер, в случае когда модулем определения определено, что результат подтверждения передачи следует передать не через почтовый сервер, и передавать результат подтверждения передачи через почтовый сервер, в случае когда модулем определения определено, что результат подтверждения передачи следует передать через почтовый сервер.

23. Устройство приема по п.22, в котором модуль определения выполняет упомянутое определение на основе предопределенной информации уведомления, переданной устройством передачи.

24. Устройство приема по п.23, в котором упомянутая предопределенная информация уведомления передается устройством передачи в виде команды в протоколе связи, используемом при приеме электронной почты модулем приема.

25. Устройство приема по п.24, в котором протоколом связи является SMTP.

26. Устройство приема по п.23, в котором упомянутая предопределенная информация уведомления включена в электронную почту, принятую модулем приема.

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

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

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

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