JP7129231B2 - 情報処理システム、およびその制御方法 - Google Patents

Description

本発明は、ローカルサーバーまたはコンテンツサーバーから取得したコンテンツデータを設定する情報処理システム、およびその制御方法に関する。

情報処理装置（例えばデジタル複合機）を顧客先にて設置するにあたって、顧客の要望に応じた適切な設定作業が必要である。設定作業には、例えばファームウェアのアップデートや各種設定値の変更、アプリケーションのインストールなどの多くの項目が実行される。この設定作業を手動で実行しようとすると時間がかかるうえに、人為的なミスが発生しやすい。また、大規模な商談などでは、同じ設定作業を複数の情報処理装置に対して実施することもあり、手動操作による設定作業は効率がよくない。

そこで、あらかじめ設定作業の内容を定義した設定データを作成し、その設定データに基づき自動的に設定作業を実行する情報処理システムがある。設定データは顧客の要望に基づいて営業担当者により作成される。そして作業者が工場等で設定データを用いて、必要なコンテンツデータ（ファームウェアやアプリケーションなど）を情報処理装置にダウンロードする。

その際、ダウンロードするコンテンツデータのファイルサイズが大きい場合、ネットワークに負荷がかかったり、ダウンロードに時間がかかることがある。特に、複数の情報処理装置の設定作業において同一のコンテンツデータを使用する場合、設定作業のたびにコンテンツデータを外部のサーバーからダウンロードするのは非効率的である。

特許文献１では、ネットワークの負荷を抑えるために、最初にコンテンツデータをダウンロードした情報処理装置がコンテンツデータを公開するＷｅｂサーバーとなり、他の情報画像装置の設定作業時にはそのＷｅｂサーバーがイントラネット経由でコンテンツデータを配信することで、設定作業時間の短縮を図る形態が開示されている。

特開２０１７－２１４０７号公報

しかしながら特許文献１では、設定作業が最初に完了した情報処理装置をネットワークに接続した状態にしておく必要があり、その情報処理装置を配置しておくためのスペースの確保も問題となる。そこで、オフィスや工場におけるイントラネット環境のローカルサーバーにファイルサイズの大きいファームウェア等のコンテンツデータを管理させ、設定作業の際にそのローカルサーバーからコンテンツデータを取得するシステムが考えられる。

一方、コンテンツデータにはユーザー情報等が含まれる場合があるため、設定データの取得要求を情報処理装置から取得した際には、その要求元に対して認証を要求する。それは、コンテンツデータの一部がローカルサーバーに管理させた場合も同様であって、ローカルサーバーがコンテンツデータの取得要求を受信した際にも、その要求元に対して認証を要求する必要がある。

しかし、認証を実行し設定データを取得したユーザーに対し、ローカルサーバーからコンテンツデータを取得するために再度認証を要求するのは非効率的である。

本願発明は、自動設定処理におけるユーザーの操作性を維持しつつ、ローカルサーバーからコンテンツデータをセキュアに取得させることを目的とする。

本発明は、情報処理装置と、前記情報処理装置の機能を実現するためのアプリケーション、および前記アプリケーションを動作させるためのファームウェアのうち少なくとも一つを含むコンテンツデータをインストールするための指示を含む設定データを管理する管理サーバーと、前記コンテンツデータの少なくとも一部を管理するローカルサーバーと、を含む情報処理システムであって、前記管理サーバーは、前記情報処理装置からの前記情報処理装置を識別する第１の識別子および前記情報処理装置が属する組織を識別する第２の識別子を含む要求に基づいて、前記設定データ特定する特定手段と、前記特定手段で特定された前記設定データを前記情報処理装置に提供するための提供手段と、を有し、前記提供手段は、さらに、前記特定手段で前記設定データが特定されたことに伴って、前記第１の識別子および前記第２の識別子に基づく前記ローカルサーバーにアクセスするための認証情報を含むローカルサーバー情報を、前記情報処理装置に提供し、前記情報処理装置は、前記管理サーバーから取得した前記設定データに含まれる指示に従って前記コンテンツデータを取得する際に、前記管理サーバーから取得した前記ローカルサーバー情報を用いて前記ローカルサーバーにアクセスし、前記ローカルサーバーが管理する前記コンテンツデータを取得することを特徴とする。

本発明によれば、自動設定処理におけるユーザーの操作性を維持しつつ、ローカルサーバーからコンテンツデータをセキュアに取得させることができる。

情報処理システムのシステム構成の一例を示す図である。 管理サーバーのハードウェア構成の一例を示す図である。 デバイスのハードウェア構成の一例を示す説明図である。 管理サーバー、デバイス、ローカルサーバーのソフトウェア構成の一例を示す図である。 設定データの一例を示す図である。 ローカルサーバー情報の一例を示す図である。 デバイスの自動設定処理の一例を示すフローチャートである。 管理サーバーの設定データ送信処理の一例を示すフローチャートである。 設定データを検索するための画面の一例を示す図である。 設定データの内容を表示している画面の一例を示す図である。 管理サーバーがデバイスに送信する設定データの一例を示す図である。 デバイスが管理サーバーに送信する設定データ取得リクエストの一例を示す図である。 設定履歴の一例を示す図である。 デバイスが管理サーバーに送信するローカルサーバー情報取得リクエストの一例を示す図である。 管理サーバーのローカルサーバー情報送信処理の一例を示すフローチャートである。 ローカルサーバー情報の取得失敗を表示している画面の一例を示す図である。 実施例２における設定履歴の一例を示す図である。 実施例２における、管理サーバーのローカルサーバー情報送信処理の一例を示すフローチャートである。 ローカルサーバー選択画面の一例を示す図である。 設定データ選択画面の一例を示す図である。 ローカルサーバーを使用した自動設定作業の処理の一例を示すシーケンス図である。 実施例３における、自動設定作業の処理の一例を示すシーケンス図である。 有効期限延長リクエストの一例である。 有効期限延長処理の一例を示すフローチャートである。

以下、本発明の実施形態について図面に基づいて説明する。

［第１の実施形態］
＜システム構成＞
図１は、情報処理システムのシステム構成の一例を示す図である。

通信回線１００は、ＰＣ１０２及びローカルサーバー１０８が接続されているＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）である。管理サーバー１０１は、デバイス１０４の自動設定処理を行うための設定データを管理するインターネット１０７上のサーバーである。ＰＣ１０２は管理サーバー１０１に接続されており、設定データの作成や編集を行う。設定データを作成、または編集するためには、設定データの作成者によるユーザー認証（ユーザーＩＤやパスワード等の入力）が行われる。また、ローカルサーバー１０８も通信回線１００に接続されている。

通信回線１０３は、通信回線１００と同様にＬＡＮであり、デバイス１０４及びローカルサーバー１０５が接続されている。デバイス１０４は、管理サーバー１０１から設定データを取得し、設定作業を自動で実行する情報処理装置である。情報処理装置の具体的な例としては、例えばデジタル複合機等である。設定作業を実行するためには、後述のデバイス認証が行われる。

ローカルサーバー１０５、１０８は、コンテンツサーバー１０６が保持しているコンテンツデータをイントラネットにキャッシュするためのサーバーである。デバイス１０４は、コンテンツサーバー１０６ではなくローカルサーバー１０５、１０８からコンテンツデータを取得することにより、コンテンツ取得時間を短縮したりネットワーク負荷を低減したりすることができる。ここでのコンテンツデータとは、デバイス１０４に対して設定されるアプリケーションやファームウェア等のソフトウェアのことである。

