Результат интеллектуальной деятельности: СПОСОБ ОТПРАВКИ ЭЛЕКТРОННОГО ФАЙЛА

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

Настоящее изобретение, в общем, относится к способу отправки электронного файла. В частности, настоящее изобретение относится к способу отправки зашифрованного электронного файла. По настоящей заявке на патент испрашивается приоритет по дате подачи японской заявки на патент № 2008-332456, поданной 26 декабря 2008 г., содержимое которой включено в этот документ по ссылке.

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

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

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

[Патентный документ 1] Публикация японской заявки на патент № 2007-306261

[Патентный документ 2] Публикация японской заявки на патент № 2005-141746

Раскрытие изобретения

Техническая задача

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

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

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

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

Решение задачи

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

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

Лучший способ осуществления изобретения

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

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

Фиг.1 является блок-схемой, изображающей иллюстративную конфигурацию системы связи, относящейся к первому варианту осуществления настоящего изобретения. Как изображено на фиг.1, система 100 связи преимущественно включает в себя отправляющее (передающее) устройство 110, приемное устройство 120, сервер 130 управления и сервер 140 электронной почты. Эти устройства и серверы выполнены с возможностью соединения с сетью 150 связи, в том числе с Internet. Сеть 150 связи может включать в себя сети мобильной и стационарной связи.

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

Аналогично, приемное устройство 120 может быть, например, персональным компьютером, мобильным телефоном, PDA и т.п. Приемное устройство 120 принимает через сеть 150 связи электронную почту, переданную из передающего устройства 110.

Сервер 140 электронной почты принимает через сеть 150 связи электронную почту, переданную из передающего устройства 110, и передает принятую электронную почту в приемное устройство 120 через сеть 150 связи.

Сервер 130 управления передает ключевое слово, необходимое для расшифровки электронного файла, зашифрованного передающим устройством 110, из передающего устройства 110 в приемное устройство 120 через сеть 150 связи.

Внутренние структуры передающего и приемного устройств и сервера управления

"Внутренняя структура передающего устройства 110"

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

Передающее устройство 110 преимущественно включает в себя управляющее/обрабатывающее звено 220, звено 230 для хранения информации, звено 240 связи и звено 250 вывода на экран.

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

Звено 240 связи передает электронную почту в приемное устройство 120, передает ключевое слово в сервер 130 управления и т.п. под управлением управляющего/обрабатывающего звена 220.

Звено 250 вывода на экран выводит на экран пользователя передающего устройства 110 (отправителя) результат операций, выполняемых управляющим/обрабатывающим звеном 220, под управлением управляющего/обрабатывающего звена 220.

Управляющее/обрабатывающее звено 220 управляет звеном 230 для хранения информации, звеном 240 связи и звеном 250 вывода на экран для реализации операций, необходимых для обеспечения способа отправки электронного файла, относящегося к первому варианту осуществления настоящего изобретения. А именно, управляющее/обрабатывающее звено 220 исполняет прикладные программы, хранящиеся в звене 230 для хранения информации, для управления звеном 230 для хранения информации, звеном 240 связи и звеном 250 вывода на экран, посредством чего реализует операции, необходимые для обеспечения способа передачи электронного файла, относящегося к первому варианту осуществления настоящего изобретения, которые включают в себя, например, шифровку электронного файла, передачу электронной почты с присоединенным к ней зашифрованным электронным файлом и передачу ключевого слова, необходимого для расшифровки зашифрованного электронного файла.

"Внутренняя структура сервера 130 управления"

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

Сервер 130 управления преимущественно включает в себя управляющее/обрабатывающее звено 310, звено 320 связи и звено 330 для хранения информации.

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

Управляющее/обрабатывающее звено 310 управляет звеном 320 связи для связи с передающим устройством 110 (прием ключевого слова и т.п. из передающего устройства 110) и связи с приемным устройством 120 (передача электронной почты в приемное устройство 120, прием открытого ключа из приемного устройства 120 и передача ключевого слова в приемное устройство 120).

Управляющее/обрабатывающее звено 310 управляет звеном 320 связи и звеном 330 для хранения информации для реализации операций, необходимых для обеспечения способа передачи электронного файла, относящегося к первому варианту осуществления настоящего изобретения. А именно, управляющее/обрабатывающее звено 310 исполняет прикладные программы, хранящиеся в звене 330 для хранения информации, для управления звеном 330 для хранения информации и звеном 320 связи, посредством чего реализует операции, необходимые для обеспечения способа передачи электронного файла, относящегося к первому варианту осуществления настоящего изобретения, которые включают в себя, например, прием ключевого слова и т.п. из передающего устройства 110 и передачу ключевого слова в приемное устройство 120.

