(57)【要約】【課題】複数のサーバー証明書を作成する場合において利便性の高いＳＳＬ通信等の暗号化通信を可能としつつ、サーバー証明書の保存に要する記憶容量を低減すること。【解決手段】本発明は、暗号化通信に必要なサーバー証明書を作成するサーバーであって、ネットワーク環境に応じて変動する情報から構成される第１のサーバー証明書、前記ネットワーク環境に応じて変動しない情報から構成される第２のサーバー証明書、及びユーザが変更可能な前記サーバーの複数のホスト名の情報を集約した第３のサーバー証明書を作成する作成手段を有することを特徴とするサーバーである。【選択図】図７
2018191244.tif 000002
【特許請求の範囲】
【請求項１】
暗号化通信に必要なサーバー証明書を作成するサーバーであって、
ネットワーク環境に応じて変動する情報から構成される第１のサーバー証明書、前記ネットワーク環境に応じて変動しない情報から構成される第２のサーバー証明書、及びユーザが変更可能な前記サーバーの複数のホスト名の情報を集約した第３のサーバー証明書を作成する作成手段を有することを特徴とするサーバー。
【請求項２】
クライアントから送信された暗号化通信の要求に対して、前記第１のサーバー証明書と、前記第２のサーバー証明書と、前記第３のサーバー証明書との何れかを前記クライアントに送信するか判定する判定手段を更に有することを特徴とする請求項１に記載のサーバー。
【請求項３】
前記サーバーは、前記サーバーおよび通信相手装置の外部にある外部アクセスポイントを介して通信を行うインフラストラクチャモードと、前記外部のアクセスポイントを介さずに通信を行うＷｉ−Ｆｉ  Ｄｉｒｅｃｔモードと、前記インフラストラクチャモードと前記Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔモードとの両モードで動作する同時動作モードとの何れかのモードで動作することを特徴とする請求項２に記載のサーバー。
【請求項４】
前記暗号化通信の要求であるＣｌｉｅｎｔ  Ｈｅｌｌｏにおいて設定されているＳｅｒｖｅｒ  Ｎａｍｅ  Ｉｎｄｉｃａｔｉｏｎの指定先が、前記インフラストラクチャモードのＩＰアドレスの場合、前記サーバーは、前記第１のサーバー証明書を前記クライアントに送信し、
前記指定先が、前記Ｗｉ−Ｆｉ  ＤｉｒｅｃｔモードのＩＰアドレスの場合、前記サーバーは、前記第２のサーバー証明書を前記クライアントに送信し、
前記指定先が、Ｂｏｎｊｏｕｒプロトコルのホスト名、ＬＬＭＮＲプロトコルのホスト名、若しくはＤＤＮＳプロトコルのホスト名の場合、又は、前記Ｃｌｉｅｎｔ  Ｈｅｌｌｏにおいて前記Ｓｅｒｖｅｒ  Ｎａｍｅ  Ｉｎｄｉｃａｔｉｏｎが設定されていない場合、前記サーバーは、前記第３のサーバー証明書を前記クライアントに送信することを特徴とする請求項３に記載のサーバー。
【請求項５】
前記サーバーが前記インフラストラクチャモードで起動した場合、前記作成手段は、前記第２のサーバー証明書を作成することなく、前記第１のサーバー証明書及び前記第３のサーバー証明書を作成し、
前記サーバーが前記Ｗｉ−Ｆｉ  Ｄｉｒｅｃｔモードで起動した場合、前記作成手段は、前記第１のサーバー証明書を作成することなく、前記第２のサーバー証明書及び前記第３のサーバー証明書を作成することを特徴とする請求項３又は４に記載のサーバー。
【請求項６】
前記サーバーが前記同時動作モードで起動した場合、前記作成手段は、前記第３のサーバー証明書を作成した後で、前記第１のサーバー証明書及び前記第２のサーバー証明書を作成することを特徴とする請求項３乃至５の何れか１項に記載のサーバー。
【請求項７】
前記サーバーの複数のホスト名の何れかががユーザによって変更された場合、前記作成手段は、前記第３のサーバー証明書を作成することを特徴とする請求項１乃至６の何れか１項に記載のサーバー。
【請求項８】
前記サーバーの複数のホスト名は、Ｂｏｎｊｏｕｒプロトコルのホスト名、ＬＬＭＮＲプロトコルのホスト名、及びＤＤＮＳプロトコルのホスト名を含むことを特徴とする請求項１乃至７の何れか１項に記載のサーバー。
【請求項９】
印刷手段を更に備えることを特徴とする請求項１乃至８のいずれか１項に記載のサーバー。
【請求項１０】
暗号化通信に必要なサーバー証明書を作成するサーバーの制御方法であって、
ネットワーク環境に応じて変動する情報から構成される第１のサーバー証明書、前記ネットワーク環境に応じて変動しない情報から構成される第２のサーバー証明書、及びユーザが変更可能な前記サーバーの複数のホスト名の情報を集約した第３のサーバー証明書を作成するステップを有することを特徴とする制御方法。
【請求項１１】
コンピュータに、請求項１０に記載の方法を実行させるための、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、暗号化通信の技術に関する。
【背景技術】
【０００２】
近年、ネットワーク環境において証明書を使用したＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ）通信の利用が拡大している。マルチファンクションプリンタのような組み込み装置においても、状態の確認やセキュアプリントを実行する際にＳＳＬ通信を利用する機会が増えている。ＳＳＬ通信は一般的に、暗号化通信を要求するクライアントとその要求を受け付けるサーバーとから成り立ち、安全なＳＳＬ通信を確保するために、クライアントがサーバーから送られるサーバー証明書を検証する仕組みがある。
【０００３】
このような仕組みの１つとして、クライアントがサーバーに送信するＳＳＬ通信の開始要求であるＣｌｉｅｎｔ  Ｈｅｌｌｏにおいて、ＳＮＩ（Ｓｅｒｖｅｒ  Ｎａｍｅ  Ｉｎｄｉｃａｔｉｏｎ）を利用することが知られている。クライアントはＳＮＩを利用することでアクセスしたいホスト名をサーバーに伝え、サーバーはどのサーバー証明書を利用すべきか判定し、該ホスト名に対応するサーバー証明書をクライアントに送付する。
【０００４】
ところで、ネットワークサービスを提供する装置は、各種ＯＳや端末からの装置検出（ディスカバリ）を実現するために各種通信プロトコルをサポートしている。具体的にはＤＤＮＳ（Ｄｙｎａｍｉｃ  Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）、ｍＤＮＳ（マルチキャストＤＮＳ）、Ｂｏｎｊｏｕｒ、ＬＬＭＮＲ（Ｌｉｎｋ  Ｌｏｃａｌ  Ｍｕｌｔｉｃａｓｔ  Ｎａｍｅ  Ｒｅｓｏｌｕｔｉｏｎ）等である。これらのプロトコルのホスト名はプロトコル毎に異なる場合がある。また、ホスト名以外にもネットワーク上の装置を識別するためにＩＰアドレスが使われる。
【０００５】
つまり、ネットワーク上のクライアントが、各種プロトコルのホスト名又はＩＰアドレスを用いてサーバーにアクセスする可能性がある。クライアントがサーバーにアクセスする際にＳＮＩを利用した場合、何れかのホスト名、ＩＰアドレスが指定されることになるが、サーバーは、該指定されたホスト名、ＩＰアドレスに対応するサーバー証明書をクライアントに送信しなければならない。対応するサーバー証明書が送信されなかった場合、クライアントが安全な暗号化通信を実行できないと判断し、ＳＳＬ通信の機会を失う虞がある。
【０００６】
特許文献１には、複数のインターフェースを備える通信機器が複数のインターフェースの夫々に対応するサーバー証明書を作成し、使用するインターフェースに応じてサーバー証明書を使い分けることが開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１６−１６３１５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１では、複数のサーバー証明書を作成するが、作成するサーバー証明書の数が多くなった場合に、サーバー証明書の保存に必要な記憶容量が増大してしまう。つまり、特許文献１では、複数のサーバー証明書を作成することにより生じる課題について考慮されていなかった。
【０００９】
本発明は、上記の課題に鑑み、複数のサーバー証明書を作成する場合において利便性の高いＳＳＬ通信等の暗号化通信を可能としつつ、サーバー証明書の保存に要する記憶容量を低減することを目的とする。
【課題を解決するための手段】
【００１０】
本発明は、暗号化通信に必要なサーバー証明書を作成するサーバーであって、ネットワーク環境に応じて変動する情報から構成される第１のサーバー証明書、前記ネットワーク環境に応じて変動しない情報から構成される第２のサーバー証明書、及びユーザが変更可能な前記サーバーの複数のホスト名の情報を集約した第３のサーバー証明書を作成する作成手段を有することを特徴とするサーバーである。
【発明の効果】
【００１１】
本発明により、複数のサーバー証明書を作成する場合において利便性の高いＳＳＬ通信等の暗号化通信を可能としつつ、サーバー証明書の保存に要する記憶容量を低減することが可能となる。
【図面の簡単な説明】
【００１２】
【図１】無線通信システムの構成を示すブロック図
【図２】携帯型通信端末装置の外観を示す図
【図３】スマートフォンの構成を示すブロック図
【図４】ＭＦＰの外観を示す図
【図５】ＭＦＰの構成を示すブロック図
【図６】ユーザインターフェースを模式的に示す図
【図７】実施例１におけるＳＳＬ通信可能化処理のフローチャート
【図８】実施例１における証明書作成処理のフローチャート
【図９】ＭＦＰの不揮発性メモリに保存されるデータを示す図
【図１０】実施例１におけるＳＳＬ通信要求受信時にＭＦＰが実行する処理のフローチャート
【図１１】実施例２における証明書作成処理のフローチャート
【発明を実施するための形態】
【００１３】
以下、図面を参照しながら本発明の実施形態を例示的に詳しく説明する。但し、以下に記載する構成要素の相対配置、表示画面等は、特定的な記載がない限りは、発明の範囲をそれらのみに限定する趣旨のものではない。
【００１４】
＜システムの構成について＞
以下、本実施形態における無線通信システムの構成について、図１を用いて説明する。図１に示すように、本実施形態における無線通信システム１００は、携帯型通信端末装置１１０と、マルチファンクションプリンタ（以下ＭＦＰ）１２０と、外部アクセスポイント１３０とを備える。
【００１５】
携帯型通信端末装置１１０は、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ  ＬＡＮ：以下ＷＬＡＮ）通信を行うためのＷＬＡＮ通信部を有する装置である。携帯型通信端末装置１１０として、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）等の個人情報端末、携帯電話、デジタルカメラ等を用いて良い。ＭＦＰ１２０は、携帯型通信端末装置１１０と無線通信可能であれば良く、印刷機能の他に、読取（スキャン）機能、ＦＡＸ機能、電話機能等を有していても良い。尚、以下では、ＭＦＰ１２０として、読取機能と印刷機能とを有するＭＦＰを用いる場合を示す。外部アクセスポイント１３０は、ＷＬＡＮ通信を行うためのＷＬＡＮ通信部を有し、アクセスポイントへの接続を許可した装置同士の通信を中継することでインフラストラクチャモードの通信を提供する。インフラストラクチャモードは、ＭＦＰ１２０（本実施形態ではサーバーに相当）の外部であり、かつ、通信相手装置である携帯型通信端末装置１１０の外部である外部アクセスポイントを介して相手側の装置と無線接続する方式の１つである。
【００１６】
携帯型通信端末装置１１０とＭＦＰ１２０との間では、各々が有するＷＬＡＮ通信部によって、外部アクセスポイント１３０を介したインフラストラクチャモードの無線通信を行っても良い。或いは、各々が有するＷＬＡＮ通信部によって、外部アクセスポイント１３０を介さないＷｉ−Ｆｉ  Ｄｉｒｅｃｔモード（以下ＷＦＤ）等のＰ２Ｐ通信を行っても良い。ＷＦＤに対応した機器は、自身がアクセスポイント（ＧｒｏｕｐＯｗｎｅｒ）として動作することができ、それにより、相手側装置と直接に無線接続を行うことが可能となる。その際に、相手側装置と自装置とのどちらがアクセスポイントとして動作するかは、ＧｒｏｕｐＯｗｎｅｒＮｅｇｏｔｉａｔｉｏｎというシーケンスにより決定される。これにより従来のアクセスポイント専用機が不要となり、装置同士の直接接続を実現する。尚、携帯型通信端末装置１１０及びＭＦＰ１２０は、ＷＬＡＮ経由で種々の印刷サービスに対応した処理を実行可能である。つまり、ＷＦＤモードで携帯型通信端末装置１１０とＭＦＰ１２０が無線通信する場合、上述した外部アクセスポイント１３０を介さずに無線通信が実行される。
【００１７】
尚、ここでは、携帯型通信端末装置とＭＦＰとを備えるシステムを例に挙げて説明するが、用いる装置は携帯型通信端末装置やＭＦＰに限定されず、本発明は、サーバーと、クライアントと、アクセスポイントとを備える任意のシステムに適用可能である。
【００１８】
＜携帯型通信端末装置について＞
以下、本実施形態における携帯型通信端末装置１１０の外観について、図２を用いて説明する。尚、以下では、携帯型通信端末装置１１０としてスマートフォンを用いる場合を示す。スマートフォンとは、携帯電話の機能の他に、カメラ機能、ウェブブラウザ機能、電子メール機能等を有する多機能型の携帯電話である。
【００１９】
ＷＬＡＮユニット２０１は、スマートフォン２００内部に埋め込まれたＷＬＡＮで通信を行うためのユニットであって、ＷＦＤモード、ソフトウェアＡＰモード（親機モード）、インフラストラクチャモード等での無線通信を行うためのユニットである。ＷＬＡＮユニット２０１は、例えばＩＥＥＥ８０２．１１シリーズに準拠したＷＬＡＮシステムにおけるパケット通信が可能であるものとする。表示部２０２は、例えば、ＬＣＤ方式の表示機構を備えたディスプレイである。操作部２０３は、タッチパネル方式の操作機構を備えており、ユーザによる操作を検知する。代表的な操作方法として、表示部２０２にボタンアイコンやソフトウェアキーボード等を表示し、ユーザがそれらの箇所に触れることによって操作イベントを検知する方法が知られている。尚、ここでは、表示部と操作部とが一体的に構成されている場合を示すが、表示部と操作部とは別個に構成されていても良い。電源ボタン２０４は、電源をオンにする又は電源をオフにする際に押下するボタンである。
【００２０】
＜スマートフォンの構成について＞
以下、本実施形態におけるスマートフォン２００の構成について、図３を用いて説明する。スマートフォン２００は、スマートフォン２００自身のメインの制御を行うメインボード３０１と、ＷＬＡＮ通信を行うＷＬＡＮユニット２０１とを有する。
【００２１】
ＣＰＵ３０２は、スマートフォン２００全体の動作を統括的に制御する。具体的には、ＣＰＵ３０２が、ＲＯＭ３０３に保存されたプログラムをＲＡＭ３０４に展開し、該展開したプログラムを実行することで、様々な処理を実行する。
【００２２】
ＲＯＭ３０３には、ＣＰＵ３０２が実行する制御プログラムや組込オペレーティングシステム（ＯＳ）プログラム等のデータが保存される。本実施形態では、ＲＯＭ３０３に保存されている組込ＯＳの管理下で、ＲＯＭ３０３に保存されている各制御プログラムに従って、スケジューリングやタスクスイッチ等のソフトウェア制御が行われる。ＲＡＭ３０４は、ＳＲＡＭ（Ｓｔａｔｉｃ  ＲＡＭ）等で構成され、プログラム制御変数、ユーザによって入力された設定値、スマートフォン２００の管理データ等のデータが保存される。また、ＲＡＭ３０４には、各種ワーク用バッファ領域が設けられている。
【００２３】
画像メモリ３０５は、ＤＲＡＭ（Ｄｙｎａｍｉｃ  ＲＡＭ）等のメモリで構成され、ＣＰＵ３０２で処理するための画像データが一時的に保存される。この画像データには、ＷＬＡＮユニット２０１を介して受信した画像データや、データ蓄積部３１３から読み出した画像データ等が含まれる。不揮発性メモリ３１２は、フラッシュメモリ（ｆｌａｓｈ  ｍｅｍｏｒｙ）等のメモリで構成され、不揮発性メモリ３１２に保存されたデータは、スマートフォン２００の電源がオフになったときも消去されることなく保存され続ける。
【００２４】
尚、メモリ構成は、上述したものに限定されるわけではない。例えば、図３では、ＲＡＭ３０４と画像メモリ３０５とは別個の構成要素としているが、ＲＡＭ及び画像メモリを、一つのメモリを共用することで実現しても良い。また、データ蓄積部３１３を用いてデータのバックアップ等を行っても良い。さらに、上述の例では、画像メモリ３０５を、ＤＲＡＭを用いて実現しているが、ハードディスクや不揮発性メモリ等の他の記憶媒体を用いて実現しても良い。
【００２５】
データ変換部３０６は、種々の形式のデータの解析や、色変換、画像変換等のデータ変換を行う。電話部３０７は、電話回線の制御を行い、スピーカ部３１４を介して入出力される音声データを処理することで電話による通信を実現する。操作制御部３０８は、操作部２０３を介して入力された信号に基づく制御を行う。ＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）３０９は、スマートフォン２００の現在の緯度や経度等の位置情報を取得する。表示制御部３１０は、表示部２０２に表示する内容を電子的に制御し、例えば、各種入力を行うためのキーや、ＭＦＰ１２０の動作状況、ステータス状況等の情報を示すメッセージ等を、表示部２０２に表示させる。
【００２６】
カメラ部３１１は、レンズを介して入力された画像を電子的に記録して符号化する機能を有する。カメラ部３１１を用いて撮影することで取得された画像データは、データ蓄積部３１３に保存される。スピーカ部３１４は、電話機能のための音声を入力または出力する機能や、アラーム通知等のその他の音声機能を実現する。電源部３１５は、携帯可能な電池等から構成され、スマートフォン２００内の各構成要素への電力供給を制御する。本実施形態では、スマートフォン２００は次の４つの電源状態のうちの何れかの状態となるものとする。４つの電源の状態とは即ち、電池の残量が無い状態（電池切れ状態）、電源が入っていない状態（電源オフ状態）、電源オフ状態から電源ボタン２０４押下による通常起動で遷移する起動状態（電源オン状態）、起動しているが省電力な状態（省電力状態）である。
【００２７】
ＷＬＡＮユニット２０１は、規格に準拠したＷＬＡＮ通信を実現するためのユニットであり、バスケーブル３１６を介してメインボード３０１に接続されている。スマートフォン２００は、ＷＬＡＮユニット２０１を用いてＷＬＡＮ通信を行うことが可能であり、これにより、スマートフォン２００は、ＭＦＰ１２０等の他デバイスとの間でデータ通信を行う。ＷＬＡＮユニット２０１は、データをパケットに変換し、該変換したパケットを外部の他デバイスに送信するとともに、外部の他デバイスから送信されたパケットを受信し、該受信したパケットを元のデータに復元してＣＰＵ３０２に送信する。
【００２８】
メインボード３０１内の各構成要素及びＷＬＡＮユニット２０１は、ＣＰＵ３０２によって管理されるシステムバス３１８を介して接続されており、相互にデータを送受信することが可能である。
【００２９】
＜ＭＦＰの外観について＞
以下、本実施形態におけるＭＦＰ１２０の外観について、図４を用いて説明する。原稿台４０１は、読取部（スキャナ）５０９（図５参照）で読み取らせる原稿を載せるガラス状の透明な台である。原稿蓋４０２は、読取部５０９で読取を行う際に原稿を押さえたり、読取の際に原稿を照射する光源からの光が外部に漏れないようにしたりするための蓋である。挿入口４０３は、様々なサイズの印刷用紙等の記録媒体をセット可能な挿入口である。挿入口４０３にセットされた記録媒体は、一枚ずつ印刷部５１２（図５参照）に搬送され、印刷部５１２で印刷が行われた後、排出口４０４から排出される。
【００３０】
操作表示部４０５は、文字入力キー、カーソルキー、決定キー、取り消しキー等の操作部と、ＬＥＤ（発光ダイオード）やＬＣＤ（液晶ディスプレイ）等の表示部とから構成される。或いは、操作表示部４０５は、タッチパネルで構成されても良い。操作表示部４０５は、ユーザからの操作を受け付けるとともに、ＭＦＰ１２０の動作状況を示すメッセージ等を表示することでユーザに情報を提示する。ユーザは操作表示部４０５を介してＭＦＰ１２０の各種機能を利用することや各種設定を行うことができる。
【００３１】
＜ＭＦＰの構成について＞
以下、本実施形態におけるＭＦＰ１２０の構成について、図５を用いて説明する。ＭＦＰ１２０は、ＭＦＰ１２０自身のメインの制御を行うメインボード５０１と、ＷＬＡＮ通信を行うＷＬＡＮユニット５１６と、モデム５１９とを有する。
【００３２】
ＣＰＵ５０２は、ＭＦＰ１２０全体の動作を統括的に制御する。具体的には、ＣＰＵ５０２が、ＲＯＭ５０３に保存されたプログラムをＲＡＭ５０４に展開し、該展開したプログラムを実行することで、様々な処理、例えば後述の図７、図８、図１０、図１１の処理を実行する。
【００３３】
ＲＯＭ５０３には、ＣＰＵ５０２が実行する制御プログラムや組込オペレーティングシステム（ＯＳ）プログラム等のデータが保存される。本実施形態では、ＲＯＭ５０３に保存されている組込ＯＳの管理下で、ＲＯＭ５０３に保存されている各制御プログラムに従って、スケジューリングやタスクスイッチ等のソフトウェア制御が行われる。ＲＡＭ５０４は、ＳＲＡＭ（Ｓｔａｔｉｃ  ＲＡＭ）等で構成され、プログラム制御変数、ユーザによって入力された設定値、ＭＦＰ１２０の管理データ等のデータが保存される。また、ＲＡＭ５０４には、各種ワーク用バッファ領域が設けられている。不揮発性メモリ５０５は、フラッシュメモリ（ｆｌａｓｈ  ｍｅｍｏｒｙ）等のメモリで構成され、不揮発性メモリ５０５に保存されたデータは、ＭＦＰ１２０の電源がオフになったときも消去されることなく保存され続ける。画像メモリ５０６は、ＤＲＡＭ（Ｄｙｎａｍｉｃ  ＲＡＭ）等のメモリで構成される。画像メモリ５０６は、画像データを一時的に保存するためのメモリであり、画像メモリ５０６に保存する画像データには、ＷＬＡＮユニット５１６を介して受信した画像データや、符号復号化処理部５１１で処理した画像データ等が含まれる。尚、スマートフォン２００のメモリ構成と同様、ＭＦＰ１２０のメモリ構成もここで説明したものに限定されるわけではない。
【００３４】
データ変換部５０８は、種々の形式のデータの解析や、画像データから印刷データへの変換等のデータ変換を行う。読取制御部５０７は、コンタクトイメージセンサ（ＣＩＳ）等から構成される読取部５０９を制御して、原稿上の画像を光学的に読み取ることで取得した光の強度を電気信号に変換し出力する。
【００３５】
操作表示部４０５は、ユーザからの操作を受け付けるとともに、ＭＦＰ１２０の動作状況を示すメッセージ等を表示する。符号復号化処理部５１１は、ＭＦＰ１２０で扱う画像データに対する、符号化処理、復号化処理、拡大処理、縮小処理等を行う。給紙部５１３は、印刷用紙等の記録媒体を保持しており、印刷制御部５１４は、給紙部５１３を制御して給紙部５１３に保持されている記録媒体を印刷部５１２に供給する。複数種類の用紙を一つのＭＦＰで保持するために、ＭＦＰが複数の給紙部を有し、印刷制御部５１４がどの給紙部から給紙を行うかを制御しても良い。
【００３６】
印刷制御部５１４は、画像データに対し、スムージング処理、濃度補正処理、色補正処理等の各種画像処理を施し、画像処理後の印刷データを印刷部５１２に出力する。印刷部５１２は、印刷制御部５１４から送信された印刷データに基づいて印刷を行う。例えば、ＭＦＰ１２０がインクジェットプリンタの場合、印刷部５１２は、インクタンクから供給されるインクをプリントヘッドから吐出することで印刷を行う。また、印刷制御部５１４は、印刷部５１２の情報を定期的に読み出してＲＡＭ５０４に保存する情報を更新する役割も果たす。例えば、ＭＦＰ１２０がインクジェットプリンタの場合、印刷制御部５１４は、インクタンクの残量やプリントヘッドの状態等のステータス情報を更新する。
【００３７】
また、ＭＦＰ１２０には、スマートフォン２００と同様に、ＷＬＡＮユニット５１６が搭載されている。ＷＬＡＮで通信するためのアンテナ等から成るＷＬＡＮユニット５１６は、スマートフォン２００のＷＬＡＮユニット２０１と同等の機能を有し、バスケーブル５１５を介してメインボード５０１に接続されている。尚、スマートフォン２００及びＭＦＰ１２０は、ＷＦＤをベースとした通信が可能であり、ソフトウェアアクセスポイント（ＳｏｆｔＡＰ）機能を有する。
【００３８】
メインボード５０１内の各構成要素は、ＣＰＵ５０２によって管理されるシステムバス５２０を介して接続されており、相互にデータを送受信することが可能である。
【００３９】
＜ＭＦＰのユーザインターフェースについて＞
図６（ａ）〜図６（ｃ）は、ＭＦＰ１２０の操作表示部４０５に表示されるユーザインターフェース（以下ＵＩ）の例を模式的に示す図である。図６（ａ）は、ＭＦＰ１２０の電源を投入し、かつ印刷や読取（スキャン）等の動作をしていないアイドル状態で表示されるホーム画面である。図６（ａ）のホーム画面を見たユーザは、何れかのアイコンを選択することで、コピー機能、読取（スキャン）機能、又はクラウド機能を利用することが可能である。図６（ｂ）は、図６（ａ）のホーム画面が表示されている状態からユーザがキー操作又はタッチパネル操作を行うことでシームレスに表示される画面である。図６（ｂ）の画面には、図６（ａ）のホーム画面で選択する機能とは別の機能、即ちプリント機能やフォト機能を利用する際に選択するアイコンや、ＬＡＮ設定を行う際に選択するアイコンが表示されている。図６（ｃ）は、図６（ｂ）の画面においてＬＡＮ設定のアイコンを選択した際に表示されるＵＩである。ユーザは、このＵＩを介してインフラストラクチャモードを有効にするか又は無効にするかの設定や、ＷＦＤモードを有効にするか又は無効にするかの設定等、ＬＡＮに関する各種設定を変更することが可能である。
【００４０】
［実施例１］
本実施例では、ＳＳＬ通信を可能にするためにＭＦＰ１２０がサーバー証明書を作成する処理、及び、ＳＳＬ通信開始時のＭＦＰ１２０における該作成したサーバー証明書の使用形態、について説明する。尚、本実施例におけるＭＦＰ１２０は、インフラストラクチャモードではＤＨＣＰサーバーからＩＰアドレスを取得し通信を行い、ＷＦＤモードではオーナーとして固定のＩＰアドレスで通信を行うものとする。また、ＭＦＰ１２０は、各種のディスカバリプロトコルで名前解決可能なＢｏｎｊｏｕｒプロトコル、ＬＬＭＮＲプロトコル、ＤＤＮＳプロトコルのホスト名を、インフラストラクチャモードとＷＦＤモードとで共通のものとして持つものとする。つまり、例えば、インフラストラクチャモードでデバイス検索された場合に使用されるホスト名と、ＷＦＤモードでデバイス検索された場合に使用されるホスト名は共通となる。
【００４１】
＜ＳＳＬ通信可能化処理について＞
以下、本実施例におけるＭＦＰ１２０で実行される、ＳＳＬ通信を可能にするための処理（ＳＳＬ通信可能化処理）について、図７を用いて説明する。図７は、本実施例におけるＳＳＬ通信可能化処理のフローチャートである。尚、以下に示すＳＳＬ通信可能化処理は、ＭＦＰ１２０の起動後、具体的には、ＩＰアドレスが確定し、かつＢｏｎｊｏｕｒ、ＬＬＭＮＲ、ＤＤＮＳ等の各種プロトコルのホスト名が確定した場合に開始される。
【００４２】
ステップＳ７０１において、作成済みのルート証明書が不揮発性メモリ５０５に保存されているか判定する。ステップＳ７０１の判定結果が真の場合、ステップＳ７０６に進む一方、該判定結果が偽の場合、ステップＳ７０２に進む。
【００４３】
まず、ルート証明書が未作成の場合（ステップＳ７０１でＮＯ）を説明する。この場合、ステップＳ７０２において、ルート証明書を作成する。次いで、ステップＳ７０３において、インフラストラクチャモードのＩＰアドレスをコモンネームとしたサーバー証明書（以降インフラ証明書と呼ぶ）を作成する。次いで、ステップＳ７０４において、ＷＦＤモードのＩＰアドレスをコモンネームとしたサーバー証明書（以降ＷＦＤ証明書と呼ぶ）を作成する。次いで、ステップＳ７０５において、Ｂｏｎｊｏｕｒ、ＬＬＭＮＲ、ＤＤＮＳ等のプロトコルのホスト名をＳｕｂｊｅｃｔ  Ａｌｔｅｒｎａｔｉｖｅ  Ｎａｍｅｓ（サブジェクトの別名、以下ＳＡＮｓ）としたサーバー証明書（以降ホスト名証明書と呼ぶ）を作成する。尚、ステップＳ７０２〜ステップＳ７０５の各ステップにおける証明書の作成処理の詳細については、図８を用いて後述する。なお、ホスト名証明書に含まれるプロトコルとして上記３つのプロトコルを挙げたが、ユーザが設定変更しない限り固定のホスト名が使用されるプロトコルであればホスト名証明書に含まれても良い。
【００４４】
続いて、ルート証明書が作成されている場合（ステップＳ７０１でＹＥＳ）を説明する。この場合、ステップＳ７０６において、インフラ証明書が既に作成されているか判定する。ステップＳ７０６の判定結果が真の場合、ステップＳ７０７に進む一方、該判定結果が偽の場合、ステップＳ７０８に進む。
【００４５】
ステップＳ７０７において、不揮発性メモリ５０５に保存されているインフラ証明書のコモンネームに記載のＩＰアドレスと、ＭＦＰ１２０のインフラストラクチャモードの現ＩＰアドレスとを比較する。そして、これらが一致するか判定する。ステップＳ７０７の判定結果が真（一致）の場合、ステップＳ７０９に進む一方、該判定結果が偽（不一致）の場合、ステップＳ７０８に進む。
【００４６】
ステップＳ７０８において、現ＩＰアドレスをコモンネームとしたインフラ証明書を作成し、該作成したインフラ証明書を不揮発性メモリ５０５に上書き保存して、ステップＳ７０９に進む。
【００４７】
インフラ証明書に関する処理の後、ステップＳ７０９において、ＷＦＤ証明書が既に作成されているか判定する。ステップＳ７０９の判定結果が偽の場合、ステップＳ７１０でＷＦＤ証明書を作成してからステップＳ７１１に進む一方、該判定結果が真の場合、ＷＦＤ証明書を作成することなくステップＳ７１１に進む。
【００４８】
ＷＦＤ証明書に関する処理の後、ステップＳ７１１において、ホスト名証明書が既に作成されているか判定する。ステップＳ７１１の判定結果が真の場合、ステップＳ７１２に進む一方、該判定結果が偽の場合、ステップＳ７１３に進む。
【００４９】
ステップＳ７１２において、不揮発性メモリ５０５に保存されているホスト名証明書のＳＡＮｓに記載のＢｏｎｊｏｕｒ、ＬＬＭＮＲ、ＤＤＮＳのホスト名と、ＭＦＰ１２０のＢｏｎｊｏｕｒ、ＬＬＭＮＲ、ＤＤＮＳの現ホスト名とを比較する。そして、これらが全て一致するか判定する。ステップＳ７１２の判定結果が真（全て一致）の場合、ホスト名証明書を作成することなく一連の処理が終了する一方、該判定結果が偽（少なくとも一つが不一致）の場合、ステップＳ７１３に進む。
【００５０】
ステップＳ７１３において、ＭＦＰ１２０のＢｏｎｊｏｕｒ、ＬＬＭＮＲ、ＤＤＮＳの現ホスト名をＳＡＮｓに記載したホスト名証明書を作成し、一連の処理は終了する。以上が、本実施例におけるＳＳＬ通信可能化処理の内容である。
【００５１】
＜証明書作成処理について＞
以下、本実施例における証明書作成処理（図７のステップＳ７０２〜７０５、Ｓ７０８、Ｓ７１０、Ｓ７１３）について、図８を用いて説明する。図８は、本実施例における証明書作成処理のフローチャートである。
【００５２】
まず、ステップＳ８０１において、公開鍵暗号方式で使用する公開鍵とプライベート鍵とのペア（鍵ペア）を生成する。尚、公開鍵暗号方式として、例えばＲＳＡ暗号方式や楕円曲線暗号（ＥＣＣ）方式等の任意の方式を採用して良い。
【００５３】
次いで、ステップＳ８０１で生成した公開鍵を証明書として使用できるようにするため、ステップＳ８０２において、必要なパラメータを設定する。ここで必要なパラメータとは、国名、都道府県名、市町村名、組織名、部署名、コモンネーム、有効期限、暗号方式、サブジェクトの別名等を含む。
【００５４】
次いで、ステップＳ８０３において、ＳＨＡ−２５６等のハッシュアルゴリズムを用いてハッシュ値を算出する。
【００５５】
次いで、ステップＳ８０４において、ステップＳ８０３で算出したハッシュ値を証明書のプライベート鍵で暗号化することで、署名する。ステップＳ８０４の署名で使用する証明書は、作成する証明書によって使い分ける。具体的には、ルート証明書を作成する場合は、ステップＳ８０１で生成した公開鍵に対してペアとなるプライベート鍵で署名する。こうすることで、発行者と主体者が同一実体であるような証明書、いわゆる自己署名証明書を作成することができる。この自己署名証明書をＭＦＰ１２０の初回起動時に作成し、ルート証明書としてプライベート鍵と併せて不揮発性メモリ５０５に保存しておく（図９参照）。また、ＳＳＬ通信で使用するサーバー証明書を作成する場合は、ステップＳ８０１で生成した公開鍵に対して、予め作成しておいたルート証明書を上位の認証局として、ルート証明書のプライベート鍵で署名する。
【００５６】
最後に、ステップＳ８０５において、公開鍵に署名情報を付加して証明書を作成する。尚、図９に示すように、本実施例における証明書作成処理で作成された証明書は、証明書のプライベート鍵とペアで、証明書作成時のＩＰアドレスやホスト名の情報とともに、不揮発性メモリ５０５に保存される。以上が、本実施例における証明書作成処理の内容である。
【００５７】
前述の通り本実施例では、ルート証明書が作成されていない場合（ステップＳ７０１でＮＯ）、インフラ証明書、ＷＦＤ証明書、ホスト名証明書が作成されていたとしてもそれらを使用せず、新規に作成したルート証明書のプライベート鍵で署名したものを使用する。そのため、これら３つのサーバー証明書は再作成されることとなる。一方、ルート証明書が作成されている場合（ステップＳ７０１でＹＥＳ）、署名で用いるプライベート鍵は同一であるから、サーバー証明書のコモンネーム等の情報が変わらない限り、これら３つのサーバー証明書を再作成する必要はない。
【００５８】
＜ＳＳＬ通信要求受信時の処理について＞
以下、本実施例におけるＳＳＬ通信要求受信時の処理について、図１０を用いて説明する。図１０は、スマートフォン２００から送信されたＳＳＬ通信要求をＭＦＰ１２０が受信した場合に、ＭＦＰ１２０が実行する処理のフローチャートである。この処理は、ＭＦＰ１２０がＳＳＬ通信要求であるＣｌｉｅｎｔ  Ｈｅｌｌｏを受信すると開始される。なお、本実施形態のＭＦＰ１２０は、証明書が作成中である場合、その作成中の証明書を使用することはできない。例えば、後述するようにＳＮＩの指定先がインフラストラクチャモードのＩＰアドレスである場合、ＭＦＰ１２０は、インフラ証明書を使用することになる。しかし、そのインフラ証明書がＳ７０３またはＳ７０８により作成中である場合、ＭＦＰ１２０はインフラ証明書を使用できないため、ＳＳＬ通信は実行されないことになる。
【００５９】
まず、ステップ１００１において、受信したＣｌｉｅｎｔ  Ｈｅｌｌｏ内でＳＮＩが設定されているか判定する。ステップＳ１００１の判定結果が真の場合、ステップＳ１００２に進む一方、該判定結果が偽の場合、ステップＳ１００５に進む。
【００６０】
Ｃｌｉｅｎｔ  Ｈｅｌｌｏ内でＳＮＩが設定されている場合（ステップＳ１００１でＹＥＳ）、ステップＳ１００２において、ＳＮＩの指定先が何であるか判定する。この判定の結果、ＳＮＩの指定先がインフラストラクチャモードのＩＰアドレスの場合、ステップＳ１００３に進む。または、ＳＮＩの指定先がＷＦＤモードのＩＰアドレスの場合、ステップＳ１００４に進む。または、ＳＮＩの指定先がＢｏｎｊｏｕｒと、ＬＬＭＮＲと、ＤＤＮＳとの何れかのホスト名の場合、ステップＳ１００５に進む。
【００６１】
ＳＮＩの指定先がインフラストラクチャモードのＩＰアドレスの場合、ステップＳ１００３において、インフラ証明書を使用、つまりスマートフォン２００に送信する。
【００６２】
ＳＮＩの指定先がＷＦＤモードのＩＰアドレスの場合、ステップＳ１００４において、ＷＦＤ証明書を使用、つまりスマートフォン２００に送信する。
【００６３】
ＳＮＩが設定されていない場合（ステップＳ１００１でＮＯ）、又は、ＳＮＩの指定先がＢｏｎｊｏｕｒ、ＬＬＭＮＲ、ＤＤＮＳの何れかのホスト名の場合、ステップＳ１００５において、ホスト名証明書を使用、つまりスマートフォン２００に送信する。以上が、本実施例における、ＳＳＬ通信要求受信時にＭＦＰ１２０が実行する処理の内容である。尚、ここまで、暗号化通信としてＳＳＬ通信を利用する場合を説明してきたが、本実施例はＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ）通信等の他の暗号化通信にも適用可能である。
【００６４】
＜本実施例の効果等について＞
これまで述べてきたように、本実施例では、ＭＦＰ１２０は３つのサーバー証明書（即ち、インフラ証明書、ＷＦＤ証明書、ホスト名証明書）を作成及び管理する。これにより、スマートフォン２００等の携帯型通信端末装置１１０から送信されたＳＳＬ通信要求を受信するＭＦＰ１２０等の装置がたとえ低スペックであったしても、ＳＳＬ通信の機会を可能な限り低減させないようにすることが可能である。その理由は、次の通りである。
【００６５】
インフラ証明書はネットワーク環境に応じて変動する情報で構成されていることから、ＷＦＤ証明書やホスト名証明書と比べると再作成の頻度が高い。そして、低スペック装置ではインフラ証明書の作成に時間が掛かるケースが想定されるが、本実施例では、インフラ証明書を作成している間、ＷＦＤ証明書を利用したＳＳＬ通信またはホスト名証明書を利用したＳＳＬ通信は可能である。一方、ユーザが操作表示部４０５等を介してホスト名に変更する場合に、ホスト名証明書は再作成されることになるが、本実施例では、ホスト名証明書を再作成している間も、インフラ証明書又はＷＦＤ証明書を利用したＳＳＬ通信は可能である。つまり、ＭＦＰ１２０が、インフラ証明書、ＷＦＤ証明書、ホスト名証明書を個別に管理しているため、作成中の証明書とは異なる他の証明書を使用するＳＳＬ通信を実行できる。その結果、ＳＳＬ通信の機会を可能な限り低減させないという効果を得ることができる。
【００６６】
また一方、ＷＦＤモードで動作する間、ＭＦＰ１２０はオーナーとして常に固定のＩＰアドレスで動作するので、ＷＦＤ証明書を変更不要の証明書として扱うことが可能である。また、本実施例では、３つのサーバー証明書を不揮発性メモリ５０５に保存しており（図９参照）、これにより、プリンタの電源をオフにした後で再びオンにしたときに、前に作成した証明書をそのまま利用することが可能である。さらに、ホスト名証明書は、ネットワーク環境に応じて変動する情報ではなく、ユーザが任意に変更可能な情報のみから構成されているので、ネットワーク環境が変化した場合にホスト証明書を再作成する必要はない。尚、本実施例では複数のホスト名をＳａｎｓに記載にしたが、複数のホスト名の何れかの情報をさらにコモンネームとして記載するようにしても良い。
【００６７】
また、本実施例におけるホスト証明書に限り複数のプロトコルに対応可能に１つにまとめられたホスト証明書が作成される。その結果、上述したＢｏｎｊｏｕｒプロトコルの証明書、ＬＬＭＮＲプロトコルの証明書、ＤＤＮＳプロトコルの証明書を別々に作成するケースと比較して、サーバーにおける記憶容量の消費量を軽減することができる。
【００６８】
また、本実施例では、３つのサーバー証明書を同じルート証明書で署名しており、これにより、ＳＳＬ通信における一定の安全性を確保している。本来、自己署名証明書は正規の認証局が署名した証明書ではないため、ＳＳＬクライアントである携帯型通信端末装置１１０に信頼された証明書ではないと判断されてしまうという問題がある。この問題への対処としては、自己署名証明書を信頼された証明書として携帯型通信端末装置１１０に登録（インポート）すれば良いが、サーバー証明書を再作成する度に自己署名証明書を登録するのは煩雑である。そこで本実施例では、上述したように、ルート証明書で３つのサーバー証明書を署名する。こうすることで、署名に用いたルート証明書を携帯型通信端末装置１１０に登録しさえすれば、ルート証明書が再作成されない限り、サーバー証明書が再作成されたときにも安全性を確保できる。
【００６９】
［実施例２］
実施例１では、証明書の作成状態（即ち証明書が作成されているか否か）及びＭＦＰ１２０の現設定情報（即ち現ＩＰアドレス、現ホスト名等）に基づき、サーバー証明書を作成する場合について説明した（図７参照）。しかし、ＭＦＰ１２０の無線接続方式（いわゆるネットワークの動作モード）に基づいて作成するサーバー証明書の優先順位を決定した方が、より早くＳＳＬ通信を開始できる。本実施例では、無線接続方式に応じた順番でＭＦＰ１２０が複数種類のサーバー証明書を順次作成する処理について説明する。具体的には、インフラストラクチャモードと、ＷＦＤモードと、同時動作モードとの何れかのモードで動作するＭＦＰ１２０が起動したときに実行するサーバー証明書の作成処理である。尚、同時動作モードとは、ＭＦＰ１２０がインフラストラクチャモードとＷＦＤモードとの両モードで動作するモードである。
【００７０】
＜サーバー証明書の作成処理について＞
以下、特定の動作モードで起動し、かつＩＰアドレス及びホスト名が確定しているＭＦＰ１２０が、ルート証明書が作成されていない場合に実行するサーバー証明書を作成する処理について、図１１を用いて説明する。
【００７１】
まず、ステップＳ１１０１において、ルート証明書を作成する。
【００７２】
次いで、ステップＳ１１０２において、ＭＦＰ１２０の現在の動作モードが何であるか判定する。この判定の結果、ＭＦＰ１２０の現在の動作モードがインフラストラクチャモードの場合、ステップＳ１１０３に進む。または、ＭＦＰ１２０の現在の動作モードがＷＦＤモードの場合、ステップＳ１１０５に進む。または、ＭＦＰ１２０の現在の動作モードが同時動作モードの場合、ステップＳ１１０７に進む。
【００７３】
ＭＦＰ１２０の現在の動作モードがインフラストラクチャモードの場合、ステップＳ１１０３においてインフラ証明書を作成し、次いで、ステップＳ１１０４においてホスト名証明書を作成し、一連の処理は終了する。このように、ＭＦＰ１２０がインフラストラクチャモードで動作している場合、ＷＦＤ証明書を要するＷＦＤモードでは動作しないので、ＷＦＤ証明書を作成しない。尚、ここでは、インフラ証明書を作成した後にホスト名証明書を作成しているが、これらの証明書を作成する順番は逆でも良い。
【００７４】
ＭＦＰ１２０の現在の動作モードがＷＦＤモードの場合、ステップＳ１１０５においてＷＦＤ証明書を作成し、次いで、ステップＳ１１０６においてホスト名証明書を作成し、一連の処理は終了する。このように、ＭＦＰ１２０がＷＦＤモードで動作している場合、インフラ証明書を要するインフラストラクチャモードでは動作しないので、インフラ証明書を作成しない。尚、ここでは、ＷＦＤ証明書を作成した後にホスト名証明書を作成しているが、これらの証明書を作成する順番は逆でも良い。
【００７５】
ＭＦＰ１２０の現在の動作モードが同時動作モードの場合、ステップＳ１１０７においてホスト名証明書を作成し、次いで、ステップＳ１１０８においてインフラ証明書を作成し、ステップＳ１１０９においてＷＦＤ証明書を作成し、一連の処理は終了する。このように、ＭＦＰ１２０が同時動作モードで動作している場合、インフラストラクチャモードとＷＦＤモードとの両モードで使用可能なホスト名証明書をまず作成し、続いて、インフラ証明書、ＷＦＤ証明書の順に作成する。尚、インフラ証明書、ＷＦＤ証明書を作成する順番は逆でもよい。
【００７６】
尚、本実施例ではルート証明書が未作成の場合を示したが、ルート証明書が作成済みの場合は、優先順位に従って必要に応じてサーバー証明書を作成する。具体的には、実施例１と同様の判定（図７のステップＳ７０７、ステップＳ７１２）を行い、該判定結果に基づきサーバー証明書を作成する。
【００７７】
＜本実施例の効果等＞
本実施例では、動作モードに応じて作成するサーバー証明書を限定し、また、サーバー証明書を作成する際の優先順位を決める。具体的には、特定の動作モード（インフラストラクチャモード、ＷＦＤモード）では、使用する可能性があるサーバー証明書のみを作成する一方、使用する可能性が無いサーバー証明書を作成しないことで、ＭＦＰ１２０の処理負荷を低減することを可能としている。また、同時動作モードでは、インフラストラクチャモードとＷＦＤモードとの両モードで使用可能なホスト名証明書をまず作成することで、ホスト名証明書を最後に作成する場合と比べて、当該両モードの何れかのＳＳＬ通信を早く提供することを可能としている。
【００７８】
尚、本実施例は、上述したものに限定されるわけではない。例えば、上述の例では、ＩＰアドレスの情報から構成されるＷＦＤ証明書と、ホスト名の情報を集約したホスト名証明書とを分けて作成しているが、ＷＦＤモードのＩＰアドレスをホスト名証明書のＳａｎｓに記載するようにしても良い。またこの場合に、ＷＦＤ証明書を作成しないようにしても良い。
【００７９】
［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００８０】
１２０  ＭＦＰ
５０２  ＣＰＵ
【図１】
2018191244.tif 000003
【図２】
2018191244.tif 000004
【図３】
2018191244.tif 000005
【図４】
2018191244.tif 000006
【図５】
2018191244.tif 000007
【図６】
2018191244.tif 000008
【図７】
2018191244.tif 000009
【図８】
2018191244.tif 000010
【図９】
2018191244.tif 000011
【図１０】
2018191244.tif 000012
【図１１】
2018191244.tif 000013