コンテンツサーバー１０６は、デバイス１０４のファームウェアやアプリケーションを管理し、インターネット１０７経由でダウンロード可能にするインターネット１０７上のサーバーである。通信回線１００、１０３、及び管理サーバー１０１、コンテンツサーバー１０６は、インターネット１０７を介して通信可能に接続されている。通信回線１００、１０３とインターネット１０７との間には、一般的にはプロキシサーバーやファイアーウォール（不図示）が設置される。

以降の実施例では、デバイス１０４と同じ内部ネットワークシステム内に、ローカルサーバーが２台（１０５、１０８）存在する場合を例に説明するが、ローカルサーバーは１台でもよく、台数については特に問わない。また、通信回線１００と通信回線１０３を分けずに、ＰＣ１０２とデバイス１０４、ローカルサーバー１０５、１０８とが同一のＬＡＮに接続されていてもよい。

＜ハードウェア構成＞
図２は、管理サーバー１０１、ＰＣ１０２、コンテンツサーバー１０６、ローカルサーバー１０５、１０８のハードウェア構成の一例を示す図である。各装置のＣＰＵが各装置のＨＤＤ等に記憶されたプログラムに基づき処理を実行することによって各装置の機能等が実現される。図２では管理サーバー１０１を例に説明するが、情報処理システムに含まれるその他の装置についても同様のハードウェア構成である。

管理サーバー１０１においてハードディスク（ＨＤＤ）２１２には、自動設定ソフトウェアのプログラムが格納される。

ＣＰＵ２０１は、管理サーバー１０１の全体の制御を司る。ＣＰＵ２０１が、ＨＤＤ２１２に記録されたプログラムをＲＡＭ２０３等に読み出して実行することにより、図４に示す管理サーバー１０１のソフトウェア構成、及び後述のフローチャートの処理が実現される。

ＲＯＭ２０２には、ＢＩＯＳのプログラムやブートプログラムが格納されている。

ＲＡＭ２０３は、ＣＰＵ２０１の主メモリー、ワークエリア等として機能する。

キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９やポインティングデバイス（ＰＤ）２１０等からの指示入力を制御する。

ディスプレイコントローラ（ＤＳＰＣ）２０６は、ディスプレイ（ＤＳＰ）２１１の表示を制御する。

ディスクコントローラ（ＤＫＣ）２０７は、ハードディスク（ＨＤＤ）２１２やＣＤＲＯＭ（ＣＤ）２１３等の記憶装置へのアクセスを制御する。ＨＤＤ２１２及びＣＤ－ＲＯＭ（ＣＤ）２１３等には、ブートプログラム、オペレーティングシステムのプログラム、データベース、自動設定プログラム及びデータ等が記憶されている。

インタフェースコントローラ（ＩＦＣ）２０８は、インターネット１０７を介してＰＣ１０２やデバイス１０４、コンテンツサーバー１０６とのデータ通信を行う。これらの各構成要素は、システムバス２０４上に配置される。

本実施形態に係る自動設定プログラムは、ＣＤ－ＲＯＭ等の記憶媒体に格納された形で供給されてもよい。その場合には図２に示すＣＤ２１３等によって記憶媒体からプログラムが読み取られ、ＨＤＤ２１２にインストールされる。

＜デバイスのハードウェア構成＞
図３は、デバイス１０４のハードウェア構成の一例を示す説明図である。デバイス１０４の具体的な例としては、印刷機能やスキャン機能、ネットワーク通信機能等を備える画像形成装置である。

ＣＰＵ４０１は、画像形成装置全体の制御を司る。

ＲＯＭ４０２は、ＣＰＵ４０１が実行する印刷処理プログラムやフォントデータを格納する。

ＲＡＭ４０３は、ＣＰＵ４０１のワークエリア、受信バッファ、画像描画に使用される。

ハードディスク（ＨＤＤ）４０４は、プログラムやデバイス１０４の設定値等を記録する。

操作パネル４０５は各種スイッチやボタン、並びに、タッチパネル、メッセージ表示用の液晶表示部で構成される操作パネルである。ＣＰＵ４０１は、操作パネル４０５を介したユーザーの操作に応じて、ＨＤＤ４０４等に記憶されているデバイス１０４の設定値を変更することができる。

ネットワークインタフェース（ネットワークＩ／Ｆ）４０６は、ネットワークに接続するためのネットワークインタフェースである。

プリントエンジン４０７は、記録紙に印刷を行うプリンタのエンジンである。

スキャナー４０８は、原稿を読み取るためのスキャナーである。

ファクシミリ通信部４０９は、ファクシミリの送受信を行うための通信部である。

ＣＰＵ４０１がＲＯＭ４０２又はＨＤＤ４０４に記憶されたプログラムに基づき処理を実行することにより、図４に示すデバイス１０４のソフトウェア構成及び後述のフローチャートの処理が実現される。

＜管理サーバーとデバイスのソフトウェア構成＞
図４は、管理サーバー１０１及びデバイス１０４、ローカルサーバー１０５、１０８のソフトウェア構成の一例を示す図である。ローカルサーバー１０５とローカルサーバー１０８のソフトウェア構成はほとんど同じであるため、図４ではローカルサーバー１０５を代表として説明する。

管理サーバー１０１は設定データ管理部３００、ローカルサーバー管理部３０１、設定履歴管理部３０２を有する。設定データ管理部３００は、デバイス１０４を設定するために必要な設定データを管理する。ローカルサーバー管理部３０１は、ローカルサーバー１０５や１０８の情報を管理する。設定履歴管理部３０２は、管理サーバー１０１が管理している設定データを使用してデバイス１０４の設定を実行した履歴（設定履歴）を管理する。

設定データやローカルサーバー情報は組織ごとに管理され、ある組織のユーザーが別の組織のデータを参照することはできない。一方で同じ組織に所属するユーザー同士であれば、その組織のデータを参照することができる。本実施形態における組織とは、自動設定サービスを利用するユーザーの論理的なグループの単位である。組織は、企業の拠点（事業所）ごとに作成してもよいし、データの参照性を重視して複数の拠点を同一の組織として扱ってもよい。本実施例では、ローカルサーバー１０５と１０８とが同じ組織のローカルサーバーとしてローカルサーバー管理部３０１に管理されているものとする。

デバイス１０４は設定データ取得部３０３、コンテンツ取得部３０４、設定実行部３０５、設定結果通知部３０６を有する。設定データ取得部３０３は、インターネット１０７経由で管理サーバー１０１から設定データ、及びそれに付随するコンテンツデータ取得先情報を取得する。コンテンツ取得部３０４は、設定データ取得部３０３が取得した情報に基づき、コンテンツデータの取得先を決定し、コンテンツデータを取得する。

設定実行部３０５は、設定データ取得部３０３が取得した設定データ、及びコンテンツ取得部３０４が取得したコンテンツデータを使用して、デバイス１０４の設定処理を実行する。設定結果通知部３０６は、設定実行部３０５が実行した設定処理の結果をインターネット１０７経由で管理サーバー１０１に通知する。

ローカルサーバー１０５（またはローカルサーバー１０８）はコンテンツ取得部３０７とコンテンツ配信部３０８を有する。コンテンツ取得部３０７は、管理サーバー１０１からコンテンツデータを取得する。ここでのコンテンツデータとは、本実施例ではファイルサイズの大きいファームウェア等を想定するが、コンテンツ取得部３０７で取得されるコンテンツデータはファイルサイズの大きいものには限定されない。コンテンツ配信部３０８は、デバイス１０４からの要求に応じてコンテンツデータを配信する。