"Внутренняя структура приемного устройства 120"

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

Приемное устройство 120 преимущественно включает в себя управляющее/обрабатывающее звено 410, звено 420 для хранения информации, звено 430 связи и звено 440 вывода на экран.

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

Управляющее/обрабатывающее звено 410 управляет звеном 430 связи для приема электронной почты из передающего устройства 110, приема электронной почты из сервера 130 управления, приема ключевого слова из сервера 130 управления и т.п.

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

Управляющее/обрабатывающее звено 410 управляет звеном 420 для хранения информации, звеном 430 связи и звеном 440 вывода на экран для реализации операций, необходимых для обеспечения способа передачи электронного файла, относящегося к первому варианту осуществления настоящего изобретения. А именно, управляющее/обрабатывающее звено 410 исполняет прикладные программы, хранящиеся в звене 420 для хранения информации, для управления звеном 420 для хранения информации, звеном 430 связи и звеном 440 вывода на экран, посредством чего реализует операции, необходимые для обеспечения способа передачи электронного файла, относящегося к первому варианту осуществления настоящего изобретения, которые включают в себя, например, прием электронной почты из передающего устройства 110, передачу открытого ключа в сервер 130 управления и прием ключевого слова из сервера 130 управления.

Порядок операций способа передачи электронного файла

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

"Операции, выполняемые между передающим устройством 110 и серверами 130 и 140 управления и электронной почты"

На фиг.5 схематично изображены операции, выполняемые между передающим устройством 110 и серверами 130 и 140 управления и электронной почты, для способа передачи электронного файла, относящегося к первому варианту осуществления настоящего изобретения.

На этапе A1 специализированное приложение устанавливается заранее в передающее устройство 110.

На этапе A2 отправитель X, который является пользователем передающего устройства 110, использует приложение, например Office(r), для создания электронного файла, который должен быть передан получателю Y, который является пользователем приемного устройства 120. На фиг.5 изображен файл 501 Word(r) в качестве примера созданного электронного файла.

На этапе A3 отправитель X назначает электронный файл 501 в качестве электронного файла, для которого требуется безопасная передача, в специализированном приложении. А именно, звено 250 вывода на экран передающего устройства 110 выводит на экран окно 502 посредством специализированного приложения. В то время как окно 502 выводится на экран, отправитель X перетаскивает электронный файл 501 в поле 503 внутри окна 502 для назначения электронного файла 501 в качестве файла, который должен быть передан.

На этапе A4 отправитель X назначает, на специализированном приложении, адрес электронной почты получателя, которому разрешается открывать файл (здесь, получатель Y). А именно, отправитель X вводит адрес электронной почты получателя Y в поле 504 "предполагаемый получатель".

Кроме того, отправитель X назначает, в специализированном приложении, действия, которые получателю Y разрешается или запрещается выполнять над электронным файлом 501. А именно, например, отправитель X не отмечает поле 505 "ограничения просмотра" при разрешении получателю Y выполнять все действия над электронным файлом 501.

С другой стороны, отправитель X отмечает поле 505 "ограничения просмотра", когда отправитель X хочет наложить некоторое ограничение на действия с электронным файлом 501. Если отправитель X хочет ограничить количество просмотров электронного файла 501, то отправитель X отмечает поле 506 "подсчет просмотров" и вводит в поле 507 количество просмотров электронного файла 501. Если отправитель X хочет запретить печать электронного файла 501, то отправитель X отмечает поле 508 "печать". Аналогично, если отправитель X хочет запретить действие с буфером обмена над электронным файлом 501, то отправитель X отмечает поле 509 "действие с буфером обмена". Информация, введенная отправителем X вышеупомянутым способом, сохраняется как "информация о запрете и разрешении просмотра". Эта информация о запрете и разрешении просмотра используется для обеспечения возможности отправителю X управлять (разрешать и/или запрещать) операциями (действиями), которые могут выполняться получателем Y над электронным файлом 501. Конкретные способы для реализации этой функции управления описаны ниже применительно ко второму варианту осуществления.

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

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

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

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

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

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