デバイス１０４と管理サーバー１０１は、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）やＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）等の技術を用いて通信を行う。

＜設定データ＞
図５は、設定データ管理部３００（管理サーバー１０１）が管理している設定データの一例を示す図である。営業担当者等のユーザーがＰＣ１０２経由で管理サーバー１０１にアクセスすることで設定データの作成、編集、削除が行われる。なお、図５（ｄ）は図５（ａ）と、図５（ｅ）は図５（ｂ）と項目が同じであるため、代表して図５（ａ）と図５（ｂ）を説明する。

図５（ａ）は、設定データの属性値、及び付加的な情報である。図５（ａ）の例では、「組織ＩＤ」、「設定データＩＤ」、「設定データ名」、設定データの「作成日」と「最終更新日」、及び設定処理に必要なコンテンツデータの取得先となるローカルサーバーの「ローカルサーバーＩＤ」が保持されている。ローカルサーバーＩＤの詳細は図６で述べる。設定データのうち図５（ａ）に示す情報を設定メタ情報と呼ぶ。

図５（ｂ）は、設定データを適用するデバイス１０４を識別するための情報である。図５（ｂ）の例では、「設定データＩＤ」、設定データの設定対象であるデバイスの「機種」と「シリアル番号」が保持されている。設定データのうち図５（ｂ）に示す情報を設定対象情報と呼ぶ。

設定作業の対象となるデバイスのシリアル番号が「ＡＢＣ１１１１１」である場合、図５（ｂ）より設定データＩＤ「０００００００１」が特定される。図５（ａ）より設定データＩＤから、組織ＩＤ「ＡＡＡ」が特定され、設定データを検索する画面（図９）に入力される組織ＩＤと照合される。

デバイスによっては図５（ａ）～（ｃ）を参照した結果、複数の設定データが特定される場合もある。一つのデバイスに対して複数の設定データが関連付く形態としては具体的に、顧客の要望に従って段階的に設定データが作成された場合等である。図５（ｂ）、（ｅ）より、シリアル番号「ＡＢＣ１１１１１」によって２つの設定データＩＤが特定され、図５（ａ），（ｄ）によってそれぞれのデバイスが所属する組織ＩＤが特定される。

図５（ｃ）は、デバイス１０４で実行する設定処理の内容と順番を記述した情報である。図５（ｃ）の例では、「設定データＩＤ」、処理の順番である「処理Ｎｏ．」、処理の内容である「処理」、処理で使用するコンテンツデータの種類である「コンテンツ種別」、コンテンツデータの識別子である「コンテンツデータＩＤ」、及びコンテンツデータの名称である「コンテンツ名」が保持されている。設定データのうち図５（ｃ）に示す情報を設定処理情報と呼ぶ。

図５（ｃ）より、デバイスに最初に実行すべき処理内容は、「処理Ｎｏ．」が「００１」であるファームウェアのダウンロード、２番目に実行すべき処理内容は、「処理Ｎｏ．」が「００２」であるファームウェアの適用（アップデート）等である。

図５の各データは設定データＩＤで関連付いているため、設定データにおいて設定対象のデバイスの機種やシリアル番号の指定はなくてもよい。その結果、設定データは、複数の機種、又は同一機種の複数のデバイスに対して汎用的に利用可能なデータとなる。

図５では、設定データを設定メタ情報、設定対象情報、設定処理情報の３つのテーブルに分けた状態で示したが、互いに関連付いた状態であれば、各情報が管理されるテーブルの個数は問わない。

また、図５（ａ）（ｂ）（ｄ）（ｅ）は管理サーバー１０１で設定データを特定する際に参照されるため、データベースの形態（テーブル）を想定しているが、図５（ｃ）は、コンテンツデータを取得する際にデバイス１０４で参照される情報であるため、管理サーバー１０１で図５（ｃ）の中身を参照されることはない。つまり、図５（ｃ）はテーブルの形態でなくてもよく、ファイル形式のデータであってもよい。

＜ローカルサーバー情報＞
図６は、ローカルサーバー管理部３０１（管理サーバー１０１）が管理しているローカルサーバー情報の一例を示す図である。ローカルサーバー情報は、ローカルサーバー１０５、１０８又は通信回線１０３に接続しているＰＣ等から管理サーバー１０１にアクセスすることで登録される。

図６の例では、「ローカルサーバーＩＤ」、「組織ＩＤ」、「ローカルサーバーＵＲＬ」、ローカルサーバーにアクセスするための「プロトコル」や認証情報（認証ＩＤ、認証パスワード）が保持されている。より具体的には、組織ＩＤ「ＡＡＡ」の組織に対して、ローカルサーバーＩＤ「Ｓｖｒ００１」、「Ｓｖｒ００２」の２台のローカルサーバー情報が登録されている。本願のローカルサーバー１０５はローカルサーバーＩＳ「Ｓｖｒ００１」、ローカルサーバー１０８はローカルサーバーＩＤ「Ｓｖｒ００２」に相当するものとする。組織ＩＤは、組織の識別情報の一例である。

図６に示す通り、ローカルサーバー情報にはローカルサーバーＵＲＬや認証情報（認証ＩＤや認証パスワード）といった組織ごとの機密情報が含まれるため、組織に属するデバイス１０４は自身の組織のローカルサーバー情報のみを利用でき、他の組織のローカルサーバー情報を利用できないように管理される。

＜自動設定処理＞
図７は、デバイス１０４の設定実行部３０５が実行する自動設定処理の一例を示すフローチャートである。管理サーバー１０１が主体となって実行される自動設定処理については後述する。

設定実行部３０５は、操作パネル４０５を用いて、ユーザーから設定データの検索条件の入力を受け付ける（Ｓ７０１）。その際に操作パネル４０５に表示される画面の一例を図９に示す。

入力項目９０１は、設定データを所有している組織の識別子を入力するフォームである。入力項目９０２は、設定データの検索条件を入力するフォームである。図９の例では、設定データの検索方法として、設定データＩＤでの検索、またはデバイス１０４のシリアル番号とでの検索を選択可能としている。入力項目９０２において設定データＩＤが入力された場合には、管理サーバーで管理される設定データが直接検索される。入力項目９０２において「シリアル番号（ＡＢＣ１１１１１）で検索」が選択された場合は、図５（ｂ）で設定データＩＤ「０００００００１」が特定され、設定データＩＤで特定される組織ＩＤ（図５（ａ））と図９で入力された組織ＩＤとが一致したことが確認されると、図５（ｃ）で設定データが特定される。

設定データの検索条件を選択させる形態としては図９の方法には限定されない。別の検索条件を図９の画面に複数表示させてもよく、各検索条件を選択させる画面を段階的に一つずつ表示させる形態でもよい。

このように情報処理システムでは、設定作業の効率化のためにデバイス１０４でユーザー認証でなく、設定データが特定されたことによるデバイス認証を採用する。デバイス認証を採用することによる利点は、ユーザー認証情報の管理コストや、設定作業の度にユーザー認証を要することによるタイムロスを防止できる点である。また、設定データＩＤは推測されにくく桁数の多いものが望ましい。その結果、設置作業者の認証情報を管理する必要がなく、効率的に設置作業を実行することができる。

図７の説明に戻る。設定実行部３０５は、設定データ取得部３０３を介してＳ７０１で指定された条件に合致する設定データを取得するためのリクエストを、管理サーバー１０１に対して送信する（Ｓ７０２）。

設定データ取得部３０３は、設定データを管理サーバー１０１から取得できたかを判定する（Ｓ７１５）。設定データを取得できたと判定された場合はＳ７０３に進み、設定データを取得できなかったと判定された場合は自動設定処理が終了する。取得された設定データは、設定データ取得部３０３から設定実行部３０５に送信される。

設定実行部３０５は、取得した設定データに含まれる一連の設定処理が実行されたかを判定する（Ｓ７０３）。図９の検索画面で組織ＩＤ「ＡＡＡ」、設定データＩＤ「０００００００１」が入力された際に取得される設定データの一例を図１０に示す。情報１００１は、Ｓ７０２の処理結果として受信した設定メタ情報（図５（ａ））、及び設定対象情報（図５（ｂ））である。情報１００２は、Ｓ７０２の処理結果として受信した設定データの中の設定処理情報である。設定作業者が、図１０に示す画面で設定処理内容を確認したうえで実行ボタンを押下すると、設定実行部３０５がＳ７０３以降の処理を実行する。

図７の説明に戻る。Ｓ７０３において未実行の設定処理があると判定された場合はＳ７０４に進み、すべての設定処理が実行されたと判定された場合は自動設定処理を終了する。デバイス１０４の設定実行部３０５は、ＲＡＭ４０３やＨＤＤ４０４に設定データおよび設定データで指定された各設定処理の実行状況を記憶することで、設定作業がどこまで実行されたかを管理する。その実行状況を参照しながら各設定処理を実行することで、設定処理が最終的には完了する。

設定実行部３０５は、Ｓ７０３において未処理と判定された設定処理であって、次に実行する設定処理がコンテンツデータのダウンロードであるかを判定する（Ｓ７０４）。コンテンツデータのダウンロードであると判定された場合はＳ７０６に進む。それ以外の処理であると判定された場合はＳ７０５に進み、設定データに記述された設定処理を実行する（Ｓ７０５）。

図５（ｃ）のデータで言えば、処理Ｎｏ．「００１」の設定処理「Ｄｏｗｎｌｏａｄ Ｆｉｒｍｗａｒｅ」が未処理であると設定実行部３０５が判定した場合には、Ｓ７０６に進む。一方、処理Ｎｏ．「００３」の設定処理「Ｒｅｂｏｏｔ」が未処理であると判定された場合には、Ｓ７０５に進む。

Ｓ７０４において次の設定処理がコンテンツデータのダウンロードであると判定された後、管理サーバー１０１からローカルサーバー情報を取得済みであるかを判定する（Ｓ７０６）。ローカルサーバー情報の取得方法としては、Ｓ７０２で設定データとともに取得する方法か、後述のＳ７０７で取得する方法がある。ローカルサーバー情報を取得済みであると判定された場合はＳ７０９に進み、ローカルサーバー情報を取得済みでないと判定された場合はＳ７０７に進む。

Ｓ７０６でローカルサーバー情報が取得済みでないと判定された場合、設定実行部３０５はコンテンツ取得部３０４を介し、管理サーバー１０１に対してローカルサーバー情報の取得リクエストを送信する（Ｓ７０７）。取得リクエストにはシリアル番号と、Ｓ７０１の入力操作によりデバイス１０４に一時的に記憶された組織ＩＤとが含まれる。

設定実行部３０５は、Ｓ７０７のレスポンスとして管理サーバー１０１から権限エラーを取得したかどうか判定する（Ｓ７０８）。ここでの権限とは、設定データの検索に成功したことをきっかけに、設定履歴に組織ＩＤとシリアル番号が入力されることによって付与される権限であって、デバイス１０４がローカルサーバー情報を取得するための権限を意味する。

設定実行部３０５は、権限エラーが発生してローカルサーバー情報の取得に失敗した旨を操作パネル４０５に表示する（Ｓ７１４）。デバイス１０４の操作パネル４０５に表示される権限エラーの一例を図１６に示す。情報１６０１は設定結果「失敗」を示し、情報１６０２には失敗内容を示す。

Ｓ７０８で権限エラーが発生せず正常にローカルサーバー情報を受信できた場合（ローカルサーバー情報が０件だった場合を含む）はＳ７０９に進む。

設定実行部３０５は、管理サーバー１０１から受信したローカルサーバー情報の数を判定する（Ｓ７０９）。管理サーバー１０１がデバイス１０４に対してローカルサーバー情報を送信する際には、図６の情報が参照される。受信したローカルサーバー情報の数が２件以上の場合はＳ７１０に進み、ローカルサーバー情報の数が１件だけの場合はＳ７１１に進み、ローカルサーバー情報が０件である場合はＳ７１３に進む。図６の場合、組織ＩＤ「ＡＡＡ」に関連付いたローカルサーバー情報は「Ｓｖｒ００１」と「Ｓｖｒ００２」であるため、ローカルサーバー情報リクエストには２件の情報が含まれ、Ｓ７１０に進むことになる。

ローカルサーバー情報の件数が０件である場合（つまり、レスポンスにローカルサーバー情報が含まれない場合）のＳ７０７のレスポンスの一例を図１１（ｂ）に示す。ローカルサーバー情報１１０２にはローカルサーバー情報が記載されていないことがわかる。ローカルサーバー情報が０件と判断される場合とは、図６へのローカルサーバー情報の事前登録が行われていないことを意味する。

ローカルサーバー情報が１件含まれている場合の、Ｓ７０７のレスポンスの一例を図１１（ａ）に示す。設定メタ情報の一部としてローカルサーバー情報１１０１には、設定データに指定されたローカルサーバー情報が記述されている。具体的には、図６で示されるようなローカルサーバーＩＤやローカルサーバーＵＲＬ等が含まれる。

それ以外にも、設定対象情報や設定処理情報が記述されている。なお、Ｓ７０９においてローカルサーバー情報が２以上であると判定された場合は、ローカルサーバー情報１１０１に複数のローカルサーバー情報が含まれる。

図７の説明に戻る。取得したローカルサーバー情報の数が２以上であると判定された場合、設定実行部３０５は操作パネル４０５を介して複数のローカルサーバー情報を表示し、設置で使用するローカルサーバー情報の選択を促す（Ｓ７１０）。その際に操作パネル４０５に表示される画面の一例を図１９に示す。図９の設定データの検索画面において、組織ＩＤ「ＡＡＡ」が入力されているため、図１９で表示されるローカルサーバーは、組織ＩＤ「ＡＡＡ」に属するローカルサーバー１０５（ローカルサーバーＩＤ：Ｓｖｒ００１）、１０８（ローカルサーバーＩＤ：Ｓｖｒ００２）である。

Ｓ７０９において、取得したローカルサーバー情報の数が１であると判定された場合、設定実行部３０５はコンテンツ取得部３０４を介して、指定されたローカルサーバーからコンテンツデータを取得する（Ｓ７１１）。具体的には、図５（ｃ）に示す設定処理情報に指定されたコンテンツＩＤに該当するコンテンツデータをローカルサーバーから取得する。ローカルサーバーでは、コンテンツＩＤをキーにコンテンツデータを特定できるような構成でコンテンツデータのファイルが配置されている。

また、Ｓ７１１においてローカルサーバーに対しコンテンツの取得要求を送信する際には、コンテンツ取得部３０４はローカルサーバーに対し、ローカルサーバー情報を送信する。ローカルサーバー情報を受信したローカルサーバーは、ローカルサーバー情報に含まれる認証情報（認証ＩＤまたは認証パスワード、またはその両方）を検証することでコンテンツの取得要求を送信したデバイス１０４を認証する。