Вернемся к передающему устройству 110, на этапе A8 специализированное приложение передает электронную почту 512 с присоединенным к ней зашифрованным электронным файлом 511. Электронную почту 512 передают в приемное устройство 120 через сервер 140 электронной почты.

"Операции, выполняемые между приемным устройством 120 и серверами 130 и 140 управления и электронной почты (до завершения регистрации пользователя)"

После приема адреса электронной почты получателя Y из передающего устройства 110 на этапе A6 сервер 130 управления принимает решение о том, зарегистрирован ли получатель Y как пользователь на сервере 130 управления. Здесь, предполагается случай, когда получатель Y не зарегистрирован как пользователь.

На фиг.6 схематично изображены операции, выполняемые между приемным устройством 120 и серверами 130 и 140 управления и электронной почты, для способа передачи электронного файла, относящегося к первому варианту осуществления настоящего изобретения.

На этапе B1 сервер 130 управления формирует электронную почту 601, включающую в себя, например, в своей основной части маркер (последовательность данных), который сформирован на основе случайной информации. Основная часть электронной почты 601, например, также включает в себя URL web-сайта, который обеспечивает инсталлятор специализированного приложения (программы просмотра). В первом варианте осуществления URL является URL сервера 130 управления, например. Сервер 130 управления передает электронную почту 601 в приемное устройство 120.

На этапе B2 приемное устройство 120 принимает электронную почту 512, переданную (на этапе A8) из передающего устройства 110, через сервер 140 электронной почты. На этом этапе приемное устройство 120 не может открыть зашифрованный электронный файл 511, присоединенный к принятой электронной почте 512, так как у него нет ключевого слова для расшифровки.

На этапе B3 приемное устройство 120 принимает электронную почту 601, переданную (на этапе B1) из сервера 130 управления. В основной части электронной почты 601 существует маркер и URL, как обсуждалось выше.

На этапе B4 получатель Y щелкает мышкой по URL, записанному в основной части электронной почты 601, так что приемное устройство 120 использует URL для получения доступа к серверу 130 управления для загрузки инсталлятора 602 специализированного приложения (программы просмотра) из сервера 130 управления. После этого приемное устройство 120 исполняет загруженный инсталлятор 602 для установки специализированного приложения (программы просмотра).

Во время установки, как изображено (на) этапе B5, инсталлятор 602 формирует криптографическую пару асимметричной криптосистемы, другими словами, секретный ключ 603 и соответствующий открытый ключ 604. Сформированный секретный ключ 603 неявно сохраняется.

Кроме того, во время установки инсталлятор 602 вызывает вывод на экран звеном 440 вывода на экран диалогового окна 605 и запрашивает у получателя Y ввод маркера, записанного в основной части электронной почты 601, как изображено (на) этапе B6.

После завершения установки специализированного приложения (программы просмотра) на этапе B7 активизированное специализированное приложение передает в сервер 130 управления открытый ключ 604, сформированный на этапе B5, и результат, полученный при шифровке маркера, введенного на этапе B6, с использованием секретного ключа 603, сформированного на этапе B5. В качестве альтернативы, специализированное приложение может передавать в сервер 130 управления маркер, введенный на этапе B6, без кодирования.

На этапе B8 открытый ключ и зашифрованный маркер, переданный из приемного устройства 120, принимаются сервером 130 управления. Сервер 130 управления расшифровывает зашифрованный маркер, принятый из приемного устройства 120, с использованием принятого открытого ключа. Сервер 130 управления принимает решение о том, что получатель Y является надлежащим регистрируемым пользователем, когда расшифрованный маркер совпадает с маркером, переданным из сервера 130 управления на этапе B1, и регистрирует получателя Y как пользователя. А именно, сервер 130 управления сохраняет адрес электронной почты получателя Y и открытый ключ совместно друг с другом в базе данных 330a. Другими словами, принятый открытый ключ сохраняется в базе данных 330a совместно с адресом электронной почты получателя Y как надлежащий открытый ключ получателя Y. Следовательно, регистрация получателя Y как пользователя завершается.

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

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

"Операции, выполняемые между приемным устройством 120 и серверами 130 и 140 управления и электронной почты (после завершения регистрации пользователя)"

Как описано выше, сервер 130 управления принимает решение о том, зарегистрирован ли получатель Y как пользователь на сервере 130 управления, при приеме адреса электронной почты получателя Y из передающего устройства 110 на этапе A6. Здесь предполагается случай, когда получатель Y уже зарегистрирован как пользователь.

На фиг.7 схематично изображены операции, выполняемые между приемным устройством 120 и серверами 130 и 140 управления и электронной почты, для способа передачи электронного файла, относящегося к первому варианту осуществления настоящего изобретения.

Так как получатель Y уже зарегистрирован как пользователь, как изображено (на) этапе C1, приемное устройство 120 имеет секретный ключ 603, и сервер 130 управления имеет открытый ключ 604, соответствующий секретному ключу 603 в базе данных 330a.

На этапе C2 специализированное приложение (программа просмотра) активизируется в приемном устройстве 120. Получатель Y пытается открыть зашифрованный электронный файл 511, принятый в почте 512, с использованием программы просмотра.

На этапе C3 программа просмотра передает в сервер 130 управления адрес электронной почты, идентифицирующий получателя Y (т.е. адрес электронной почты получателя Y), и идентификатор файла, извлеченный из зашифрованного электронного файла 511.

На этапе C4 сервер 130 управления использует идентификатор файла, принятый из приемного устройства 120, как ключ для получения адресов предполагаемого получателя (на этапе A7) совместно с принятым идентификатором файла и перебирает полученные адреса предполагаемого получателя для определения того, включен ли в них адрес электронной почты получателя Y, который принят из приемного устройства 120. Другими словами, сервер 130 управления принимает решение о том, назначен ли получатель Y отправителем X как надлежащий получатель, которому разрешен доступ к электронному файлу, который однозначно определяется идентификатором файла, принятым из приемного устройства 120.

При принятии решения о том, что получатель Y является надлежащим получателем, сервер 130 управления извлекает из базы данных 330a ключевое слово 701 для расшифровки, сохраненное (на этапе A7) совместно с принятым идентификатором файла на этапе C5. Кроме того, сервер 130 управления извлекает из базы данных 330a открытый ключ 604 приемного устройства 120, сохраненный (на этапе B8) совместно с получателем Y. Дополнительно сервер 130 управления шифрует ключевое слово 701 для расшифровки с использованием открытого ключа 604 и передает зашифрованное ключевое слово 702 в приемное устройство 120.

На этапе C6 приемное устройство 120 принимает зашифрованное ключевое слово 702. Программа просмотра, активизированная в приемном устройстве 120, использует секретный ключ 603, сохраненный в приемном устройстве 120, для расшифровки зашифрованного ключевого слова 702, посредством чего получает ключевое слово 701 для расшифровки.

На этапе C7 программа просмотра использует ключевое слово 701 для расшифровки, чтобы расшифровать зашифрованный электронный файл 511, присоединенный к электронной почте 512, посредством чего получает электронный файл 501.

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

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

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

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

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

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

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

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

В случае криптосистемы с секретным ключом между передающим устройством 110 и сервером 130 управления, на этапе A6, передающее устройство 110 использует первый секретный ключ для шифровки электронного файла 501, использует второй секретный ключ для шифровки первого секретного ключа и передает в сервер 130 управления первый секретный ключ, зашифрованный с использованием второго секретного ключа. Сервер 130 управления расшифровывает зашифрованный первый секретный ключ с использованием второго секретного ключа для получения первого секретного ключа. Этот первый секретный ключ сохраняется на сервере 130 управления как ключевое слово для расшифровки на этапе A7. Следовательно, передающее устройство 110 и сервер 130 управления должны иметь второй секретный ключ заранее.

С другой стороны, между приемным устройством 120 и сервером 130 управления, на этапе B7, открытый ключ заменяется секретным ключом (здесь называется "третьим секретным ключом" для ясности), и используется другой секретный ключ (здесь называется "четвертым секретным ключом"). А именно, приемное устройство 120 передает в сервер 130 управления третий секретный ключ, зашифрованный с использованием четвертого секретного ключа, и маркер, зашифрованный с использованием третьего или четвертого секретного ключа. На этапе B8 сервер 130 управления расшифровывает зашифрованный третий секретный ключ с использованием четвертого секретного ключа для получения третьего секретного ключа и расшифровывает зашифрованный маркер с использованием третьего или четвертого секретного ключа для получения маркера. На этапе C5 сервер 130 управления шифрует ключевое слово для расшифровки с использованием третьего ключа и передает зашифрованное ключевое слово в приемное устройство 120. На этапе C6 приемное устройство 120 расшифровывает зашифрованное ключевое слово для расшифровки с использованием третьего секретного ключа для получения ключевого слова для расшифровки. Следовательно, приемное устройство 120 и сервер 130 управления должны иметь четвертый секретный ключ заранее.