設定実行部３０５は、Ｓ７１１でローカルサーバーからコンテンツデータを取得できたか判定する（Ｓ７１２）。ローカルサーバーからコンテンツデータを取得できたと判定された場合はＳ７０３に戻り、ローカルサーバーからコンテンツデータを取得できなかった場合はＳ７１３に進む。

ローカルサーバーからコンテンツデータを取得できなかった場合、設定実行部３０５はコンテンツ取得部３０４を介して、ローカルサーバーではなくコンテンツサーバー１０６等の外部サーバーからコンテンツデータを取得する（Ｓ７１３）。図５（ｃ）に示す設定処理情報に基づきコンテンツデータを取得する処理はＳ７１１と同等でも良いし、ＲＥＳＴやＳＯＡＰといったプロトコルを用いても良い。

Ｓ７１３の具体的な処理としては、管理サーバー１０１で予め管理される外部サーバー情報（コンテンツサーバー情報）がデバイス１０４によって参照される。コンテンツサーバー１０６のコンテンツサーバー情報の一例を表１に示す。

デバイス１０４は管理サーバー１０１からコンテンツサーバー情報を取得し、取得したコンテンツサーバー情報をコンテンツサーバー１０６に送信することで、ローカルサーバーから取得できなかったコンテンツデータを取得する。その際、コンテンツサーバー情報を受信したコンテンツサーバー１０６は、コンテンツサーバー情報に含まれる認証情報（認証ＩＤまたは認証パスワード、またはその両方）を検証することでデバイス１０４を認証し、コンテンツデータをデバイス１０４に送信する。尚、取得するコンテンツデータによっては、認証情報（認証ＩＤまたは認証パスワード）を用いることなく、コンテンツサーバーからコンテンツデータを取得させる形態でもよい。

このように、ファイルサイズが大きいコンテンツデータをダウンロードする際のネットワーク負荷やダウンロードに係る時間等を考慮して、コンテンツサーバー１０６でなくローカルサーバーに対してコンテンツデータの取得要求を送信する。ローカルサーバーからコンテンツデータを取得できない場合には初めてデバイス１０４は、コンテンツサーバー１０６からコンテンツデータを取得することを試みる。

以上が自動設定処理であって、Ｓ７０１とＳ７１０以外はユーザーの操作を介さずに自動で実行される。なお、より効率的に自動設定処理を実行するために、Ｓ７０６～Ｓ７１０の処理で選択されたローカルサーバーを設定実行部３０５が記憶し、２回目以降の自動設定処理でユーザーの操作を介することなく該当のローカルサーバーからコンテンツデータを取得する形態であってもよい。

＜設定データの送信処理＞
図８は、管理サーバー１０１の設定データ送信処理を示すフローチャートである。本処理は、デバイス１０４からの設定データ取得リクエストをきっかけとし、管理サーバー１０１の設定データ管理部３００が主体となって実行される。

設定データ管理部３００は、デバイス１０４の設定データ取得部３０３から、設定データ取得リクエストを受信する（Ｓ８０１）。設定データ取得リクエストには、少なくとも組織ＩＤと設定データＩＤ、または組織ＩＤとシリアル番号が含まれる。Ｓ８０１で受信する設定データ取得リクエストは、Ｓ７０２でデバイス１０４が管理サーバー１０１に送信するリクエストに対応する。尚、設定データＩＤで設定データを検索する場合も、シリアル番号で設定データを検索する場合もデバイス１０４から管理サーバー１０１に対してシリアル番号が送信される。

設定データ管理部３００は、管理サーバー１０１が保持している設定データの中に、Ｓ８０１で受信した設定データ取得リクエストに指定された条件を満たすものがあるかどうかを判定する（Ｓ８０２）。具体的には、図９において組織ＩＤ（ＡＡＡ）と設定データＩＤ（０００００００１）が指定された場合、設定データ管理部３００は図５（ｂ）に示す設定メタ情報を検索することで組織ＩＤおよびリクエストの送信元のシリアル番号が合致する設定データＩＤが存在するかどうかを判定する。

図９において組織ＩＤを指定してシリアル番号（ＡＢＣ１１１１１）で設定データを検索する場合、シリアル番号で設定データＩＤが「０００００００１」「０００００００２」が特定される。その設定データＩＤと図５（ａ）（ｄ）を用いて組織ＩＤ「ＡＡＡ」が特定され、図９で入力された組織ＩＤ「ＡＡＡ」と一致することが確認される。

設定データ管理部３００は、送信された条件で特定される設定データがある場合はＳ８０３に進み、条件を満たす設定データがない場合はＳ８０８に進む。

設定データ管理部３００は、Ｓ８０２で見つかった設定データが複数あるかどうかを判定する（Ｓ８０３）。設定データ管理部３００は、設定データが複数であると判定された場合はＳ８０４に進み、設定データが一つであると判定された場合はＳ８０６に進む。上述した通り、シリアル番号で設定データを検索した場合は、組織ＩＤおよびシリアル番号が一致する設定データが２つ存在するため、Ｓ８０４に進む。

設定データ管理部３００は、Ｓ８０２で見つかった複数の設定データのうちの一つをユーザーに選択してもらうために、各設定データの概要（例えば設定データＩＤと設定データ名）のリストをデバイス１０４に送信する（Ｓ８０４）。デバイス１０４は受信した設定データの概要をリストとして操作パネル４０５に表示する。その際に表示される表示画面の一例を図２０に示す。

図２０は、図９において設定データがシリアル番号で検索された場合の表示画面である。図９において設定データが設定データＩＤで検索された場合、設定データは一意に特定されるため、図２０のように複数の設定データが表示されるようなことはない。図２０の例では、２件の設定データが選択可能となっており、それぞれ設定データＩＤと設定データ名が表示されている。

図８の説明に戻る。設定データ管理部３００は、図２０におけるユーザー操作を介して、選択された設定データの情報を受信する（Ｓ８０５）。設定データ管理部３００は、Ｓ８０２で特定された設定データ、またはＳ８０５で選択された設定データをデバイス１０４に送信する（Ｓ８０６）。設定データ管理部３００は、設定履歴管理部３０２を介して設定履歴を更新する（Ｓ８０７）。

設定履歴管理部３０２で記憶される設定履歴の一例を図１３に示す。設定履歴は、組織ＩＤ、シリアル番号、および設定開始時刻を記録する。設定履歴管理部３０２は、設定データ取得リクエスト（Ｓ８０１）に含まれる組織ＩＤとシリアル番号を、図１３の設定履歴に記録する。設定開始時刻は、Ｓ８０７で設定履歴が更新されたときの時刻である。Ｓ８０６において設定データがデバイスに送信されない限り、設定履歴は更新されない。つまり、設定履歴にレコードが存在する、ということは、該当のデバイスに対して設定される設定データの検索が成功したことを意味する。

設定データ管理部３００は該当の設定データが見つからなかった場合、デバイス１０４に対し、指定された条件に合致した設定データがなかった旨のエラーを送信する（Ｓ８０８）。Ｓ８０８の処理は、デバイス１０４におけるＳ７１５（Ｎｏ）に相当する。以上が設定データの送信処理である。

＜設定データ取得リクエスト＞
図１２に、Ｓ７０２でデバイス１０４が管理サーバー１０１に送信する設定データ取得リクエストの一例を示す。上記でも説明した通り、設定データ取得リクエストは、Ｓ７０１で表示される検索画面（図９）で、設定データの検索条件が入力されたことをきっかけに管理サーバー１０１に送信される。