(Второй вариант осуществления)

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

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

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

На этапе D1 отправитель X назначает, в специализированном приложении, файл 501 Word(r) как файл, который должен быть передан, аналогично этапу A3. На этапе D2 отправитель X назначает адрес электронной почты получателя, которому разрешается открывать файл (здесь, получатель Y). Кроме того, отправитель X назначает действия, которые получателю Y разрешается или запрещается выполнять над электронным файлом 501, аналогично этапу A4.

На этапе D3 специализированное приложение использует введенное или сформированное ключевое слово для расшифровки, чтобы зашифровать электронный файл 501, назначенный в качестве файла, который должен быть передан, аналогично этапу A6. После этого специализированное приложение передает в сервер 130 управления адрес электронной почты получателя Y, информацию о запрете и разрешении просмотра, идентификатор файла и зашифрованное ключевое слово для расшифровки, аналогично этапу A6. Сервер 130 управления обрабатывает эти порции информации идентичным способом, как описано выше применительно к этапам A6 и A7.

На этапе D3 специализированное приложение может назначать зашифрованному электронному файлу 801 имя файла, идентичное имени исходного электронного файла 501. Другими словами, имя зашифрованного электронного файла 801 может быть одинаковым с именем электронного файла 501 (Important.doc).

В зашифрованном электронном файле 801, в части 802 заголовка существует идентификатор 802b файла. В части 802 заголовка также существует заголовок 802a, указывающий на то, что электронный файл 801 имеет уникальный формат. В части заголовка 802 могут также существовать метаданные 802c. Например, метаданные 802c могут включать в себя информацию, представляющую авторские права и предысторию редакции электронного файла 501. Метаданные 802c могут быть зашифрованы так же, как и содержимое 803 исходного файла.

На этапе D4 специализированное приложение передает электронную почту 804 с присоединенным к ней зашифрованным электронным файлом 801, аналогично этапу A8. Эта электронная почта 804 принимается приемным устройством 120 через сервер 140 электронной почты.

На этапе D5 приемное устройство 120 активизирует специализированное приложение (программу просмотра), аналогично этапу C2. Получатель Y использует программу просмотра для открытия зашифрованного электронного файла 801, который принят в электронной почте 804.

На этапе D6 зашифрованный электронный файл 801 имеет имя файла, идентичное имени электронного файла 501, но имеет уникальный формат и не может быть просто открыт. Однако во втором варианте осуществления настоящего изобретения пользователь не знает об этом факте, и операционная система (OS) 805 исполняет действие открытия электронного файла 801, как описано ниже.

На этапе D7 программа просмотра 806 конфигурируется для осуществления текущего контроля операции активизации приложения (выполняемой) OS 805. При обнаружении, что конкретное приложение (здесь, Word(r)) 807 активизируется OS 805, о чем делается предположение на основе открытия зашифрованного электронного файла 801, программа просмотра 806 использует перехват (hook) API для замены операций модуля API 808, вызываемых конкретным приложением 807, операциями уникального модуля 809 перехвата. Следовательно, когда OS 805 активизирует Word(r) согласно расширению (.doc) электронного файла 801, программа просмотра 806 обнаруживает, что OS 805 активизирует конкретное приложение 807, то есть Word(r), и использует перехват API для вызова уникального модуля 809 перехвата.

На этапе D8 активизированное конкретное приложение 807 запускает (вызывает) модуль API, подготовленный OS 805 для получения доступа к содержимому файла. На этапе D9, однако, операции вызываемого модуля API фактически не выполняются. Вместо этого фактически выполняются операции уникального модуля 809 перехвата, который вызывается посредством перехвата API. Уникальный модуль 809 перехвата определяет, существует ли в части 802 заголовка зашифрованного электронного файла 801 заголовок 802a (добавляемый на этапе D3), в отношении доступа к зашифрованному электронному файлу 801.

Когда в части заголовка 802 не существует заголовка 802a, уникальный модуль 809 перехвата принимает решение о том, что электронный файл 801 не имеет уникальный формат (т.е. принимает решение о том, что электронный файл 801 является обычным файлом Word(r)), и исполняются операции, которые обычно выполняются OS 805 для файла Word(r) (другими словами, выполняются операции модуля API, вызываемого на этапе D9).

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