図１２（ａ）の設定データ取得リクエストは、図９の検索画面において検索条件として組織ＩＤと設定データＩＤが入力された場合に送信される。情報１２０１は、ＨＴＴＰメソッドおよびリクエストＵＲＬを表している。ＵＲＬには、パスパラメーターとして設定データＩＤ「０００００００１」と、クエリパラメーターとして組織ＩＤ「ＡＡＡ」が記載されている。

情報１２０２はＨＴＴＰヘッダを表している。図１２（ａ）では、デバイス認証の結果であるトークン（以下、デバイス認証トークン）が含まれていて、管理サーバー１０１がデバイス認証トークンを検証することにより、リクエストを送信したデバイス１０４のシリアル番号を取得することができる。ただし、デバイス認証トークンおよびそこから特定したシリアル番号から組織ＩＤを特定することはできないため、情報１２０１にクエリパラメーターとして組織ＩＤが指定されている。情報１２０３はリクエストのＢｏｄｙを表している。

図１２（ｂ）の設定データ取得リクエストは、図９の検索画面において検索条件として組織ＩＤとシリアル番号が入力された場合に送信される。図１２（ａ）との差異は、情報１２０４のパスパラメーターとして設定データＩＤが指定されていない点である。前述の通り、管理サーバー１０１はデバイス認証トークンからシリアル番号を特定することができる。

本実施例における情報処理システムは、デバイス認証を前提に説明している。しかし、デバイス１０４でユーザー認証を実施してもよく、その際にデバイス１０４から管理サーバー１０１に送信される設定データ取得リクエスト一例を図１２（ｃ）に示した。図１２（ａ）との差異は、情報１２０５のクエリパラメーターとして組織ＩＤが指定されていない点である。情報１２０６にはユーザー認証の結果であるトークン（以下、ユーザー認証トークン）が含まれていて、管理サーバー１０１がユーザー認証トークンを検証することにより、ユーザーを一意に特定することができる。さらに管理サーバー１０１は、ユーザーが関連付けられた組織ＩＤも特定することができるため、情報１２０５のＵＲＬには組織ＩＤが指定されず、設定データの検索画面上で組織ＩＤの入力を要求しない構成が可能となる。

なお、上記のユーザー認証やデバイス認証は、ＯＡｕｔｈなどの公知の技術を用いて、デバイス１０４が管理サーバー１０１に接続を開始する際に実施すれば良い（不図示）。

また、図１２に示す設定データ取得リクエストは、設定データをＵＳＢメモリーなどの外部記憶装置に書き出すために、ＰＣ１０２から管理サーバー１０１に送信しても良い。ＰＣ１０２から管理サーバー１０１に対し、設定データを取得し編集するリクエスト等を送信する場合、ユーザーはＰＣ１０２のＷｅｂブラウザーを介してユーザー認証を行うため、リクエストは図１２（ｃ）の形式となる。

また、図１２（ａ）～（ｃ）はＧＥＴリクエストの例であり、情報１２０１、１２０２に管理サーバー１０１が必要とする情報がすべて含まれているため、本実施例においてはリクエストのＢｏｄｙ（｛ ｝で記載された部分）は空欄で良い。

＜ローカルサーバー情報取得リクエスト＞
図１４は、Ｓ７０７でデバイス１０４が管理サーバー１０１に送信するローカルサーバー情報取得リクエストの一例を示す説明図である。図１２と同様の部分については同一の符番を用いてその説明を省略する。

図１４（ａ）は、デバイス認証を実施したデバイス１０４が送信するローカルサーバー情報取得リクエストの例である。情報１４０１はＨＴＴＰメソッドおよびリクエストＵＲＬを表している。ＵＲＬには、クエリパラメーターとして組織ＩＤ「ＡＡＡ」が指定されている。図１２（ａ）との差異は、ＵＲＬにパスパラメーターとして設定データＩＤが含まれていない点である。ローカルサーバー情報は図６で示した通り、組織ごとに管理されているため、ローカルサーバー情報取得リクエストに設定データＩＤを含む必要がない。

図１４（ｂ）は、ユーザー認証を実施したデバイス１０４が送信する設定データ取得リクエストの例である。情報処理システムにおいては通常、作業効率性のためデバイス１０４はユーザー認証ではなくデバイス認証を実施するが、もちろんデバイス１０４でユーザー認証を実施してもよく、その場合には図１４（ｂ）に示すリクエストとなる。図１４（ａ）との差異は、情報１４０２のクエリパラメーターとして組織ＩＤが指定されていない点である。組織ＩＤは、管理サーバー１０１が認証トークン（情報１２０６）を検証することにより、特定されるからである。

＜ローカルサーバー情報送信処理＞
図１５は、管理サーバー１０１のローカルサーバー情報送信処理の一例を示すフローチャートである。本処理は、Ｓ７０７で管理サーバー１０１がローカルサーバー情報取得リクエストを取得したことをきっかけに開始される。

ローカルサーバー管理部３０１は、デバイス１０４からローカルサーバー情報取得リクエストを受信する（Ｓ１５０１）。

ローカルサーバー管理部３０１は、Ｓ１５０１で受信したローカルサーバー情報取得リクエストの送信元がユーザー認証済みかどうかを判定する（Ｓ１５０２）。具体的には、ローカルサーバー情報取得リクエストが図１４（ａ）で示した通りの形式であれば、ユーザー認証されていないと判断してＳ１５０３に進み、ローカルサーバー情報取得リクエストが図１４（ｂ）で示した通りのリクエストであればユーザー認証済みと判断してＳ１５０４に進む。

ローカルサーバー情報取得リクエストの送信元がユーザー認証済みである状況として考えられる形態は、営業担当者等の作成者が設定データを作成する形態である。作成者はユーザー認証により管理サーバー１０１にアクセスし、ローカルサーバー情報の取得要求を送信させることも可能である。

Ｓ１５０３において、ローカルサーバー管理部３０１は、図１４（ａ）のリクエストから組織ＩＤとシリアル番号を特定し、その組み合わせが図１３に示す設定履歴に存在するかどうかを判定する（Ｓ１５０３）。今回は、図１４（ａ）のリクエストから組織ＩＤ「ＡＡＡ」を特定し、トークンから特定されるシリアル番号との組み合わせが設定履歴（図１３）に存在する場合はＳ１５０４に進み、存在しない場合はＳ１５０５に進む。

ローカルサーバー管理部３０１は、ローカルサーバー情報取得リクエストから特定した組織ＩＤに関連付けられたローカルサーバー情報を取得し、デバイス１０４に送信する（Ｓ１５０４）。具体的には、図６に示すローカルサーバー情報のうち、組織ＩＤが合致するもののみをデバイス１０４に送信する。今回は、設定データの検索画面（図９）において組織ＩＤ「ＡＡＡ」が入力されており、設定データの検索に成功しているため、図６よりローカルサーバーＩＤ「Ｓｖｒ００１」と「Ｓｖｒ００２」のローカルサーバー情報がデバイス１０４に対して送信される。

本実施例において、管理サーバー１０１からデバイス１０４に対して送信されるローカルサーバー情報には、少なくとも認証情報とローカルサーバーＵＲＬを含むものとする。ここでの認証情報とは認証ＩＤのみ、または認証ＩＤと認証パスワードの両方のことである。デバイス１０４にどの認証情報を送信するか、またそもそも認証情報を送信すべきかどうかは、デバイス１０４がローカルサーバー１０５にアクセスする際のプロトコル、または取得するコンテンツデータの種類によって異なる。

例えば、プロトコルがアノニマスＦＴＰである場合、認証パスワードはユーザーのメールアドレスであるため、認証情報としては認証ＩＤだけがデバイス１０４に送信される。また、コンテンツデータの種類によっては、ローカルサーバーからコンテンツデータを取得する際には認証情報を用いない（認証情報の値を空欄にする）形態もある。

Ｓ１５０３においてリクエストで特定された組織ＩＤとシリアル番号との組み合わせが設定履歴に存在しないと判定された場合、ローカルサーバー管理部３０１は、Ｓ１５０１で受信したローカルサーバー情報取得リクエストが不正であるとみなし、デバイス１０４に権限エラーのレスポンスを送信する（Ｓ１５０５）。

なお、図７のフローチャートによると、Ｓ７０２からＳ７０３に進む時点で管理サーバー１０１が設定履歴を記憶するため、通常はＳ７０７に伴い実行される図１５のフローチャート中のＳ１５０３でＹｅｓと判定され、Ｓ１５０５が実行されることは無い。ただし、図１４に示すローカルサーバー情報取得リクエストを改ざんするなどして、Ｓ７０２の処理を実行せずにＳ７０７を実行すると、Ｓ１５０５が実行され、ローカルサーバー情報取得リクエストの送信元に権限エラーが送信される。

以上がローカルサーバー情報送信処理である。

＜自動設定処理の概要＞
図２１は、ローカルサーバーを使用した自動設定作業の処理の一例を示すシーケンス図である。符番は、上記で説明済みのフローチャートの符番と同じである。

設定作業者がデバイス１０４で入力した組織ＩＤおよび設定データＩＤ、または組織ＩＤのみ（シリアル番号）は、管理サーバー１０１に送信される（Ｓ７０１、Ｓ７０２）。送信された情報を用いてデバイス認証を実行し、デバイス認証に成功した場合は設定データがデバイス１０４に送信される（Ｓ８０６）。デバイス認証が成功したことをきっかけに、設定履歴に組織ＩＤとシリアル番号が記憶される（Ｓ８０７）。

設定データを受信したデバイス１０４は、ローカルサーバー情報の取得リクエストを管理サーバー１０１に送信する（Ｓ７０７）。ローカルサーバー情報の取得リクエストを受信した管理サーバー１０１は設定履歴を参照し、設定データの検索がＳ８０７で成功しているのかどうかを判定する（Ｓ１５０３）。

設定データの検索に成功していると判定された場合、Ｓ７０７のリクエストに対してローカルサーバー情報を応答する（Ｓ１５０４）。応答されたローカルサーバー情報が複数である場合はユーザーが選択し、デバイス１０４は選択されたローカルサーバー１０５からコンテンツデータを取得する（Ｓ７１０～７１１）。以上が本実施例における自動設定処理の概要である。

本実施例によれば、管理サーバーで組織ごとのローカルサーバー情報を管理し、デバイスの自動設定処理時に使用可能なローカルサーバーを判断することにより、組織ごとにローカルサーバーの構築状況が異なる場合でもイントラネットを利用してコンテンツデータの取得することで効率よく設定処理を実行することができる。

また、設定データ取得リクエスト受信時に記憶された設定履歴を用いて、ローカルサーバー情報取得リクエストに対する応答の可否を判断することにより、ユーザー認証を実施していないデバイスに対する設定作業効率を低下させることなく、セキュアにローカルサーバーを送信することができる。

［第２の実施形態］
設定データが一度検索され設定履歴が無期限に有効である場合、ローカルサーバー情報取得リクエストを管理サーバー１０１に送信できさえすれば、ローカルサーバー情報を取得できてしまい、セキュリティ上の危険性が高まる。本実施例では、その課題を解決するための解決手段を示す。

実施形態２では、図１～図６、図８～図１２、図１４、図１６、図１９～図２１に示す構成が第１の実施形態と同じであり、第１の実施の形態と同様の部分については同一の符番を用いて説明を省略する。以下、実施形態１と異なる点を主に説明する。

図１７は、Ｓ８０７で設定履歴管理部３０２によって記憶される設定履歴の一例である。図１３との差異は、組織ＩＤとデバイスシリアル番号の組み合わせごとに、有効期限を記憶している点である。今回は、設定開始時刻から１時間を有効期限であるものとする。

図１８は、管理サーバー１０１のローカルサーバー情報送信処理の一例を示す。

Ｓ１８０１においてローカルサーバー管理部３０１は、Ｓ１５０３で特定した設定履歴の有効期限を現在時刻が超過していないかどうかを判断する。有効期限内であると判定された場合はＳ１５０４に進み、有効期限を超過していると判定された場合はＳ１５０５に進む。以上が実施例２の場合のローカルサーバー情報送信処理である。

本実施例によれば、設定履歴の有効期限を超過した場合はローカルサーバー情報の取得を許可しないことで、デバイス１０４によるローカルサーバー情報の取得をよりセキュアに行うことができる。

［第３の実施形態］
上記の実施例では、設定データ取得リクエストを受信したことに伴って管理サーバー１０１が設定履歴を記憶（Ｓ８０７）し、ローカルサーバー情報取得リクエストを受信したことに伴って管理サーバー１０１が設定履歴を参照（Ｓ１５０３）し、ローカルサーバー情報をデバイス１０４に提供する形態を示した。本実施例ではデバイス１０４と管理サーバー１０１間の通信回数を減らすために、デバイス１０４からの一度のリクエストで設定データとローカルサーバー情報を提供する形態を示す。本形態については図２２を用いて説明するが、上記で説明済みの処理については同じ符番を振って説明を省略する。

Ｓ７０１において、設定データの検索画面（図９）を介して組織ＩＤ及び設定データＩＤ、または組織ＩＤのみが入力された後、デバイス１０４から管理サーバー１０１に対して設定データとローカルサーバー情報の取得リクエストが送信される（Ｓ１６００）。その際、検索画面に入力された情報（組織ＩＤおよび設定データＩＤ、または組織ＩＤのみ）とシリアル番号が送信される。

設定データ管理部３００（管理サーバー１０１）は、デバイス１０４から取得した情報に基づいて設定データを特定する（Ｓ１６０１）。その際に図５を参酌する方法については、上記のＳ８０２で説明した通りである。本実施例でも、設定データを特定したことによってデバイス１０４を認証しているものとする。

またその際、デバイス１０４から受信した組織ＩＤと図６を用いて、デバイス１０４が属する組織に関連付けられたローカルサーバーを特定する。その際の処理内容は、上記のＳ１５０４で説明した通りである。Ｓ１６０１において、該当の設定データが特定できなかった場合、またはローカルサーバー情報が特定されなかった場合は、Ｓ１６００のリクエストに対してエラーが応答される。

Ｓ１６０１で特定された設定データとローカルサーバー情報がデバイス１０４に送信される（Ｓ１６０２）。それ以降のデバイス１０４の処理は、上記のＳ７１０とＳ７１１と同様の内容である。つまり、図２１と図２２を比較するとわかる通り、図２２のＳ１６００～Ｓ１６０２は図２１のＳ７０２～Ｓ１５０４に相当する。

以上が本実施例における自動設定処理である。これにより、デバイス１０４と管理サーバー１０１間の通信回数を抑えつつ、デバイス１０４は管理サーバー１０１への１回の認証処理（Ｓ７０１）により、ローカルサーバー１０５にアクセスすることができる。

［第４の実施形態］
設定データの検索（Ｓ７０２）に成功してからローカルサーバー情報の取得要求を送信するまで（Ｓ７０７）に、作業者により自動設定処理が中断され、長時間経過してしまうことがある。その状況下で第２の実施形態のように設定履歴に有効期限が設けられていると、設定履歴の有効期限が超過してしまい、ローカルサーバー情報を取得する際にエラー（Ｓ１５０５）になってしまう。