На этапе D10 программа просмотра 806 (уникальный модуль 809 перехвата) передает, в сервер 130 управления, адрес электронной почты получателя Y и идентификатор файла, аналогично этапу C3. В ответ на это сервером 130 управления выполняются операции, описанные в отношении этапов C4 и C5. В результате приемное устройство 120 принимает из сервера 130 управления зашифрованное ключевое слово 702. Следовательно, программа просмотра 806 (уникальный модуль 809 перехвата) получает ключевое слово 701 для расшифровки, аналогично этапу C6, и использует ключевое слово 701 для расшифровки, чтобы расшифровать зашифрованный электронный файл 801, посредством чего получает электронный файл 501, аналогично этапу C7.

Когда получатель Y не зарегистрирован как пользователь сервером управления 130, выполняются этапы B1-B8, описанные со ссылкой на фиг.6.

Ниже более подробно описываются операции, выполняемые на этапах D8-D10, с уделением особенно большого внимания перехвату API.

"Общее представление о перехвате API"

Ниже сначала описывается общее представление о перехвате API.

(1) API означает Интерфейс прикладного программирования и относится к совокупности функций OS, которые могут использоваться для сохранения приложения внутри OS. Данное приложение объединяет вместе некоторые или все модули API, подготовленные OS для того, чтобы OS исполняла конкретную функцию, требуемую данным приложением.

Возьмем в качестве примера приложение, которое считывает файл (например, Word(r)) на Windows(r). Это приложение обычно выполняет операции, описанные на фиг.9, на которой схематично изображена операция чтения файла, выполняемая приложением общего назначения.

На этапе 910 приложение 901 назначает имя файла, вызывает API CreateFile и открывает файл. На этапе 920 приложение 901 назначает идентификатор открытого файла (HANDLE (логический номер файла)), вызывает API ReadFile и получает содержимое открытого файла. На этапе 930 приложение 901 использует API CloseHandle для вывода готового файла.

Как очевидно из вышеупомянутого изложения, устройствами и ресурсами управляет OS 902, и приложение 901 всегда вызывает некоторые API для использования функций OS. Другими словами, приложение 901 получает доступ к устройствам и ресурсам при запросе на выполнение операций посредством выпущенных API.

(2) Список API, используемых прикладной программой, описан в исполняемом файле прикладной программы. Во время активизации прикладной программы OS размещает в память объекты API, требуемые активизируемой прикладной программой, и связывает адреса API в памяти с вызовами API, описанными в прикладной программе. Следовательно, память перезаписывается, как изображено на фиг.10, так, что в ответ на описание "Вызов API CreateFile" в прикладной программе фактически выполняется операция "Вызов функции по адресу 0x6fff00a0". Здесь, объект CreateFile был уже размещен в памяти заранее.

(3) Как изображено на фиг.11, уникальный фрагмент программы (модуль) может быть вставлен в область памяти исполняемого файла программы, и информация о связи между именами API и адресами может быть перезаписана. Следовательно, может выполняться операция, отличная от объекта API CreateFile, который первоначально предполагался для вызова. Это называется "перехватом API". С использованием этого способа, когда приложение пытается вызвать функцию OS, например, API CreateFile, в качестве альтернативы может выполняться уникальная операция на основе модуля перехвата, вставленного извне. Модуль перехвата знает местоположение в памяти "API CreateFile", который первоначально предполагался для вызова, и, соответственно, может запрашивать первоначально предполагаемый API CreateFile выполнить операции, если требуется.

Выше в целом описан перехват API.

"Подробное описание операций, выполняемых на этапах D8-D10"

Фиг.12 является схемой последовательности операций, на которой изображены операции, выполняемые на этапах D8-D10, с уделением внимания перехвату API. Согласно фиг.8 и 12, на этапе D8 конкретное приложение 807 назначает имя файла и пытается вызвать API CreateFile для получения доступа к содержимому файла. Фактически, однако, на этапе D9 выполняются операции уникального модуля 809 перехвата, вызываемого перехватом API. А именно, уникальный модуль 809 перехвата назначает имя файла, вызывает API CreateFile и открывает электронный файл 801 на этапе D9-1. На этапе D9-2 уникальный модуль 809 перехвата назначает идентификатор открытого файла 801, вызывает API ReadFile и получает содержимое открытого файла. Уникальный модуль 809 перехвата считывает часть 802 заголовка электронного файла 801. При обнаружении того, что электронный файл 801 имеет уникальный формат, на этапе D10 уникальный модуль 809 перехвата передает в сервер 130 управления адрес электронной почты получателя Y и идентификатор файла. Следовательно, уникальный модуль 809 перехвата получает из сервера 130 управления зашифрованное ключевое слово 702.

После этого уникальный модуль 809 перехвата расшифровывает зашифрованный электронный файл 801 для получения содержимого электронного файла 501 в памяти. Полученное содержимое электронного файла 501 сохраняется и хранится в памяти (область временной памяти), и управление передается в точку вызова конкретного приложения 807, в памяти, как изображено (на) этапе D10-1.

Выше описаны этапы D8-D10.

Далее, на этапе D11 уникальный модуль 809 перехвата также принимает из сервера 130 управления информацию о запрете и разрешении просмотра, сохраненную (на этапе A7) совместно с идентификатором файла. Информация о запрете и разрешении просмотра эквивалентна информации, введенной отправителем X на этапе D2 (т.е. этап A4).

Согласно принятой информации о запрете и разрешении просмотра, уникальный модуль 809 перехвата может разрешить и/или запретить получателю Y выполнять данные операции (например, редактирование, печать, действие с буфером обмена и т.п.) над электронным файлом 501 в точности так, как предполагалось отправителем X. На фиг.13 изображено в деталях то, как реализовать такое управление. Фиг.13 является схемой последовательности операций, на которой изображены операции для ограничения действия с буфером обмена, выполняемой получателем над электронным файлом в способе передачи электронного файла, относящемся ко второму варианту осуществления настоящего изобретения.

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

Если на этапе E1 получатель Y нажимает клавишу "Ctrl" и клавишу "C" для выполнения действия с буфером обмена на данном этапе, то приложение 807 вызывает API SetClipBoardData на этапе E2. Фактически, однако, на этапе E3 уникальный модуль 809 перехвата возвращает "отказ", и на этапе E4 приложение 807 выдает получателю Y сообщение об ошибке и т.п.

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

Аналогично, приложение 807 вызывает API GetDC, когда требуется распечатать электронный файл 501, и последовательность API: CreateFile, WriteFile и CloseHandle, когда требуется сохранить электронный файл 501 под другим именем. В ответ на эти вызовы API, перехват API вызывает уникальный модуль 809 перехвата для выполнения уникальных операций для запрета печати электронного файла 501 или сохранения его под другим именем.

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

Согласно фиг.8, уникальный модуль 809 перехвата осуществляет текущий контроль того, вызывает ли конкретное приложение 807 API, для обнаружения, например, того, что получатель Y выполняет конкретное действие (вызывается конкретный API), и передает результат обнаружения в сервер 130 управления. А именно, уникальный модуль 809 перехвата может передавать в сервер 130 управления идентификатор электронного файла и информацию о действии, указывающую на конкретное действие (а также время, в которое это действие выполнялась), как изображено (на) этапе D12. Сервер 130 управления сохраняет информацию о действии (журнал регистрации о действии) совместно с идентификатором электронного файла в базе данных 330a. Кроме того, отправитель X может получить доступ к серверу 130 управления через передающее устройство 110 для получения сведений о том, какие действия были выполнены получателем Y над электронным файлом, который отправитель X передал, как изображено на этапе D13. Следовательно, отправитель X может отслеживать действия, выполняемые получателем Y над электронным файлом, переданным отправителем X, и время, в которое выполнены действия.

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

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

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

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

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

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

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

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

Фиг.3 - блок-схема, изображающая иллюстративную внутреннюю структуру сервера 130 управления.

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

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

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

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

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

На фиг.9 схематично изображена операция считывания файла, выполняемая приложением общего назначения.

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

Фиг.11 - схематический вид, иллюстрирующий общее представление о перехвате API.

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

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

Список позиционных обозначений

100 Система связи

110 Передающее устройство

120 Приемное устройство

130 Сервер управления

140 Сервер электронной почты

150 Сеть связи

220, 310, 410 Управляющее/обрабатывающее звено

230, 330, 420 Звено для хранения информации

240, 320, 430 Звено связи

250, 440 Звено вывода на экран

330a База данных

806 Программа просмотра (специализированное приложение)

807 Конкретное приложение

809 Уникальный модуль перехвата (модуль перехвата)