本実施例では、設定データの検索後、一時的に自動設定処理が中断されている場合でも、有効期限付きの設定履歴を活用できる形態を説明する。尚、上記で説明済みの処理や情報については同じ符番を振り、説明を省略する。

図２３を用いて、管理サーバー１０１における有効期限延長処理について説明する。まず、ローカルサーバー管理部３０１は、デバイス１０４の設定実行部３０５から設定履歴の有効期限延長リクエストを受信する（Ｓ２３０１）。管理サーバー１０１が受信する有効期限延長リクエストの一例を図２３に示す。設定実行部３０５は、実行中の自動設定処理（図７）と並行して図２３に示すような有効期限延長リクエストを管理サーバー１０１に対して定期的に送信する。

情報２２０１はＨＴＴＰメソッドおよびリクエストＵＲＬを表している。リクエストＵＲＬは、設定履歴の有効期限の延長を要求することが示されている。

図２４の説明に戻る。ローカルサーバー管理部３０１は、Ｓ２３０１で受信した有効期限延長リクエストの送信元がユーザー認証済みかどうかを判定し（Ｓ１５０２）、送信元がユーザー認証済みであると判定された場合は処理エラーをデバイス１０４に送信する（Ｓ２３０３）。上記でも述べた通り、ユーザー認証された送信元とは設定データを作成する営業担当者である。営業担当者がコンテンツデータを取得する際や設定データを取得する際には有効期限は設定されないため、ユーザー認証済みの送信元からの有効期限延長リクエストを不正なリクエストとみなされる。Ｓ１５０２において送信元が認証済みでないと判定された場合は、Ｓ１５０３に進む。

Ｓ１８０１において設定履歴の有効期限が期限内であると判定された場合、ローカルサーバー管理部３０１は、Ｓ１５０３で特定した設定履歴の有効期限を延長する（Ｓ２３０２）。一方、Ｓ１８０１において設定履歴の有効期限が期限内でないと判定された場合、処理エラーを送信する。尚、Ｓ２３０２で延長される期限の長さは、有効期限延長リクエストに指定された有効期限に基づいて決定される形態であってもよい。また、延長される期限の長さは、もともとの有効期限の長さに戻す方法であってもよい。例えば、もともとの有効期限が「２時間」であって、ローカルサーバー管理部３０１が有効期限延長リクエストを受信した時点で有効期限が「１．５時間」になっていた場合、元の有効期限「２時間」に戻す方法も考えられる。

上記の構成により、デバイス１０４から管理サーバー１０１に送信される有効期限延長リクエストは、デバイス１０４での自動設定処理が終了するとともに送信されなくなり、設定履歴の有効期限も延長されなくなる。

本実施例は、自動設定処理の遅延により設定履歴の有効期限が超過することがないよう、自動設定処理を実行している最中に有効期限が切れた場合には有効期限を延長させることができる。

〔その他の実施例〕
また、本発明の目的は以下の処理を実行することによっても達成される。即ち、上述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

１０１ 管理サーバー
１０４ デバイス
１０６ コンテンツサーバー
１０５、１０８ ローカルサーバー
３００ 設定データ管理部
３０１ ローカルサーバー管理部
３０２ 設定履歴管理部
３０３ 設定データ取得部
３０４ コンテンツ取得部
３０５ 設定実行部
３０６ 設定結果通知部

Claims (5)

1. 情報処理装置と、
   前記情報処理装置の機能を実現するためのアプリケーション、および前記アプリケーションを動作させるためのファームウェアのうち少なくとも一つを含むコンテンツデータをインストールするための指示を含む設定データを管理する管理サーバーと、
   前記コンテンツデータの少なくとも一部を管理するローカルサーバーと、
   を含む情報処理システムであって、
   前記管理サーバーは、
   前記情報処理装置からの前記情報処理装置を識別する第１の識別子および前記情報処理装置が属する組織を識別する第２の識別子を含む要求に基づいて、設定データを特定する特定手段と、
   前記特定手段で特定された前記設定データを前記情報処理装置に提供するための提供手段と、を有し、
   前記提供手段は、さらに、前記特定手段で前記設定データが特定されたことに伴って、前記第１の識別子および前記第２の識別子に基づく前記ローカルサーバーにアクセスするための認証情報を含むローカルサーバー情報を、前記情報処理装置に提供し、
   前記情報処理装置は、
   前記管理サーバーから取得した前記設定データに含まれる指示に従って前記コンテンツデータを取得する際に、前記管理サーバーから取得した前記ローカルサーバー情報を用いて前記ローカルサーバーにアクセスし、前記ローカルサーバーが管理する前記コンテンツデータを取得することを特徴とする情報処理システム。
2. 前記管理サーバーは、
   前記特定手段で前記設定データが特定された場合、前記要求に含まれる前記第１の識別子および前記第２の識別子を管理する第１の管理手段を更に有することを特徴とする請求項１に記載の情報処理システム。
3. 前記管理サーバーは、
   前記ローカルサーバー情報と、前記ローカルサーバーが属する組織を識別する第４の識別子とを関連付けて管理する第２の管理手段を更に有し、
   前記提供手段は、前記第２の管理手段によって管理された前記第４の識別子に基づいて、前記情報処理装置と同じ組織に属するローカルサーバーを特定し、該ローカルサーバーについてのローカルサーバー情報を前記情報処理装置に提供することを特徴とする請求項１または２に記載の情報処理システム。
4. 前記情報処理システムは、
   前記コンテンツデータを管理する外部サーバーを更に含み、
   前記管理サーバーは、
   前記外部サーバーにアクセスするための外部サーバー情報を管理する第３の管理手段を更に有し、
   前記情報処理装置が前記ローカルサーバーから前記コンテンツデータを取得できなかった場合、
   前記情報処理装置が、前記第３の管理手段によって管理された前記外部サーバー情報を前記管理サーバーから取得し、取得した前記外部サーバー情報を用いて前記外部サーバーにアクセスし、前記外部サーバーが管理する前記コンテンツデータを取得することを特徴とする請求項１乃至３のいずれか一項に記載の情報処理システム。
5. 情報処理装置と、
   前記情報処理装置の機能を実現するためのアプリケーション、および前記アプリケーションを動作させるためのファームウェアのうち少なくとも一つを含むコンテンツデータをインストールするための指示を含む設定データを管理する管理サーバーと、
   前記コンテンツデータの少なくとも一部を管理するローカルサーバーと、
   を含む情報処理システムにおける制御方法であって、
   前記管理サーバーは、
   前記情報処理装置からの前記情報処理装置を識別する第１の識別子および前記情報処理装置が属する組織を識別する第２の識別子を含む要求に基づいて、設定データを特定する特定ステップと、
   前記特定ステップで特定された前記設定データを前記情報処理装置に提供するための提供ステップと、を有し、
   前記提供ステップでは、さらに、前記特定ステップで前記設定データが特定されたことに伴って、前記第１の識別子および前記第２の識別子に基づく前記ローカルサーバーにアクセスするための認証情報を含むローカルサーバー情報が、前記情報処理装置に提供され、
   前記情報処理装置は、
   前記管理サーバーから取得した前記設定データに含まれる指示に従って前記コンテンツデータを取得する際に、前記管理サーバーから取得した前記ローカルサーバー情報を用いて前記ローカルサーバーにアクセスし、前記ローカルサーバーが管理する前記コンテンツデータを取得することを特徴とする制御方法。

Images