画面制御システム、サーバ、及び画面制御方法
【課題】各装置に対応するＵＩ画面を適切に表示制御する。
【解決手段】情報処理装置と、画像形成装置と、サーバとが接続された画面制御システムであって、サーバは、情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、ＵＩ定義情報に含まれるＵＩ部品に表示する表示データを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成手段と、画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示する表示データをレンダリング関数を用いて取得し、ＵＩ部品及び該ＵＩ部品に表示する表示データを含む画面を描画する第２画面情報を生成する第２生成手段とを備える。
【解決手段】情報処理装置と、画像形成装置と、サーバとが接続された画面制御システムであって、サーバは、情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、ＵＩ定義情報に含まれるＵＩ部品に表示する表示データを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成手段と、画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示する表示データをレンダリング関数を用いて取得し、ＵＩ部品及び該ＵＩ部品に表示する表示データを含む画面を描画する第２画面情報を生成する第２生成手段とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画面の表示制御を行う画面制御システム、サーバ、及び画面制御方法に関する。
【背景技術】
【０００２】
近年、ドキュメントを業務の中で活用するようなアプリケーションが増えている。そのため、一般的なExplorerのようなファイル管理ではなく、業務アプリケーションのようなUIを利用して、ドキュメントを扱うことが求められている。
【０００３】
複合機（ＭＦＰ：Multifunction Peripheral）も、このような業務連携の利用方法が増え、顧客からの注文書、申込書などの紙ドキュメントを業務アプリケーションに連動する形でシステムに取り込みたいというニーズが顕在化しつつある。様々な業務において、様々なドキュメントが利用されているが、例えば、受注管理に適したＵＩ、図面管理に適したＵＩなどは異なっていると言える。
【０００４】
ＵＩを制御して業務を効率化する技術として、例えば、特許文献１では、複合機において、ＧＵＩに配置可能なボタン等の各画面構成要素について、その画面構成要素と対応する１以上のキーワードを記憶させることで、キーワードから画面構成要素を抽出可能にし、編集操作の効率を改善する技術が開示されている。
【０００５】
一方、Ｗｅｂアプリにおいて、Ｗｅｂアプリ上でＵＩのカスタマイズするＧｏｏｇｌｅ（登録商標）のｉＧｏｏｇｌｅ（登録商標）などが開発されている。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、前述した従来の業務アプリケーションでは、個々の業務に特化したカタチでＤＢ（データベース）設計がなされ、アプリケーションが開発されていた。例えば、ドキュメント管理のアプリケーションでは、文書タイプごとにメタデータを付与するレベルに留まり、業務にあわせてＵＩを変更するためには、大規模なＳＩなどのカスタマイズが必要となる。
【０００７】
ＭＦＰからスキャンした画像をシステムに取り込む際には、個別のＭＦＰ上で動作するアプリケーションを開発するか、ＭＦＰの操作パネル上で動作するＷｅｂブラウザ（以下、ＭＦＰブラウザともいう）などを利用して、ＭＦＰ向けのＷｅｂ画面を開発するといった方法があるが、どちらも容易ではなかった。
【０００８】
また、ＰＣ用ブラウザでは、Ａｊａｘ（Asynchronous JavaScript（登録商標）+ XML）などを利用できるが、現在のＭＦＰ用ブラウザなどの組み込み用ブラウザでは、シンプルなＨＴＭＬのレンダリングしか出来ない場合もある。
【０００９】
また、例えば多数の装置が接続され、大量のデータを短時間で扱う基幹システムについては、各装置に対して適切なＵＩ画面を表示させたいが、様々な画面を全て保存することは非効率である。
【００１０】
そこで、本発明は、上記問題点に鑑みてなされたものであり、各装置に対応するＵＩ画面を適切に表示制御することができる画面制御システム、情報処理装置、及び画面制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明における一態様の画面制御システムは、情報処理装置と、画像形成装置と、サーバとが接続された画面制御システムであって、前記サーバは、画面のＵＩ部品が定義されているＵＩ定義情報を画面毎に記憶する第１記憶手段と、前記ＵＩ部品に表示する表示データを記憶する第２記憶手段と、前記情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、該ＵＩ定義情報に含まれるＵＩ部品に表示する表示データを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成手段と、前記画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示する表示データをレンダリング関数を用いて取得し、該ＵＩ部品及び該ＵＩ部品に表示する表示データを含む画面を描画する第２画面情報を生成する第２生成手段と、前記第１生成手段により生成された第１画面情報を前記情報処理装置に送信し、又は、前記第２生成手段により生成された第２画面情報を前記画像形成装置に送信する送信手段と、を備える。
【００１２】
また、本発明における他の局面のサーバは、情報処理装置と、画像形成装置とに接続されるサーバであって、画面のＵＩ部品が定義されているＵＩ定義情報を画面毎に記憶する第１記憶手段と、前記ＵＩ部品に表示する表示データを記憶する第２記憶手段と、前記情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、該ＵＩ定義情報に含まれるＵＩ部品に表示するデータを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成手段と、前記画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示する表示データをレンダリング関数を用いて取得し、該ＵＩ部品及び該ＵＩ部品に表示する表示データを含む画面を構成する第２画面情報を生成する第２生成手段と、前記第１生成手段により生成された第１画面情報を情報処理装置に送信し、又は、前記第２生成手段により生成された第２画面情報を画像形成装置に送信する送信手段と、を備える。
【００１３】
また、本発明における他の局面の画面制御方法は、情報処理装置と、画像形成装置とに接続され、画面のＵＩ部品が定義されているＵＩ定義情報を画面毎に記憶する第１記憶手段と、前記ＵＩ部品に表示する表示データを記憶する第２記憶手段とを備えるサーバにおける画面制御方法であって、前記情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、該ＵＩ定義情報に含まれるＵＩ部品に表示するデータを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成ステップと、前記画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示するデータをレンダリング関数を用いて取得し、該ＵＩ部品及び該ＵＩ部品に表示するデータを含む画面を構成する第２画面情報を生成する第２生成ステップと、前記第１生成ステップにより生成された第１画面情報を前記情報処理装置に送信し、又は、前記第２生成ステップにより生成された第２画面情報を前記画像形成装置に送信する送信ステップと、を有する。
【発明の効果】
【００１４】
本発明によれば、各装置に対応するＵＩ画面を適切に表示制御することができる画面制御システム、情報処理装置、及び画面制御方法を提供することができる。
【図面の簡単な説明】
【００１５】
【図１】実施例における画面制御システムの一例を示す図。
【図２】実施例におけるサーバ１１０のハードウェアの一例を示すブロック図。
【図３】実施例におけるサーバ１１０の機能の一例を示すブロック図。
【図４】実施例で用いるデータモデルのクラス関係の一例を示す図。
【図５】ＵＩ画面の定義データの一例を示す図。
【図６】表示画面の一部の一例を示す図。
【図７】表示画面の一例を示す図。
【図８】表示画面のパーツの連携を説明する図。
【図９】イベントによる駆動プログラムの一例を示す図。
【図１０】イベント発生のプログラムの一例を示す図。
【図１１】ＵＩ部品を描画するときのＵＲＬを生成するプログラムの一例を示す図。
【図１２】セレクトボックスの定義データの一例を示す図。
【図１３】セレクトボックスの一例を示す図。
【図１４】ＡＰＩで取得されたデータの一例を示す図。
【図１５】フォルダリストの定義データの一例を示す図。
【図１６】フォルダリストの一例を示す図。
【図１７】レンダリングの例を説明する図。
【図１８】ＰＣ用のタブ設定の一例を示す図。
【図１９】ＭＦＰ用のタブ設定の一例を示す図。
【図２０】ＰＣ用のＨＴＭＬソースの一例を示す図。
【図２１】ＰＣ用の画面の一例を示す図。
【図２２】ＭＦＰ用のＨＴＭＬソースの一例を示す図。
【図２３】ＭＦＰ用の画面の一例を示す図。
【図２４】ＪＳＯＮデータの取得とＵＩ部品の描画の一例を示す図。
【図２５】ログインの一例を示すシーケンス図。
【図２６】画面の表示処理の一例を示すシーケンス図。
【図２７】フォルダ階層の概要を説明する図。
【図２８】フォルダ階層に関するデータのデータ構造の一例を示す図。
【図２９】階層の定義とメタデータの一例を示す図。
【図３０】図２８に示すデータの画面例を示す図。
【図３１】ビューセットデータの一例を示す図。
【図３２】ビュー（タブ）データの一例を示す図。
【図３３】ビュー形成のためのデータの一例を示す図。
【図３４】ビューのＵＲＬ、ビュー、ビューセットの画面切替例を説明する図。
【図３５】タブの違いによる画面の違いを説明する図。
【図３６】ビューセットとタブの関係を示す図。
【図３７】アカウント情報の一例を示す図。
【図３８】組織情報の一例を示す図。
【図３９】ユーザ情報の一例を示す図。
【図４０】ビューフィルタ情報の一例を示す図。
【図４１】ＡＰＩの例を示す図。
【発明を実施するための形態】
【００１６】
以下、添付図面を参照して、本発明に係る画面制御システム、情報処理装置（サーバ）、画面制御方法の実施例を詳細に説明する。
【００１７】
また、以下に示す実施例では、画像データを入力する画像入力装置として、情報処理装置、又はプリンタ機能、スキャナ機能、コピー機能、ファクシミリ機能を一つの筐体に搭載した複合機を例にあげて説明する。しかし、これらに限定されるものではなく、画像データを入力可能であれば、表示画面を有するスキャナ装置、ファクシミリ装置、コピー装置などいずれにも適用することができる。
【００１８】
［実施例］
＜システムとハードウェア＞
図１は、実施例における画面制御システム１００の一例を示す図である。図１に示すように、画面制御システム１００は、ＭＦＰ１０１、クライアント装置（ＰＣ）１０３、携帯端末１０５、ＭＦＰ１０７、サーバ１１０、サーバ１３１、データベース（以下、ＤＢともいう）１３３を有する。
【００１９】
ＭＦＰ１０１は、例えば、ＭＦＰブラウザを用いて、表示画面を表示する。ＰＣ１０３は、ブラウザ上でＡｊａｘなどの非同期通信を利用可能とする。ＰＣ１０３は、表示画面の表示データに対しリクエストが発生した場合に、サーバと非同期通信を行って表示データを取得することが可能である。
【００２０】
携帯端末１０５は、ＰＣ１０３同様、ブラウザ上でＡｊａｘを利用可能とする。ＭＦＰ１０７は、ＭＦＰ１０７専用のアプリケーションからＡＰＩを利用して表示画面の表示データを取得する。
【００２１】
サーバ１１０は、各装置１０１、１０３、１０５、１０７から表示画面の表示要求を受けると、各装置に適した表示画面を構成する画面情報（ＨＴＭＬ形式）を送信する。具体的には、サーバ１１０は、カスタマイズ部１１１、画面制御部１１３、インタフェース部１１５、テンプレート管理部１１７、メタデータ管理部１１９、画面データ管理部１２１、アクセス管理部１２３を有する。
【００２２】
カスタマイズ部１１１は、ファイルやフォルダに対するアクセス権限や、ファイルやフォルダに付与されるメタデータや、表示画面のレイアウト、ＵＩパーツなどのカスタマイズを行う。ファイルとは、例えば文書ファイル（画像ファイルも含む）であり、音声ファイルや映像ファイルなどでもよい。
【００２３】
画面制御部１１３は、各装置１０１、１０３、１０５、１０７から表示画面の描画要求や表示データの取得要求を受ける。画面制御部１１３は、要求を受けた装置に適した表示画面を定義する画面情報（例えばＨＴＭＬ形式の情報）を作成し、作成した画面情報を装置に送信する。つまり、画面制御部１１３は、各装置に適した表示画面の表示制御を行う。
【００２４】
インタフェース部１１５は、例えばＪＳＯＮ（JavaScript（登録商標） Object Notation）形式やＸＭＬ(Extensible Markup Language）形式、ＷｅｂＤＡＶ（Web-based Distributed Authoring and Versioning）に対応している。各装置は、インタフェース部１１５のＡＰＩを利用して所望のデータを取得する。
【００２５】
テンプレート管理部１１７は、ファイルやフォルダのメタデータのフォーマットや、表示画面のテンプレートを記憶、管理する。
【００２６】
メタデータ管理部１１９は、フォルダ階層の定義を示す「Cabinets」、フォルダの情報を示す「Folders」、ファイルの情報を示す「Entries」、メタデータの定義を示す「Tags」を保持する。メタデータ管理部１１９で管理される情報については後述する。
【００２７】
画面データ管理部１２１は、各装置１０１、１０３、１０５、１０７で表示される表示画面に関する情報を管理する。「Smart View」は、Ａｊａｘを利用して表示画面を表示可能な装置に対する表示画面の画面情報である。「View Set」は、１又は複数の表示画面をグループ化する画面の画面情報である。「MFP View」は、Ａｊａｘを利用できない装置（例えばＭＦＰ）に対する表示画面の画面情報である。「Mobile View」は、携帯端末用の表示画面の画面情報である。
【００２８】
アクセス管理部１２３は、ファイル階層（「Cabinets」）、フォルダ（「Folders」）、ファイル（「Entries」）、及び／又はビュー（「View」：画面）に対するアクセスを制限するための情報を管理する。
【００２９】
サーバ１３１は、各フォルダに保存されるファイルを簡易的に保持、管理するサーバである。サーバ１３１は、ファイルの保存先のＵＲＬなどを記憶する記憶部（「Storage Cache」）やファイルを取得する取得部（API）を有する。ＤＢ１３２は、各装置の表示画面の定義データやＵＩ部品の定義データなどを記憶するデータベースである。ＤＢ１３３、ファイルを少なくとも記憶するデータベースである。なお、サーバ１３１、ＤＢ１３３は、サーバ１１０に含まれていてもよいし、一つのＤＢであってもよい。その他、ユーザ情報を管理するユーザ情報管理部などがあってもよい。
【００３０】
次に、実施例におけるサーバのハードウェア構成について説明する。図２は、実施例におけるサーバ１１０のハードウェア構成の一例を示すブロック図である。図２に示すように、サーバ１０７は、制御部２０１、主記憶部２０３、補助記憶部２０５、外部記憶装置Ｉ／Ｆ部２０７、ネットワークＩ／Ｆ部２１１を含む。
【００３１】
制御部２０１は、コンピュータの中で、各装置の制御やデータの演算、加工を行うＣＰＵである。また、制御部２０１は、主記憶部２０３に記憶されたプログラムを実行する演算装置であり、入力装置や記憶装置からデータを受け取り、演算、加工した上で、出力装置や記憶装置に出力する。
【００３２】
主記憶部２０３は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）などであり、制御部２０１が実行する基本ソフトウェアであるＯＳやアプリケーションソフトウェアなどのプログラムやデータを記憶又は一時保存する記憶装置である。
【００３３】
補助記憶部２０５は、ＨＤＤ（Hard Disk Drive）などであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。補助記憶部２０５は、ネットワークを介して所定のプログラムを記憶してもよい。この所定のプログラムは、インストールされることで処理可能になる。
【００３４】
外部記憶装置Ｉ／Ｆ部２０７は、ＵＳＢ（Universal Serial Bus）などのデータ伝送路を介して接続された記憶媒体２０９（例えば、フラッシュメモリ、SDカードなど）とサーバ１０７とのインタフェースである。
【００３５】
また、記憶媒体２０９に、所定のプログラムを格納し、この記憶媒体２０９に格納されたプログラムは外部記憶装置Ｉ／Ｆ部２０７を介してサーバ１０７にインストールされ、インストールされた所定のプログラムはサーバ１０７により実行可能となる。
【００３６】
ネットワークI/F部２１１は、有線及び／又は無線回線などのデータ伝送路により構築されたＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などのネットワークを介して接続された通信機能を有する周辺機器とサーバ１０７とのインタフェースである。
【００３７】
なお、サーバ１０７は、入力部や表示部を備えてもよい。入力部は、カーソルキー、数字入力及び各種機能キー等を備えたキーボード、表示部の表示画面上でキーの選択等を行うためのマウスやスライスパット等を有する。また、入力部は、ユーザが制御部２０１に操作指示を与えたり、データを入力したりするためのユーザインタフェースである。
【００３８】
表示部は、ＣＲＴやＬＣＤ等により構成され、制御部２０１から入力される表示データに応じた表示が行われる。
【００３９】
＜機能＞
図３は、実施例におけるサーバ１１０の機能の一例を示すブロック図である。図３に示す例では、サーバ１１０は、受信手段３０１、送信手段３０３、画面生成手段３０５、ユーザ認証手段３１１、アクセス制御手段３１３を含む。受信手段３０１、送信手段３０３は、ネットワークＩ／Ｆ部２１１により実現され、画面生成手段３０５、ユーザ認証手段３１１、アクセス制御手段３１３は、制御部２０１や主記憶部３０３により実現されうる。また、画面生成手段３０５は、画面制御部１１３に相当し、アクセス制御手段３１３は、アクセス管理部１２３に相当する。
【００４０】
受信手段３０１は、各装置から表示画面の表示要求を受けたり、ＵＩ部品に表示する表示データの取得要求を受けたりする。送信手段３０３は、リクエストをしていた装置に対して、画面情報、又は表示データを送信する。表示画面の表示要求は、例えば表示画面の識別情報を指示したり、表示画面の情報が保持されたＵＲＬを指示したりして行われる。
【００４１】
画面生成手段３０５は、第１生成手段３０７、第２生成手段３０９を有する。第１生成手段３０７は、非同期通信、例えばＡｊａｘが利用可能なブラウザを有する装置からの画面表示要求を受けた場合、表示画面を描画する第１画面情報を例えばＨＴＭＬ形式で生成する。生成された第１画面情報は、送信手段３０３により表示要求をした装置に送信される。第１画面情報は、表示要求を受けた表示画面のＵＩ定義データ、このＵＩ定義データに含まれるＵＩ部品に表示する表示データを非同期通信で取得するためのプログラム、例えばJavaScript（登録商標）プログラムを含む。ＵＩ定義データとは、表示画面のＵＩのレイアウトやＵＩ部品などを定義するデータである。
【００４２】
第２生成手段３０９は、シンプルなＨＴＭＬを用いてレンダリングを行う画像形成装置からの画面表示要求を受けた場合、表示画面を描画する第２画面情報を例えばＨＴＭＬ形式で生成する。生成された第２画面情報は、送信手段３０３により表示要求をした装置に送信される。第２生成手段３０９は、表示要求を受けた表示画面のＵＩ定義データに含まれるＵＩ部品に表示する表示データを、レンダリング関数を用いて取得し、取得したＵＩ部品に含まれる表示データを含む表示画面を描画する第２画面情報を生成する。
【００４３】
表示要求をした装置が非同期通信可能か否かの判断について、画面生成手段３０５は、装置の識別情報（例えばIPアドレス）と非同期通信の可否とを関連付けて記憶しておき、表示要求をした装置の識別情報に応じて非同期通信可か否かを判断すればよい。
【００４４】
また、ＭＦＰブラウザでＡｊａｘを利用可能な場合でも、レンダリング速度や画面サイズの問題から、第２生成手段３０９によりＭＦＰ用にレンダリングすることが考えられる。このとき、画面生成手段３０５は、表示要求をした装置のIPアドレスを用いて装置判定を行い、IPアドレスが情報処理装置（ＰＣ）１０３を示せば第１生成手段、ＭＦＰ１０１を示せば第２生成手段を用いて画面生成を行う。
【００４５】
ユーザ認証手段３１１は、各装置からユーザＩＤとパスワードを取得してユーザ認証を行なう。認証されたユーザに関する情報は、アクセス制御手段３１３に出力される。ユーザに関する情報とは、ユーザＩＤ、ユーザ名、ユーザが属する組織情報などを含むユーザ情報、又はユーザ情報に付与されるメタデータの少なくとも１つを含む。
【００４６】
アクセス制御手段３１３は、ログインされたユーザに対して、表示画面（ビュー）に対しアクセス制限を加え、表示可能な表示画面を制限する。アクセス制限の詳細は後述する。
【００４７】
（モデルのクラス関係）
次に、実施例で用いるデータモデルについて説明する。図４は、実施例で用いるデータモデルのクラス関係の一例を示す図である。「Organization」クラス４０１は、組織ID「rs_organization_id（単にorganization_idでもよい）」を有するクラスである。
【００４８】
「Cabinets」クラス４０９、「Folder」クラス４１１、「Entry」（ファイル）クラス４１３、「Tag」クラス４１５、「Doctype」クラス４１７は、ユーザが実際に利用するファイルやフォルダのクラスである。
【００４９】
「ContentFilter」クラス４１９、「ViewFiler」クラス４２１は、ファイルやビューに対しアクセス権を設定するためのクラスである。「SmartView」クラス４２３、「ViewSet」クラス４２５は、フォルダやファイルを業務内容に近い形式で表示するＵＩの設定を行うためのクラスである。「User」クラス４２７は、ユーザ情報を設定するためのクラスである。なお、二重で囲んだクラスは、ユーザ管理者による設定ができるクラスである。
【００５０】
（ＵＩの定義）
図５は、ＵＩの定義データの一例を示す図である。図５に示す「Rs Organization」は、組織ＩＤを示す。「Config」５０１は、ＵＩ定義データの一例を示す。ＵＩ定義データには、表示画面に表示される各ＵＩ部品が定義される。
【００５１】
例えば、ライン５１１は、ＵＩ部品の識別情報を示し、「inv_no_search」が定義されている。ライン５１３は、ＵＩ部品のコンポーネントを示し、「search_box」が定義されている。
【００５２】
ライン５１５では、ＵＩ部品とＵＩ部品にデータを表示する場合の関連付けが行われ、所定のＵＲＬにリクエストを送ると、検索結果に含まれるデータが返ってくることを示す。ライン５１７は、所定の表示領域を示し、「tab_left」が定義されている。ライン５１９は、表示データを検索する際の検索キーを示し、「stag_14」の検索キーが定義される。ライン５２１は、このＵＩ部品が表示される場合の名称が定義される。なお、図５に示すデータは、例えばＤＢ１３２に保存される。
【００５３】
図６は、表示画面の一部の一例を示す図である。図６は、図５に示すＵＩ定義データを表示した場合の例である。図６に示すタイトル６０１は、図５に示すライン５２１の「INV番号検索」が表示されたものである。また、サーチボックス６０３は、ライン５１３のＵＩ部品が表示されたものである。なお、実施例で用いるＵＩ定義データは、図５に示すライン５１１〜５２１のＵＩ部品に関するデータを記述するだけで、図６に示すタイトル６０１及びサーチボックス６０３が表示される。これにより、ＵＩのカスタマイズが容易である。なお、図６に示す画面は、例えば、第１生成手段３０５が図５に示すＵＩ定義データに基づいて第１画面情報を生成することで、ＰＣ１０３で表示可能になる。
【００５４】
（画面構成）
次に、実施例で用いる表示画面の構成について説明する。図７は、表示画面の一例を示す図である。図７に示す実線枠はペイン（pane：所定の表示領域）を示し、点線枠はパーツ（parts：ＵＩ部品）を示す。ペイン内には、１又は複数のパーツが定義される。ただし、ロゴなどの操作イベントが発生しないパーツ７１１は、ペイン内に定義しなくてもよい。ペイン７０１は、「tab_left」ペインであり、ペイン７０３は、「tab_main_top」ペインであり、ペイン７０５は、「tab_main_bottom」ペインである。
【００５５】
ペイン７０１には、セレクトボックス７１３、サーチボックス７１５などのパーツが定義されている。ペイン７０３には、ドキュメントリスト７１７のパーツが定義されている。ペイン７０５には、ドキュメントリスト７１９のパーツが定義されている。
【００５６】
次に、ペインとパーツを含む画面におけるパーツの連携について説明する。図８は、表示画面のパーツの連携を説明する図である。
（１）「Config」に定義されたbindingsをもとに、どこのペインのパラメータ変更イベントを受けるかを調べ、自ペインに再描画のための関数をbindする。
（２）bindingsの対象になったペイン内のセレクトボックスによりセレクトされた時、自分の属するペインから「pane.event_name」という名前のイベントにtriggerをかける。
（３）かかったtriggerイベントに対応するbindを実行する。
（４）bindから呼ばれた再描画関数が自ペインを再描画する。
【００５７】
なお、パラメータ変更などのイベント自体は、各パーツ単位で発生する。しかし、パーツでイベントが発生すると、ペイン名に対応付けてトリガーがかけれらるため、イベント通知を受ける側（bindされる関数）は、あらかじめ、ペインに対してbindされることになる。イベント発生は、ペイン単位で検知される。bindingsは、ペインに対して行われる。bindingするイベントは、ＵＩ部品の識別情報（div_id名）ではなく、ペイン名＋データ名である。例えば、「tab_left.layer_0（ペイン名.データ名）」である。図８に示す画面例に対し、新たにＵＩ部品を加えたい場合、ペイン内部にパーツを追加できればパーツを追加してもよいし、ペインを追加して追加したペイン内部にパーツを定義してもよい。
【００５８】
図８に示すようなパーツ連携を採用することより、他のペイン内で操作イベントが発生した場合、自ペイン内のパーツを再描画する。したがって、画面の設計者は、パーツ毎に対応付けをしなくてもよくなる。また、この対応付けによる設定の数を減らすこともできる。
【００５９】
図９は、イベントによる駆動プログラムの一例を示す図である。図９は、図８の（１）、（３）に対応するプログラムの例である。図９に示す関数は、イベントによる駆動を設定する関数である。また、「ペイン名＋データ名」のイベントの発生が起きたら他の関数を呼ぶ設定が、JavaScript（登録商標）内で行われる。「target.on_change()」は、bindが実行されたときに呼ばれる関数である。
【００６０】
図１０は、イベント発生のプログラムの一例を示す図である。図１０は、図８の（２）に対応するプログラムである。図１０に示す関数は、ＵＩ部品内でイベントを発生させる関数である。ライン１００１で、「ペイン名＋データ名」のイベントを発生させている。関数１００３は、ＤＯＭ（Document Object Model）内の変数ペインに値をセットする関数である。これにより、ＵＩ部品に操作イベントが発生したときに、所属するペインからtriggerを発生させることができる。なお、図９及び図１０に示すJavaScript（登録商標）のソースは、jqueryというライブラリの利用を前提とするが、この限りではない。
【００６１】
図１１は、ＵＩ部品を描画するときのＵＲＬを生成するプログラムの一例を示す図である。図１１は、図８の（４）に対応するプログラムである。図１１に示す関数は、ブラウザがパーツを描画するときのＵＲＬを生成する関数である。ここでは、図９の「set_param」でＤＯＭ内の「panes」に設定された値を取得して、ＵＲＬのパラメータにセットする。図９〜図１０に示すデータは、ＤＢ１３２に保存される。
【００６２】
（ＵＩパーツの設定）
次に、ＵＩパーツ（ＵＩ部品）の設定例について説明する。図１２は、セレクトボックスの定義データの一例を示す図である。図１２のライン１２０１に示す「div_id」は、ＵＩパーツのＩＤであり、ＩＤは、「layer_1_select」の例を示す。ライン１２０３に示す「component」は、利用するＵＩ部品名である。この例では、ＵＩ部品名は「select_box」の例を示す。ライン１２０５に示す「relative_url」は、データを取得するＡＰＩのＵＲＬである。
【００６３】
ライン１２０７に示す「display_fields」は、セレクトボックスに表示するデータの中のフィールド名である。ライン１２０９に示す「value_fields」は、セレクトボックスが変更されたときに、ペインに設定される値のデータのフィールドである。ライン１２１０に示す「pane」は、このＵＩパーツが属するペインである。この例では、属するペインは「tab_left」の例を示す。ライン１２１１は、ペインの値としてセットするときの名前であり、「layer_1」の例を示す。
【００６４】
図１３は、セレクトボックスの一例を示す図である。図１３では、フォルダ階層を選択するためのセレクトボックスの一例を示す。例えば、「時期」は第１階層であり、「HAWB番号検索」は第２階層である。このフォルダ階層については後述する。
【００６５】
図１３に示す１３０１のセレクトボックスは、図１２に示すＵＩパーツがブラウザを用いて表示されたときの例である。例えば、セレクトボックスのプルダウンボタンが押下された場合には、ＰＣ１０３は、例えばＡｊａｘを利用し、ライン１２０５のＡＰＩのＵＲＬにより取得された「layer_1」内のデータを表示する。
【００６６】
図１４は、ＡＰＩで取得されたデータの一例を示す図である。例えば、データ１４０１に示す「2009.11」、「2009.12」、「2010.01」、「2010.02」を取得したとする。このとき、図１３に示すブルダウンボタンが押下されると、データ１４０１内の「2009.11」、「2009.12」、「2010.01」、「2010.02」が画面に表示されることになる。なお、「layer＝layer_1」と「level＝１」は同じ第１階層のフォルダを示す。
【００６７】
次に、他のＵＩパーツの設定例について説明する。図１５は、フォルダリストの定義データの一例を示す図である。図１５に示す例では、フォルダリストの表示、また、セレクトボックスの変更を受けて、リストが再描画される設定を含む。変数１５０１は、「tab_left」のペインで「layer_0」〜「stag_15」のイベントが発生したときにそのイベントによって再描画を行なう関連付けを行う変数である。変数１５０１の情報をもとに、図９に示す関数によって、イベントに再描画用の関数が紐付けられ、図１１に示すURL生成で検索パラメータが生成される。
【００６８】
図１６は、フォルダリストの一例を示す図である。図１６に示すフォルダリスト１６０１は、図１５に示すＵＩパーツの定義データを表示した例である。例えば、左のセレクトボックス内でデータがセレクトされると、それに応じて図１６に示すフォルダリストが再描画される。
【００６９】
（レンダリング）
次に、上記のＵＩ定義データ、画面構成などを用いて、ＰＣ１０３でのレンダリングと、ＭＦＰ１０１でのレンダリングとについての概略を説明する。図１７は、レンダリングの例を説明する図である。図１７（Ａ）は、ＰＣ１０３でのレンダリングの概略を示す。
【００７０】
まず、ＰＣ１０３は表示画面の表示要求を行う。表示要求には、表示画面を示す識別情報や要求元のＩＰアドレス、ＰＣ１０３にログインしたユーザの情報などが含まれる。
【００７１】
サーバ１１０の受信手段３０１は、ＰＣ１０３から表示要求を受けると、画面生成手段３０５に表示要求を出力する。画面生成手段３０５は、ユーザの情報及び表示画面の識別情報等により、どのＵＩ定義データを用いればよいかを判断する。また、画面生成手段３０５は、ＩＰアドレスなどから第１生成手段３０７、第２生成手段３０９のどちらを用いるかを決定する。ここで、ＰＣ１０３は、非同期通信に対応しているＡｊａｘを利用することができるとする。
【００７２】
第１生成手段３０７は、表示画面のＵＩ定義データを取得し、取得したＵＩ定義データと、ＵＩ定義データに含まれるＵＩ部品の情報と、Ａｊａｘを利用するJavaScript（登録商標）のプログラムとを含む第１画面情報をＨＴＭＬ形式で生成する。第１生成手段３０７は、生成した第１画面情報を、送信手段３０３を介してＰＣ１０３に送信する。
【００７３】
ＰＣ１０３は、受信したＨＴＭＬ形式の第１画面情報に含まれるJavaScript（登録商標）のプログラムを実行し、ＵＩ部品の情報を利用してＵＩ部品をＨＴＭＬのＤＯＭ上に追加する。ＰＣ１０３は、ブラウザ上でJavaScript（登録商標）によって各ＵＩ部品のレンダリングを行う。例えば、表示データが必要なＵＩ部品の場合、ＰＣ１０３は、初期描画時や他のＵＩ部品の値（表示データ）が変更になったというイベントが発生した時にＡｊａｘを利用してＡＰＩからデータを取得する。
【００７４】
サーバ１１０の第１生成手段３０７は、ＰＣ１０３からのデータ取得要求に対して、リクエストされたＵＲＬやパラメータ（メタデータや階層など）を参照して、ＰＣ１０３が必要とするデータをＤＢ１３２から検索し、ＪＳＯＮ形式で応答データを生成する。
【００７５】
ＰＣ１０３は、ＪＳＯＮ形式で応答データを取得すると、取得したデータをＵＩ部品に表示するよう描画処理を行う。なお、複数のＵＩ部品で表示データが必要な場合は、各ＵＩ部品で非同期にデータを取得できる。ＰＣ１０３は、上記のＡＰＩを利用し、表示データを取得して描画することを繰り返す。
【００７６】
図１７（Ｂ）は、ＭＦＰ１０１でのレンダリングの概略を示す。まず、ＭＦＰ１０１は、表示画面の表示要求を行う。表示要求には、表示画面を示す識別情報や要求元のIPアドレス、ＭＦＰ１０１を利用しているユーザの情報などが含まれる。
【００７７】
サーバ１１０の受信手段３０１は、ＭＦＰ１１０から表示要求を受けると、画面生成手段３０５に表示要求を出力する。画面生成手段３０５は、ユーザの情報及び表示画面の識別情報により、どのＵＩ定義データを用いればよいかを判断する。また、画面生成手段３０５は、非同期通信に対応していないＭＦＰ１０１からの要求であるため、第２生成手段３０９を用いることを決定する。
【００７８】
第２生成手段３０９は、表示画面のＵＩ定義データに含まれるＵＩ部品の定義情報をもとにレンダリング関数を呼び出して、各ＵＩ部品に表示する表示データを取得する。第２生成手段３０９は、ＵＩ定義データとパラメータ（メタデータや階層など）を用いて表示データを検索し、表示データを表示するＵＩパーツを含む画面の第２画面情報をＨＴＭＬ形式で生成する。このとき、画面生成手段３０９は、１ページ分のＨＴＭＬ（第２画面情報）をＭＦＰ１０１に送信する。ＭＦＰ１０１は、取得したＨＴＭＬを用いて表示画面を描画する。
【００７９】
また、表示しているＵＩ部品の表示データが変更された場合、他のＵＩ部品の再描画が必要であれば、ＭＦＰ１０１は、サーバ１１０に対し、再度表示要求を行う。サーバ１１０は、再度表示要求を受けた場合、前述した処理と同様にして１ページ分のＨＴＭＬ形式の第３の画面情報をＭＦＰ１０１に送信する。
【００８０】
ここで、ビュー（タブ）設定の例について説明する。実施例では、各装置はタブを用いてビューを切り替えることも可能である。図１８は、ＰＣ用のタブ設定の一例を示す図である。図１８は、「文書リスト」を表示する簡単なビューの例を示す。図１８に示すように、枠１８０１で、このビューに表示するデータを取得するデータのＵＲＬを指定する。ここでは、「cabinets/A_project/entries.json」に保存されているデータを取得することを意味する。また、「pane」は、どこのペインに属するかを示す。「per_page」は、１ページに表示するデータ数を示す。この例では、１ページに１０個のドキュメントが表示されることを意味する。
【００８１】
図１９は、ＭＦＰ用のビュー設定の一例を示す図である。図１９に示す枠１９０１で、取得する表示データの種類を指定する。図１９に示す例では、「A_project」というフォルダに保存されているファイル（「entries」）を取得する。枠１９０３では、取得する表示データの条件を指定する。図１９に示す例では、１ページに５つのファイルを表示することを意味する。
【００８２】
次に、ＨＴＭＬソースと表示画面との関係について説明する。図２０は、ＰＣ用のＨＴＭＬソースの一例を示す図である。図２０に示す枠２００１では、JavaScript（登録商標）のプログラムの読み込みを行う。枠２００３では、ＵＩ部品の表示データの埋め込みを行う。ライン２００５などでは、ログアウトボタンなど共通の部分が定義される。ライン２００７などでは、タブの切替を行う部分である。枠２００９では、実際にＵＩ部品が設置されるＤＩＶ要素が定義される。第１生成手段３０７は、例えば図２０に示す画面情報を生成し、ＰＣ１０３に送信する指示を出す。ＰＣ１０３は、図２０に示すような画面情報を受信し、受信した画面情報に基づいて表示画面を描画する。図２０に示す画面情報は、第１生成手段３０７により生成される。ＰＣ１０３は、図２０に示すような画面情報を受信し、受信した画面情報に基づいて表示画面を描画する。
【００８３】
図２１は、ＰＣ用の画面の一例を示す図である。図２１は、図２０に示す画面情報を描画した例を示す。図２１に示す画面には、図２０に示す枠２００３の「title」の「文書リスト」が表示され、「disp_fields」の「文書名」、「Size」、「更新日時」が順に表示される。また、枠２００３の「per_page」の通り、最大「１０」個のファイルが１ページに表示される。
【００８４】
次に、図２２は、ＭＦＰ用のＨＴＭＬソースの一例を示す図である。図２２に示す枠２２０１は、印刷ボタン用のＭＦＰ特有のJavaScript（登録商標）が記載されている。枠２２０３は、ＨＴＭＬに埋め込まれたファイルのリストを表す。つまり、図１９に示す枠１９０１により取得された文書が、枠１９０３の条件に従って図２２に示す枠２２０３内に埋め込まれている例である。第２生成手段３０９は、例えば図２２に示す画面情報を生成し、ＭＦＰ１０１に送信する指示を出す。ＭＦＰ１０１は、図２２に示すような画面情報を受信し、受信した画面情報に基づいて表示画面を描画する。
【００８５】
図２３は、ＭＦＰ用の画面の一例を示す図である。図２３は、図２２に示す画面情報を描画した例を示す。図２３に示す画面には、図２２に示す枠２２０３内の「Title」と「Size」とボタンとが表示される。また、図１９の枠１９０３に示す通り、１ページには最大５つのファイルが表示される。
【００８６】
次に、ＰＣ１０３が、ＡＰＩを利用して表示データを取得する例について説明する。図２４は、ＪＳＯＮデータの取得とＵＩ部品の描画の一例を示す図である。ＰＣ１０３は、図２４の下部のＪＳＯＮ形式のＵＲＬから取得してきた表示データを、ブラウザ上でＡｊａｘを利用して描画する。図２４に示す例では、ＵＲＬが示す位置に格納されているファイルを表示する。このように、実施例におけるＰＣ１０３は、セレクトボックスでデータが選択されると、Ａｊａｘを利用してＪＳＯＮ形式で表示データを取得し、表示画面を再描画する。
【００８７】
＜動作＞
次に、画面制御システム１００の動作について説明する。図２５は、ログインの一例を示すシーケンス図である。図２５に示すステップＳ１０１で、ＰＣ１０３は、ブラウザを用いてサーバ１１０に対し、ページリクエストを行う。
【００８８】
ステップＳ１０２で、サーバ１１０は、ログイン用のチケットがリクエストに含まれていないため、ユーザ管理サーバにリダイレクトする。ステップＳ１０３で、ユーザ管理サーバは、ログイン画面をＰＣ１０３に送信する。
【００８９】
ステップＳ１０４で、ＰＣ１０３は、ログインするための情報をユーザ管理サーバに送信する。ログインするための情報とは、組織情報、ユーザ情報、パスワードなどである。
【００９０】
ステップＳ１０５で、ユーザ管理サーバは、認証が成功すると、ログイン用のチケットをＰＣ１０３に送信するとともに、サーバ１１０へのリダイレクトを行うようＰＣ１０３に指示する。
【００９１】
ステップＳ１０６で、ＰＣ１０３は、ログイン用のチケットとともにページリクエストをサーバ１１０に対して行う。ステップＳ１０７で、サーバ１１０は、ログイン用のチケットを確認し、リクエストされたページのＨＴＭＬソース（図２０参照）をＰＣ１０３に送信する。ブラウザによる描画処理は図２６を用いて説明する。なお、ユーザ管理サーバは、サーバ１１０に含まれる構成であってもよい。
【００９２】
図２６は、画面の描画処理の一例を示すシーケンス図である。図２６に示すステップＳ２０１で、ＰＣ１０３は、ログイン用のチケットを含むページリクエストをサーバに１１０に行う。
【００９３】
ステップＳ２０２で、サーバ１１０は、リクエストされたページのＨＴＭＬソースをＰＣ１０３に送信する。ＨＴＭＬソースには、ペインやＵＩの定義データを含む。
【００９４】
ステップＳ２０３で、ＰＣ１０３は、ＨＴＭＬソースのヘッダ内に記載されているＣＳＳ（Cascading Style Sheets）、JavaScript（登録商標）をサーバ１１０に要求する。
【００９５】
ステップＳ２０４で、サーバ１１０は、要求されたＣＳＳ、JavaScript（登録商標）をＰＣ１０３に送信する。ステップＳ２０５で、ＰＣ１０３は、取得したＨＴＭＬソースやＣＳＳ、JavaScript（登録商標）に基づき、画面のレンダリングが行われる。ＵＩ部品は初期化され、ＵＩ部品が描画されていく。このとき、複数のＵＩ部品がある場合、Ａｊａｘを利用して非同期に描画が実行される。
【００９６】
ステップＳ２０６で、ＰＣ１０３は、ＵＩ部品に表示データがある場合（例えば、ＵＲＬが記述されている場合）、サーバ１１０に対し、ＵＩ部品用の表示データを要求する。ステップＳ２０７で、サーバ１１０は、要求された表示データをＪＳＯＮ形式のデータで生成し、ＰＣ１０３に送信する。
【００９７】
ＰＣ１０３は、サーバ１１０からＪＳＯＮデータを取得すると、JavaScript（登録商標）を実行し、画面の再描画を行なう。
【００９８】
以上の構成により、サーバ１１０は、ページリクエストをした装置が非同期通信に対応しているか否かで画面情報の生成方法を変更し、各装置に適した画面情報をＨＴＭＬ形式で生成することができる。
【００９９】
＜ＤＢの構造＞
次に、ＤＢ１３２に保存されるデータのデータ構造の一例を説明する。以下、説明するＤＢ１３２のデータ構造は、フォルダ階層になっており、階層に意味を持たせる。さらに、各階層のフォルダに付与され、階層の意味に関連するメタデータを付与してもよい。
【０１００】
このデータ構造を用いることで、サーバ１１０は、個々の業務に合わせてＵＩのカスタマイズをしたり、ビューのアクセス制限をしたりすることが容易になる。
【０１０１】
図２７は、フォルダ階層の概要を説明する図である。図２７に示すように、フォルダ階層の定義を「キャビネット（cabinet）」とし、キャビネット毎に階層の定義付けを行う。例えば、第１階層を「顧客」とし、第２階層を「図面番号」とし、第３階層を「案件」とする。また、各階層のフォルダには、階層の定義に関連するメタデータを付与することもできる。例えば、第１階層のフォルダに、「顧客」に関連するメタデータとして「業種」、「地区」を付与し、第２階層のフィルダに、「図面番号」に関連するメタデータとして「製品種別」、「材料」を付与し、第３階層のフォルダに、「案件」に関連するメタデータとして「案件状態」、「納期」、「個数」を付与する。
【０１０２】
各フォルダには、文書ファイル（ドキュメント）が保存される。また、文書ファイルには、文書タイプが付与され、さらにメタデータを付与することも可能である。例えば、文書タイプ「見積書」の文書ファイルには、「文書状態」、「送付状態」のメタデータを付与する。
【０１０３】
また、キャビネット毎に異なる階層の定義を行うこともできる。さらに、契約アカウント毎に、異なるキャビネットを有することもできる。また、階層毎にＵＩ部品を定義しておくことで、階層に応じた表示画面を生成しやすくする。
【０１０４】
次に、フォルダ階層に関するデータについて説明する。図２８は、フォルダ階層に関するデータのデータ構造の一例を示す図である。図２８（Ａ）は、フォルダ定義情報の一例を示す図である。
【０１０５】
図２８（Ａ）に示す例では、フォルダ定義情報は、フォルダ定義情報の識別子２８００、組織ＩＤ２８０１、フォルダ階層のタイトル、フォルダ階層の定義２８０２、各階層のフォルダに付与され、階層の定義に関連するメタデータの定義２８０３、ファイルに付与されるメタデータの定義２８０４、フォルダに付与されるメタデータ２８０５、ファイルに付与されるメタデータ２８０６などを含む。
【０１０６】
フォルダ階層の定義２８０２は、各階層にフォルダの定義がなされ、各階層に意味を持たせる。例えば、フォルダ定義情報「２」では、階層１（layer_0）に「部署名」、階層２（layer_1）に「営業担当者」、階層３（layer_2）に「顧客名」、階層４（layer_3）に「案件名」が定義されている。
【０１０７】
フォルダに付与されるメタデータの定義２８０３は、各階層に付与され、階層の定義に関連するメタデータが定義される。例えば、図２８（Ａ）に示す例では、階層４に「stag_0」が付与されている。「stag_0」は、「処理状態」を示す。これは、階層４のフォルダには、処理状態（例えば、未処理、処理済み）を示すメタデータが付与されることを意味する。
【０１０８】
ファイルに付与されるメタデータの定義２８０４は、フォルダに保存されるファイルに付与されるメタデータを定義する。例えば、図２８（Ａ）に示す例では、「e_stag_0」がファイルに付与されている。「e_stag_0」は、「文書タイプ」を示すメタデータである。これは、ファイルには、文書タイプ（例えば、見積書、注文書など）を示すメタデータが付与されることを意味する。
【０１０９】
メタデータには、文字列を示すメタデータ「stag（string-tag）」と年月日を示すメタデータ「dtag（data-tag）」などがある。メタデータは、他にも「ntag（number-tag）」や「btag（boolean-tag）」などがあってもよい。また、フォルダに付与されるメタデータと、ファイルに付与されるメタデータとは識別可能である。なお、フォルダに付与されるメタデータは、そのフォルダに保存されるファイルに対応付けられる。
【０１１０】
図２８（Ｂ）は、フォルダ情報の一例を示す図である。フォルダ情報は、フォルダ毎に、フォルダＩＤ２８２０、組織ＩＤ２８０１、フォルダ定義情報の識別子２８００、親フォルダの識別子２８０２１、どの階層かを示すレベル２８２２、各階層の定義に対応するデータ２８２３、フォルダに付与されるメタデータの定義に対応するメタデータ２８２４などを含む。
【０１１１】
なお、フォルダ情報の各階層は、自階層以上の階層のフォルダ定義に対応するデータを保持してもよい。例えば、階層（level）が「２」のフォルダ情報として、「layer_0」の「東京本社」、「layer_1」の「若本」、「layer_2」の「ＢＢＢ工業」が保持されている。これにより、上位階層のフォルダの定義に対応するデータを取得する際、親フォルダを辿らなくても容易に取得可能となる。また、階層の定義に対応するデータが、その階層のフォルダの名称とされてもよい。
【０１１２】
メタデータ２８２４は、「stag_0」２８０５に対応するデータである。「stag_0」２８０５が「処理状態」を定義しているため、メタデータ２８２４は、処理状態を示すデータとなる。図２８（Ｂ）に示す例では、メタデータ２８２４は、「処理済み」を示す。
【０１１３】
図２８（Ｃ）は、ファイル情報の一例を示す図である。ファイル情報は、ファイルＩＤ２８４０、組織ＩＤ２８０１、どのフォルダに保存されているかを示すフォルダＩＤ２８２０、ファイルのタイトル２８４１、ファイルが格納されている位置を示すＵＲＬ２８４２、ファイルサイズ２８４３、ファイルのメタデータ２８４４などを含む。
【０１１４】
なお、ファイルのメタデータ２８４４は、フォルダのメタデータ２８２４と識別可能である。例えば、ファイルのメタデータ２８４４には、「e_stag」というように、ファイルのメタデータを示す「e_」が付与されている。これにより、フォルダのメタデータとファイルのメタデータとを区別して管理、検索などをすることができる。
【０１１５】
図２８に示すデータ構造を有することで、フォルダ階層に意味を持たせ、その階層のフォルダにメタデータを付与してファイルを管理することができる。サーバ１１０は、階層毎にＵＩ部品を定義することで、階層に沿った形式でのＵＩのカスタマイズなどが可能になる。ユーザは業務内容に合わせてフォルダ階層を生成する場合が多いので、階層に沿った形でＵＩがカスタマイズされると、業務に連動したＵＩが生成されることになる。
【０１１６】
次に、階層の定義とメタデータの例について説明する。図２９は、階層の定義とメタデータの一例を示す図である。図２９（Ａ）は、階層の定義を示す図である。図２９（Ａ）に示す例では、第１階層は「部署名」、第２階層は「営業担当者」、第３階層は「顧客名」、第４階層「案件名」が階層に定義づけられている。図２９（Ｂ）は、各階層のフォルダに付与されるメタデータの定義を示す図である。図２９（Ｂ）に示す例では、第４階層のフォルダには、「状態」がメタデータとして定義付けられている。なお、第１階層のフォルダには、「所在地」、第３階層のフォルダには、「業種」などのメタデータが定義付けられてもよい。
【０１１７】
図３０は、図２８に示すデータの画面例を示す図である。表示画面３００１は、領域３００３と領域３００５を含む。領域３００３は、フォルダ定義情報及びフォルダ情報から記述されるフォルダ構成が描画される。領域３００３のフォルダ構成は、図２８（Ａ）に示すフォルダ定義情報の識別情報「２」のフォルダ構成である。
【０１１８】
例えば、図３０の領域３００３に示すように、東京本社（第１階層）、若本（第２階層）、ＢＢＢ工業（第３階層）、計測器部品受注（第４階層）が階層順に描画される。領域３００３に示すフォルダ構成は、第３階層までの例である。
【０１１９】
図３０の領域３００５は、ファイル情報から記述されるファイル構成が描画される。図２８（Ｃ）を参照すると、フォルダＩＤ「４」の「計測器部品受注」フォルダには、「見積書.pdf」、「注文書.pdf」、「納品書.pdf」が保存されている。これにより、領域３００５には、「見積書.pdf」、「注文書.pdf」、「納品書.pdf」が描画される。
【０１２０】
図３０に示す画面の場合、第１生成手段３０７は、各フォルダに対し、フォルダの格納位置を示すURLを記述しておく。ＰＣ１０３は、フォルダへのダブルクリックなどでイベントを検出し、ダブルクリックされたフォルダに対応するＵＲＬから表示データを取得し、取得した表示データを領域３００５に再描画する。この場合の表示データは、文書ファイルである。
【０１２１】
（ビュー及びビューセット）
次に、ビュー及びビューセットについて説明する。ビューセットとは、１又は複数のビューがグループ化され、グループ内のビューが切替可能である画面のことをいう。実施例において、サーバ１１０は、ビューセットを定義しておくことで、例えば部署毎に表示可能なビューを容易に切り替えることができる。
【０１２２】
図３１は、ビューセットデータの一例を示す図である。図３１に示すように、ビューセットには、ビューセットＩＤ（id）、組織ＩＤ（organization_id）、タブを表示するためのＵＲＬのパス名（tiltle）、表示用のタブ名（display_name）、ＵＩ部品が定義されている情報（config）、ビューのタイプ（view_type）、スキン（skin）、ビューの順番（view_order）が関連付けられている。
【０１２３】
例えば、ビューセットＩＤ「２」には、ＵＲＬのパス名「factory」、タブ名「工場向け」、ビュータイプ「ＰＣ」、スキン「smoothness」、順番「１、４」が設定されている。「スキン」は、画面の色調などを変更して、ユーザに違いを強調するためのデータである。例えば「smoothness」、「normal」などがある。「smoothness」は、「normal」に比べて明度や彩度を変更し滑らかなイメージを与える色調にする。また、ビューセットの「config」には、ロゴやログアウトボタンなど共通のＵＩ部品が定義されている。「view_order」には、ビューの識別情報が左からの表示順に設定されている。「view_order」の「＊」は、「view_type」が同じ全てのビューを示すと解釈される。
【０１２４】
図３２は、ビュー（タブ）データの一例を示す図である。図３２に示すように、ビューのデータ構造は、ビューセットと同様である。図３２に示す「config」は、一覧を表示するような場合、例えば図１５に示すようなドキュメントリストの定義データが設定される。ここで、図３１に示す「view_order」の「＊」は、「view_type」が同じ「ＰＣ」のビューＩＤ「１，２，３，４」を示すと解釈される。
【０１２５】
図３３は、ビュー形成のためのデータの一例を示す図である。図３３（Ａ）は、図３１に示すようなビューセットデータを形成するために定義されたデータを示す。図３３（Ａ）に示す例では、種類（string、text、datetime、integerなど）に応じてデータが定義されている。例えば、「view_type」は、文字列形式（string）であり、「config」は、テキスト形式（text）であり、「view_order」は、整数形式（integer）である。
【０１２６】
図３３（Ｂ）は、図３２に示すようなビューデータを形成するために定義されたデータを示す。例えば、「display_name」は、文字列形式（string）である。図３３に示すように、各データには、定義された形式でデータが入力される。
【０１２７】
図３４は、ビューのＵＲＬ、ビュー、ビューセットの画面切替例を説明する図である。図３４に示す例では、図３１に示すビューセットのid「２」のビューセットについて説明する。
（１）ビューセットのid「２」のビューセットを表示する場合
ＰＣ１０３は、例えば「https://host_name/APP_name/view/factory」のＵＲＬを表示する場合、ＵＲＬ末尾の「factory」が示すビューセットを表示する。また、ビューセット「factory」は、ビューのid「１」が一番上に表示される。なお、ビューのid「１」は、図３２に示す例によると、「案件一覧」が表示される。
（２）ビューセットのid「２」の二番目のビューを表示する場合
ＰＣ１０３は、例えば「https://host_name/APP_name/view/factory/drawing」のＵＲＬを表示する場合、ＵＲＬ末尾の「drawing」が示すビューを表示する。
（３）ビューセットのid「１」のビューセット（display_name=Default）を表示した場合
ＰＣ１０３は、例えば「https://host_name/APP_name/view/all」のＵＲＬを表示した場合、図３４の下部に示すような画面が表示される。ビューセットのid「１」のビューセットは、「view_type」が「ＰＣ」であるビュー全てを表示可能とする。このとき、ビューのidの番号が一番小さい「１」の「案件一覧」が表示される。また、ユーザが「未回答一覧」のタブを押下すると、ビューのid「２」を表示するため（図３２参照）、ＰＣ１０３のブラウザは、ＵＲＬ「・・・/view/all/to_be_respond」により取得した表示画面を表示する。
【０１２８】
上記のようなビューやビューセットのデータ構造がＤＢ１３２に保存されることで、例えば、同じ会社であっても、ビュー（タブ）毎に「config」を作成し、保存しておくことで、タブ毎に違った見せ方、使い方をすることができる。
【０１２９】
画面生成手段３０５は、ビューセットの表示要求を受けた場合、上記のようなタブのＵＲＬを第１画面情報に含めておくことで、ＰＣ１０３のブラウザはＡｊａｘを利用して各タブを非同期通信により取得することができる。
【０１３０】
図３５は、タブの違いによる画面の違いを説明する図である。図３５（Ａ）は、案件検索用のタブを表示する画面例である。図３５（Ｂ）は、見積り依頼対応用のタブを表示する画面例である。このように、同じ会社であっても、タブによって、違う見せ方（例えばスキン）や違う使い方（コンポーネントの数）をすることができる。
【０１３１】
また、図３１を用いて説明したように、実施例におけるサーバ１１０は、タブの組み合わせをビューのセットとして管理することができる。例えば、営業部向けタブセット、製造部向けタブセット、経理向けタブセットなどである。
【０１３２】
図３６は、ビューセットとタブの関係を示す図である。図３６（Ａ）は、「Advanced」セットであるため、「案件」タブ、「見積り依頼対応」タブ、「製造予定日順」タブの全てが表示可能である。図３６（Ｂ）は、「Simple」セットであるため、「案件」タブしか表示できないし、案件リストについても図３６（Ａ）に比べると項目が少ない。これは、ＵＩ定義データで設定するコンポーネントを少なくすればよい。上記のように、各タブのＵＩ定義データやビューセット画面の定義データなどをＤＢ１３２に保存しておく。
【０１３３】
また、上記例では、ＰＣ１０３用のビューやビューセットの例を示したが、図１７に基づいて、ＭＦＰ１０１からタブの切替要求を受けたサーバ１１０は、切替後のタブ１ページ分のＨＴＭＬを生成して、ＭＦＰ１０１に送信すればよい。よって、ＭＦＰ１０１でもＤＢ１３２に保存されているビューセットの表示は可能である。
【０１３４】
＜ビュー制限＞
図３７は、アカウント情報の一例を示す図である。図４に示す例では、アカウント情報は、ユーザＩＤ３７０１、ログイン名３７０３、パスワード３７０５、ユーザに割り当てられたグループ３７０７が関連付けられている。例えばユーザＩＤ「１」は、ログイン名が「tanabe」である。また、ユーザＩＤ「３」は、ログイン名が「iwata」であり、「managers」グループに属する。
【０１３５】
図３８は、組織情報の一例を示す図である。図３８に示す例では、組織情報は、組織ＩＤ３８０１、組織名３８０３、ディスプレイに表示される名称を示す表示名３８０５、所在地を示すタイムゾーン３８０７、使用言語を示す言語３８０９が関連付けられている。例えば組織ＩＤ「１」は、組織名「CompanyA」であり、表示部への表示名は「Ａ社」であり、所在地は「Tokyo」であり、使用言語は「Japanese」である。
【０１３６】
図３９は、ユーザ情報の一例を示す図である。図３９に示す例では、ユーザＩＤ３７０１は、図３７に示す「id」と同じ識別情報であり、組織ＩＤ３８０１は、図３８に示す「id」と同じ識別情報である。
【０１３７】
図３９に示す例では、ユーザ情報は、ユーザＩＤ３７０１、組織ＩＤ３８０１、ログイン名３９０１、タグ（第１メタデータ）３９０３、タグ（第２メタデータ）３９０５やグループ３９０７が関連付けられている。例えば、ユーザＩＤ「２」は、組織ＩＤ「３」であり、ログイン名が「wakamoto」であり、第１メタデータである「u_stag_0」が「営業部」であり、第２メタデータである「u_stag_1」が「埼玉工場」である。このようにユーザ情報にはメタデータを付与することができるようにする。
【０１３８】
ユーザ認証手段３１１は、装置から取得したログイン名及びパスワードと、図３７に示すアカウント情報のログイン名及びパスワードとを照合する。照合が一致すれば、ユーザ認証手段３１１は、ユーザＩＤを基に、図３８に示すユーザ情報を参照して組織ＩＤを取得し、認証チケットにユーザＩＤ、組織ＩＤ、及びメタデータを含める。実施例では、これらのユーザ情報を用いてビューに対してアクセス制限を加える。
【０１３９】
図４０は、ビューフィルタ情報の一例を示す図である。図４０に示すビューフィルタには、フィルタid、組織id（organization_id）、ビューセットid（view_set_id）、タイトル（title）、説明（description）、条件（user_condition）が関連付けられている。
【０１４０】
例えば、id「１」のフィルタ情報は、組織id「３」であり、ビューセットidが「１」であり、タイトルが「管理部門用」であり、条件が「"u_stag_0":"管理部"」である。このフィルタが示すのは、管理部は全てのＰＣ用のビューが見えるということである。
【０１４１】
アクセス制御手段３１３又は画面生成手段３０５は、ビューのアクセス制限を以下の手順で行う。
ａ）リクエストＵＲＬを解析
ｂ）ログインユーザの情報をＤＢから取得
ｃ）ビューセットをＤＢから取得
ｄ）ビューフィルタをＤＢから取得
ｅ）ログインユーザが閲覧可能なビューセットのリストを生成（ビューセット切替セレクトボックス用）
ｆ）リクエストされているビューセットが表示可か判定（許可されない場合はエラーを返す）
ｇ）ビューセットに含まれるビューをＤＢから取得（ビューの切替タブ用）
ｈ）リクエストされているビューの「config」情報を元に、JavaScript（登録商標）とＵＩ部品の情報を含むＨＴＭＬ形式の画面情報を生成して装置に返す。
【０１４２】
ａ）〜ｃ）の処理は、画面生成手段３０５が行う。次に、アクセス制御手段３１３は、ｄ）において、ログインのユーザのメタデータや組織情報などに基づいてビューフィルタを取得すると、ログインユーザが閲覧可能なビューセットのidを画面生成手段３０５に出力する。
【０１４３】
画面生成手段３０５は、ｅ）において、アクセス制御手段３１３から取得したビューセットのidに基づいてビューセットのリストを生成する。アクセス制御手段３１３は、ｆ）でリクエストされたＵＲＬのビューセットが表示可か判定する。例えば、アクセス制御手段３１３は、リクエストされたＵＲＬのビューセットのＵＲＬのパス名が、取得されたビューセットのidに対応するＵＲＬのパス名と一致すれば、そのビューセットは表示可と判定する。ｇ）〜ｈ）の処理は、画面生成手段３０５が行う。
【０１４４】
また、アクセス制御手段３１３は、先にｄ）のビューフィルタを取得し、ビューフィルタの制約のもとでビューセットのＤＢから表示可能なビューのリストを取得することも可能である。
【０１４５】
これにより、ビューフィルタ情報を用いることで、ユーザに関連する情報を用いて、ビューセットにアクセス制限を加えることができる。ユーザに関する情報とは、ユーザのメタデータ、ユーザの組織情報、ユーザＩＤなどである。
【０１４６】
＜ＡＰＩ＞
図４１は、ＡＰＩの例を示す図である。図４１は、サーバ１１０で用いるＡＰＩ（Application Program Interface）の例を示す図である。図４１に示すパス４１０１「cabinets/{id}/folders.json」は、フォルダの一覧を取得するときのＡＰＩである。例４１０２は、レイヤー「２」（第２階層）かつレイヤー「０」の定義に対応するデータが「ＪＰ」であるフォルダ一覧を取得するＡＰＩの例である。このときフォルダ一覧には、レイヤー２以上の階層の定義に対応するデータが表示される。
【０１４７】
パス４１０３「cabinets/{id}/layers.json」は、指定した階層のフォルダ名の一覧を取得するときのＡＰＩである。例４１０４は、レイヤー「１」（第１階層）のフォルダのフォルダ名の一覧を取得するＡＰＩの例である。このときフォルダ名一覧には、例えば、「2007.01」「2007.02」などが表示される。
【０１４８】
なお、「layers」は、「folders」と違いがあり、ユニークなデータとなっている。例えば、担当者名でフォルダを作成すると、全ての年度に担当者名のフォルダが出来る。このとき、「folders」で階層を指定した場合、同じ担当者のフォルダが何度も表示されるが、「layers」で指定した場合、全て異なる担当者のフォルダが表示される。
【０１４９】
パス４１０５「cabinets/{id}/entries.json」は、ファイル一覧を取得するときのＡＰＩである。例４１０６は、レイヤー「２」（第２階層）のフォルダ名が「00000012344891」であるフォルダに保存されているファイル一覧を取得するＡＰＩの例と、フォルダＩＤが「2108」であるフォルダに保存されているファイル一覧を取得するＡＰＩの例である。このときファイル一覧には、例えば、ファイルＩＤ、位置、サイズ、タイトルなどが表示される。
【０１５０】
パス４１０７「cabinets/{id}/tags.json」は、タグ候補の一覧を取得するときのＡＰＩである。例４１０８は、「stag_2」の候補となるタグの一覧を取得するＡＰＩの例である。このとき、キャビネットＩＤ、フォルダＩＤ、タグ名、タグタイプなどが表示される。図４１に示すＡＰＩを用いて、ＰＣ１０３は、各種データを取得することが可能となる。
【０１５１】
以上、実施例によれば、各装置に対応するＵＩ画面を適切に表示制御することができる。また、実施例によれば、ペイン単位でイベント発生を検知するため、ＵＩ部品毎に対応付けを行わなくてもよい。また、実施例によれば、ビューセットやタブを効率よく用いることで、例えば部署毎に表示可能なビューを容易に切り替えることができる。また、実施例によれば、ビューフィルタ情報を用いることで、ユーザに関連する情報に基づいてビューのアクセスを適切に制限することができる。
【０１５２】
また、携帯端末でＡｊａｘを利用可能であれば、画面生成手段３０５は、モバイル用もＰＣ用と同様にして画面情報を生成することができる。このとき、モバイル用は表示画面が小さいので、表示するＵＩ部品を少なくしたり、表示データの項目を減らしたりすればよい。
【０１５３】
実施例のサーバで実行されるプログラムは、前述した各手段を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記記憶媒体からプログラムを読み出して実行することにより上記各手段が主記憶装置上にロードされ、上記各手段が主記憶装置上に生成されるようになっている。
【０１５４】
なお、本発明は、上記実施例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施例に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施例に示される全構成要素からいくつかの構成要素を削除してもよい。
【符号の説明】
【０１５５】
１０１ ＰＣ
１０３ ＭＦＰ
１０５ 携帯端末
１０７ ＭＦＰ
１１０ サーバ
１１３ 画面制御部
１１５ インタフェース部
１１９ メタデータ管理部
１２１ 画面データ管理部
１３３ ＤＢ
３０１ 受信手段
３０３ 送信手段
３０５ 画面生成手段
３０７ 第１生成手段
３０９ 第２生成手段
３１１ ユーザ認証手段
３１３ アクセス制御手段
【先行技術文献】
【特許文献】
【０１５６】
【特許文献１】特開２００９−４８３９７号公報
【技術分野】
【０００１】
本発明は、画面の表示制御を行う画面制御システム、サーバ、及び画面制御方法に関する。
【背景技術】
【０００２】
近年、ドキュメントを業務の中で活用するようなアプリケーションが増えている。そのため、一般的なExplorerのようなファイル管理ではなく、業務アプリケーションのようなUIを利用して、ドキュメントを扱うことが求められている。
【０００３】
複合機（ＭＦＰ：Multifunction Peripheral）も、このような業務連携の利用方法が増え、顧客からの注文書、申込書などの紙ドキュメントを業務アプリケーションに連動する形でシステムに取り込みたいというニーズが顕在化しつつある。様々な業務において、様々なドキュメントが利用されているが、例えば、受注管理に適したＵＩ、図面管理に適したＵＩなどは異なっていると言える。
【０００４】
ＵＩを制御して業務を効率化する技術として、例えば、特許文献１では、複合機において、ＧＵＩに配置可能なボタン等の各画面構成要素について、その画面構成要素と対応する１以上のキーワードを記憶させることで、キーワードから画面構成要素を抽出可能にし、編集操作の効率を改善する技術が開示されている。
【０００５】
一方、Ｗｅｂアプリにおいて、Ｗｅｂアプリ上でＵＩのカスタマイズするＧｏｏｇｌｅ（登録商標）のｉＧｏｏｇｌｅ（登録商標）などが開発されている。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、前述した従来の業務アプリケーションでは、個々の業務に特化したカタチでＤＢ（データベース）設計がなされ、アプリケーションが開発されていた。例えば、ドキュメント管理のアプリケーションでは、文書タイプごとにメタデータを付与するレベルに留まり、業務にあわせてＵＩを変更するためには、大規模なＳＩなどのカスタマイズが必要となる。
【０００７】
ＭＦＰからスキャンした画像をシステムに取り込む際には、個別のＭＦＰ上で動作するアプリケーションを開発するか、ＭＦＰの操作パネル上で動作するＷｅｂブラウザ（以下、ＭＦＰブラウザともいう）などを利用して、ＭＦＰ向けのＷｅｂ画面を開発するといった方法があるが、どちらも容易ではなかった。
【０００８】
また、ＰＣ用ブラウザでは、Ａｊａｘ（Asynchronous JavaScript（登録商標）+ XML）などを利用できるが、現在のＭＦＰ用ブラウザなどの組み込み用ブラウザでは、シンプルなＨＴＭＬのレンダリングしか出来ない場合もある。
【０００９】
また、例えば多数の装置が接続され、大量のデータを短時間で扱う基幹システムについては、各装置に対して適切なＵＩ画面を表示させたいが、様々な画面を全て保存することは非効率である。
【００１０】
そこで、本発明は、上記問題点に鑑みてなされたものであり、各装置に対応するＵＩ画面を適切に表示制御することができる画面制御システム、情報処理装置、及び画面制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明における一態様の画面制御システムは、情報処理装置と、画像形成装置と、サーバとが接続された画面制御システムであって、前記サーバは、画面のＵＩ部品が定義されているＵＩ定義情報を画面毎に記憶する第１記憶手段と、前記ＵＩ部品に表示する表示データを記憶する第２記憶手段と、前記情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、該ＵＩ定義情報に含まれるＵＩ部品に表示する表示データを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成手段と、前記画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示する表示データをレンダリング関数を用いて取得し、該ＵＩ部品及び該ＵＩ部品に表示する表示データを含む画面を描画する第２画面情報を生成する第２生成手段と、前記第１生成手段により生成された第１画面情報を前記情報処理装置に送信し、又は、前記第２生成手段により生成された第２画面情報を前記画像形成装置に送信する送信手段と、を備える。
【００１２】
また、本発明における他の局面のサーバは、情報処理装置と、画像形成装置とに接続されるサーバであって、画面のＵＩ部品が定義されているＵＩ定義情報を画面毎に記憶する第１記憶手段と、前記ＵＩ部品に表示する表示データを記憶する第２記憶手段と、前記情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、該ＵＩ定義情報に含まれるＵＩ部品に表示するデータを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成手段と、前記画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示する表示データをレンダリング関数を用いて取得し、該ＵＩ部品及び該ＵＩ部品に表示する表示データを含む画面を構成する第２画面情報を生成する第２生成手段と、前記第１生成手段により生成された第１画面情報を情報処理装置に送信し、又は、前記第２生成手段により生成された第２画面情報を画像形成装置に送信する送信手段と、を備える。
【００１３】
また、本発明における他の局面の画面制御方法は、情報処理装置と、画像形成装置とに接続され、画面のＵＩ部品が定義されているＵＩ定義情報を画面毎に記憶する第１記憶手段と、前記ＵＩ部品に表示する表示データを記憶する第２記憶手段とを備えるサーバにおける画面制御方法であって、前記情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、該ＵＩ定義情報に含まれるＵＩ部品に表示するデータを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成ステップと、前記画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示するデータをレンダリング関数を用いて取得し、該ＵＩ部品及び該ＵＩ部品に表示するデータを含む画面を構成する第２画面情報を生成する第２生成ステップと、前記第１生成ステップにより生成された第１画面情報を前記情報処理装置に送信し、又は、前記第２生成ステップにより生成された第２画面情報を前記画像形成装置に送信する送信ステップと、を有する。
【発明の効果】
【００１４】
本発明によれば、各装置に対応するＵＩ画面を適切に表示制御することができる画面制御システム、情報処理装置、及び画面制御方法を提供することができる。
【図面の簡単な説明】
【００１５】
【図１】実施例における画面制御システムの一例を示す図。
【図２】実施例におけるサーバ１１０のハードウェアの一例を示すブロック図。
【図３】実施例におけるサーバ１１０の機能の一例を示すブロック図。
【図４】実施例で用いるデータモデルのクラス関係の一例を示す図。
【図５】ＵＩ画面の定義データの一例を示す図。
【図６】表示画面の一部の一例を示す図。
【図７】表示画面の一例を示す図。
【図８】表示画面のパーツの連携を説明する図。
【図９】イベントによる駆動プログラムの一例を示す図。
【図１０】イベント発生のプログラムの一例を示す図。
【図１１】ＵＩ部品を描画するときのＵＲＬを生成するプログラムの一例を示す図。
【図１２】セレクトボックスの定義データの一例を示す図。
【図１３】セレクトボックスの一例を示す図。
【図１４】ＡＰＩで取得されたデータの一例を示す図。
【図１５】フォルダリストの定義データの一例を示す図。
【図１６】フォルダリストの一例を示す図。
【図１７】レンダリングの例を説明する図。
【図１８】ＰＣ用のタブ設定の一例を示す図。
【図１９】ＭＦＰ用のタブ設定の一例を示す図。
【図２０】ＰＣ用のＨＴＭＬソースの一例を示す図。
【図２１】ＰＣ用の画面の一例を示す図。
【図２２】ＭＦＰ用のＨＴＭＬソースの一例を示す図。
【図２３】ＭＦＰ用の画面の一例を示す図。
【図２４】ＪＳＯＮデータの取得とＵＩ部品の描画の一例を示す図。
【図２５】ログインの一例を示すシーケンス図。
【図２６】画面の表示処理の一例を示すシーケンス図。
【図２７】フォルダ階層の概要を説明する図。
【図２８】フォルダ階層に関するデータのデータ構造の一例を示す図。
【図２９】階層の定義とメタデータの一例を示す図。
【図３０】図２８に示すデータの画面例を示す図。
【図３１】ビューセットデータの一例を示す図。
【図３２】ビュー（タブ）データの一例を示す図。
【図３３】ビュー形成のためのデータの一例を示す図。
【図３４】ビューのＵＲＬ、ビュー、ビューセットの画面切替例を説明する図。
【図３５】タブの違いによる画面の違いを説明する図。
【図３６】ビューセットとタブの関係を示す図。
【図３７】アカウント情報の一例を示す図。
【図３８】組織情報の一例を示す図。
【図３９】ユーザ情報の一例を示す図。
【図４０】ビューフィルタ情報の一例を示す図。
【図４１】ＡＰＩの例を示す図。
【発明を実施するための形態】
【００１６】
以下、添付図面を参照して、本発明に係る画面制御システム、情報処理装置（サーバ）、画面制御方法の実施例を詳細に説明する。
【００１７】
また、以下に示す実施例では、画像データを入力する画像入力装置として、情報処理装置、又はプリンタ機能、スキャナ機能、コピー機能、ファクシミリ機能を一つの筐体に搭載した複合機を例にあげて説明する。しかし、これらに限定されるものではなく、画像データを入力可能であれば、表示画面を有するスキャナ装置、ファクシミリ装置、コピー装置などいずれにも適用することができる。
【００１８】
［実施例］
＜システムとハードウェア＞
図１は、実施例における画面制御システム１００の一例を示す図である。図１に示すように、画面制御システム１００は、ＭＦＰ１０１、クライアント装置（ＰＣ）１０３、携帯端末１０５、ＭＦＰ１０７、サーバ１１０、サーバ１３１、データベース（以下、ＤＢともいう）１３３を有する。
【００１９】
ＭＦＰ１０１は、例えば、ＭＦＰブラウザを用いて、表示画面を表示する。ＰＣ１０３は、ブラウザ上でＡｊａｘなどの非同期通信を利用可能とする。ＰＣ１０３は、表示画面の表示データに対しリクエストが発生した場合に、サーバと非同期通信を行って表示データを取得することが可能である。
【００２０】
携帯端末１０５は、ＰＣ１０３同様、ブラウザ上でＡｊａｘを利用可能とする。ＭＦＰ１０７は、ＭＦＰ１０７専用のアプリケーションからＡＰＩを利用して表示画面の表示データを取得する。
【００２１】
サーバ１１０は、各装置１０１、１０３、１０５、１０７から表示画面の表示要求を受けると、各装置に適した表示画面を構成する画面情報（ＨＴＭＬ形式）を送信する。具体的には、サーバ１１０は、カスタマイズ部１１１、画面制御部１１３、インタフェース部１１５、テンプレート管理部１１７、メタデータ管理部１１９、画面データ管理部１２１、アクセス管理部１２３を有する。
【００２２】
カスタマイズ部１１１は、ファイルやフォルダに対するアクセス権限や、ファイルやフォルダに付与されるメタデータや、表示画面のレイアウト、ＵＩパーツなどのカスタマイズを行う。ファイルとは、例えば文書ファイル（画像ファイルも含む）であり、音声ファイルや映像ファイルなどでもよい。
【００２３】
画面制御部１１３は、各装置１０１、１０３、１０５、１０７から表示画面の描画要求や表示データの取得要求を受ける。画面制御部１１３は、要求を受けた装置に適した表示画面を定義する画面情報（例えばＨＴＭＬ形式の情報）を作成し、作成した画面情報を装置に送信する。つまり、画面制御部１１３は、各装置に適した表示画面の表示制御を行う。
【００２４】
インタフェース部１１５は、例えばＪＳＯＮ（JavaScript（登録商標） Object Notation）形式やＸＭＬ(Extensible Markup Language）形式、ＷｅｂＤＡＶ（Web-based Distributed Authoring and Versioning）に対応している。各装置は、インタフェース部１１５のＡＰＩを利用して所望のデータを取得する。
【００２５】
テンプレート管理部１１７は、ファイルやフォルダのメタデータのフォーマットや、表示画面のテンプレートを記憶、管理する。
【００２６】
メタデータ管理部１１９は、フォルダ階層の定義を示す「Cabinets」、フォルダの情報を示す「Folders」、ファイルの情報を示す「Entries」、メタデータの定義を示す「Tags」を保持する。メタデータ管理部１１９で管理される情報については後述する。
【００２７】
画面データ管理部１２１は、各装置１０１、１０３、１０５、１０７で表示される表示画面に関する情報を管理する。「Smart View」は、Ａｊａｘを利用して表示画面を表示可能な装置に対する表示画面の画面情報である。「View Set」は、１又は複数の表示画面をグループ化する画面の画面情報である。「MFP View」は、Ａｊａｘを利用できない装置（例えばＭＦＰ）に対する表示画面の画面情報である。「Mobile View」は、携帯端末用の表示画面の画面情報である。
【００２８】
アクセス管理部１２３は、ファイル階層（「Cabinets」）、フォルダ（「Folders」）、ファイル（「Entries」）、及び／又はビュー（「View」：画面）に対するアクセスを制限するための情報を管理する。
【００２９】
サーバ１３１は、各フォルダに保存されるファイルを簡易的に保持、管理するサーバである。サーバ１３１は、ファイルの保存先のＵＲＬなどを記憶する記憶部（「Storage Cache」）やファイルを取得する取得部（API）を有する。ＤＢ１３２は、各装置の表示画面の定義データやＵＩ部品の定義データなどを記憶するデータベースである。ＤＢ１３３、ファイルを少なくとも記憶するデータベースである。なお、サーバ１３１、ＤＢ１３３は、サーバ１１０に含まれていてもよいし、一つのＤＢであってもよい。その他、ユーザ情報を管理するユーザ情報管理部などがあってもよい。
【００３０】
次に、実施例におけるサーバのハードウェア構成について説明する。図２は、実施例におけるサーバ１１０のハードウェア構成の一例を示すブロック図である。図２に示すように、サーバ１０７は、制御部２０１、主記憶部２０３、補助記憶部２０５、外部記憶装置Ｉ／Ｆ部２０７、ネットワークＩ／Ｆ部２１１を含む。
【００３１】
制御部２０１は、コンピュータの中で、各装置の制御やデータの演算、加工を行うＣＰＵである。また、制御部２０１は、主記憶部２０３に記憶されたプログラムを実行する演算装置であり、入力装置や記憶装置からデータを受け取り、演算、加工した上で、出力装置や記憶装置に出力する。
【００３２】
主記憶部２０３は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）などであり、制御部２０１が実行する基本ソフトウェアであるＯＳやアプリケーションソフトウェアなどのプログラムやデータを記憶又は一時保存する記憶装置である。
【００３３】
補助記憶部２０５は、ＨＤＤ（Hard Disk Drive）などであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。補助記憶部２０５は、ネットワークを介して所定のプログラムを記憶してもよい。この所定のプログラムは、インストールされることで処理可能になる。
【００３４】
外部記憶装置Ｉ／Ｆ部２０７は、ＵＳＢ（Universal Serial Bus）などのデータ伝送路を介して接続された記憶媒体２０９（例えば、フラッシュメモリ、SDカードなど）とサーバ１０７とのインタフェースである。
【００３５】
また、記憶媒体２０９に、所定のプログラムを格納し、この記憶媒体２０９に格納されたプログラムは外部記憶装置Ｉ／Ｆ部２０７を介してサーバ１０７にインストールされ、インストールされた所定のプログラムはサーバ１０７により実行可能となる。
【００３６】
ネットワークI/F部２１１は、有線及び／又は無線回線などのデータ伝送路により構築されたＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などのネットワークを介して接続された通信機能を有する周辺機器とサーバ１０７とのインタフェースである。
【００３７】
なお、サーバ１０７は、入力部や表示部を備えてもよい。入力部は、カーソルキー、数字入力及び各種機能キー等を備えたキーボード、表示部の表示画面上でキーの選択等を行うためのマウスやスライスパット等を有する。また、入力部は、ユーザが制御部２０１に操作指示を与えたり、データを入力したりするためのユーザインタフェースである。
【００３８】
表示部は、ＣＲＴやＬＣＤ等により構成され、制御部２０１から入力される表示データに応じた表示が行われる。
【００３９】
＜機能＞
図３は、実施例におけるサーバ１１０の機能の一例を示すブロック図である。図３に示す例では、サーバ１１０は、受信手段３０１、送信手段３０３、画面生成手段３０５、ユーザ認証手段３１１、アクセス制御手段３１３を含む。受信手段３０１、送信手段３０３は、ネットワークＩ／Ｆ部２１１により実現され、画面生成手段３０５、ユーザ認証手段３１１、アクセス制御手段３１３は、制御部２０１や主記憶部３０３により実現されうる。また、画面生成手段３０５は、画面制御部１１３に相当し、アクセス制御手段３１３は、アクセス管理部１２３に相当する。
【００４０】
受信手段３０１は、各装置から表示画面の表示要求を受けたり、ＵＩ部品に表示する表示データの取得要求を受けたりする。送信手段３０３は、リクエストをしていた装置に対して、画面情報、又は表示データを送信する。表示画面の表示要求は、例えば表示画面の識別情報を指示したり、表示画面の情報が保持されたＵＲＬを指示したりして行われる。
【００４１】
画面生成手段３０５は、第１生成手段３０７、第２生成手段３０９を有する。第１生成手段３０７は、非同期通信、例えばＡｊａｘが利用可能なブラウザを有する装置からの画面表示要求を受けた場合、表示画面を描画する第１画面情報を例えばＨＴＭＬ形式で生成する。生成された第１画面情報は、送信手段３０３により表示要求をした装置に送信される。第１画面情報は、表示要求を受けた表示画面のＵＩ定義データ、このＵＩ定義データに含まれるＵＩ部品に表示する表示データを非同期通信で取得するためのプログラム、例えばJavaScript（登録商標）プログラムを含む。ＵＩ定義データとは、表示画面のＵＩのレイアウトやＵＩ部品などを定義するデータである。
【００４２】
第２生成手段３０９は、シンプルなＨＴＭＬを用いてレンダリングを行う画像形成装置からの画面表示要求を受けた場合、表示画面を描画する第２画面情報を例えばＨＴＭＬ形式で生成する。生成された第２画面情報は、送信手段３０３により表示要求をした装置に送信される。第２生成手段３０９は、表示要求を受けた表示画面のＵＩ定義データに含まれるＵＩ部品に表示する表示データを、レンダリング関数を用いて取得し、取得したＵＩ部品に含まれる表示データを含む表示画面を描画する第２画面情報を生成する。
【００４３】
表示要求をした装置が非同期通信可能か否かの判断について、画面生成手段３０５は、装置の識別情報（例えばIPアドレス）と非同期通信の可否とを関連付けて記憶しておき、表示要求をした装置の識別情報に応じて非同期通信可か否かを判断すればよい。
【００４４】
また、ＭＦＰブラウザでＡｊａｘを利用可能な場合でも、レンダリング速度や画面サイズの問題から、第２生成手段３０９によりＭＦＰ用にレンダリングすることが考えられる。このとき、画面生成手段３０５は、表示要求をした装置のIPアドレスを用いて装置判定を行い、IPアドレスが情報処理装置（ＰＣ）１０３を示せば第１生成手段、ＭＦＰ１０１を示せば第２生成手段を用いて画面生成を行う。
【００４５】
ユーザ認証手段３１１は、各装置からユーザＩＤとパスワードを取得してユーザ認証を行なう。認証されたユーザに関する情報は、アクセス制御手段３１３に出力される。ユーザに関する情報とは、ユーザＩＤ、ユーザ名、ユーザが属する組織情報などを含むユーザ情報、又はユーザ情報に付与されるメタデータの少なくとも１つを含む。
【００４６】
アクセス制御手段３１３は、ログインされたユーザに対して、表示画面（ビュー）に対しアクセス制限を加え、表示可能な表示画面を制限する。アクセス制限の詳細は後述する。
【００４７】
（モデルのクラス関係）
次に、実施例で用いるデータモデルについて説明する。図４は、実施例で用いるデータモデルのクラス関係の一例を示す図である。「Organization」クラス４０１は、組織ID「rs_organization_id（単にorganization_idでもよい）」を有するクラスである。
【００４８】
「Cabinets」クラス４０９、「Folder」クラス４１１、「Entry」（ファイル）クラス４１３、「Tag」クラス４１５、「Doctype」クラス４１７は、ユーザが実際に利用するファイルやフォルダのクラスである。
【００４９】
「ContentFilter」クラス４１９、「ViewFiler」クラス４２１は、ファイルやビューに対しアクセス権を設定するためのクラスである。「SmartView」クラス４２３、「ViewSet」クラス４２５は、フォルダやファイルを業務内容に近い形式で表示するＵＩの設定を行うためのクラスである。「User」クラス４２７は、ユーザ情報を設定するためのクラスである。なお、二重で囲んだクラスは、ユーザ管理者による設定ができるクラスである。
【００５０】
（ＵＩの定義）
図５は、ＵＩの定義データの一例を示す図である。図５に示す「Rs Organization」は、組織ＩＤを示す。「Config」５０１は、ＵＩ定義データの一例を示す。ＵＩ定義データには、表示画面に表示される各ＵＩ部品が定義される。
【００５１】
例えば、ライン５１１は、ＵＩ部品の識別情報を示し、「inv_no_search」が定義されている。ライン５１３は、ＵＩ部品のコンポーネントを示し、「search_box」が定義されている。
【００５２】
ライン５１５では、ＵＩ部品とＵＩ部品にデータを表示する場合の関連付けが行われ、所定のＵＲＬにリクエストを送ると、検索結果に含まれるデータが返ってくることを示す。ライン５１７は、所定の表示領域を示し、「tab_left」が定義されている。ライン５１９は、表示データを検索する際の検索キーを示し、「stag_14」の検索キーが定義される。ライン５２１は、このＵＩ部品が表示される場合の名称が定義される。なお、図５に示すデータは、例えばＤＢ１３２に保存される。
【００５３】
図６は、表示画面の一部の一例を示す図である。図６は、図５に示すＵＩ定義データを表示した場合の例である。図６に示すタイトル６０１は、図５に示すライン５２１の「INV番号検索」が表示されたものである。また、サーチボックス６０３は、ライン５１３のＵＩ部品が表示されたものである。なお、実施例で用いるＵＩ定義データは、図５に示すライン５１１〜５２１のＵＩ部品に関するデータを記述するだけで、図６に示すタイトル６０１及びサーチボックス６０３が表示される。これにより、ＵＩのカスタマイズが容易である。なお、図６に示す画面は、例えば、第１生成手段３０５が図５に示すＵＩ定義データに基づいて第１画面情報を生成することで、ＰＣ１０３で表示可能になる。
【００５４】
（画面構成）
次に、実施例で用いる表示画面の構成について説明する。図７は、表示画面の一例を示す図である。図７に示す実線枠はペイン（pane：所定の表示領域）を示し、点線枠はパーツ（parts：ＵＩ部品）を示す。ペイン内には、１又は複数のパーツが定義される。ただし、ロゴなどの操作イベントが発生しないパーツ７１１は、ペイン内に定義しなくてもよい。ペイン７０１は、「tab_left」ペインであり、ペイン７０３は、「tab_main_top」ペインであり、ペイン７０５は、「tab_main_bottom」ペインである。
【００５５】
ペイン７０１には、セレクトボックス７１３、サーチボックス７１５などのパーツが定義されている。ペイン７０３には、ドキュメントリスト７１７のパーツが定義されている。ペイン７０５には、ドキュメントリスト７１９のパーツが定義されている。
【００５６】
次に、ペインとパーツを含む画面におけるパーツの連携について説明する。図８は、表示画面のパーツの連携を説明する図である。
（１）「Config」に定義されたbindingsをもとに、どこのペインのパラメータ変更イベントを受けるかを調べ、自ペインに再描画のための関数をbindする。
（２）bindingsの対象になったペイン内のセレクトボックスによりセレクトされた時、自分の属するペインから「pane.event_name」という名前のイベントにtriggerをかける。
（３）かかったtriggerイベントに対応するbindを実行する。
（４）bindから呼ばれた再描画関数が自ペインを再描画する。
【００５７】
なお、パラメータ変更などのイベント自体は、各パーツ単位で発生する。しかし、パーツでイベントが発生すると、ペイン名に対応付けてトリガーがかけれらるため、イベント通知を受ける側（bindされる関数）は、あらかじめ、ペインに対してbindされることになる。イベント発生は、ペイン単位で検知される。bindingsは、ペインに対して行われる。bindingするイベントは、ＵＩ部品の識別情報（div_id名）ではなく、ペイン名＋データ名である。例えば、「tab_left.layer_0（ペイン名.データ名）」である。図８に示す画面例に対し、新たにＵＩ部品を加えたい場合、ペイン内部にパーツを追加できればパーツを追加してもよいし、ペインを追加して追加したペイン内部にパーツを定義してもよい。
【００５８】
図８に示すようなパーツ連携を採用することより、他のペイン内で操作イベントが発生した場合、自ペイン内のパーツを再描画する。したがって、画面の設計者は、パーツ毎に対応付けをしなくてもよくなる。また、この対応付けによる設定の数を減らすこともできる。
【００５９】
図９は、イベントによる駆動プログラムの一例を示す図である。図９は、図８の（１）、（３）に対応するプログラムの例である。図９に示す関数は、イベントによる駆動を設定する関数である。また、「ペイン名＋データ名」のイベントの発生が起きたら他の関数を呼ぶ設定が、JavaScript（登録商標）内で行われる。「target.on_change()」は、bindが実行されたときに呼ばれる関数である。
【００６０】
図１０は、イベント発生のプログラムの一例を示す図である。図１０は、図８の（２）に対応するプログラムである。図１０に示す関数は、ＵＩ部品内でイベントを発生させる関数である。ライン１００１で、「ペイン名＋データ名」のイベントを発生させている。関数１００３は、ＤＯＭ（Document Object Model）内の変数ペインに値をセットする関数である。これにより、ＵＩ部品に操作イベントが発生したときに、所属するペインからtriggerを発生させることができる。なお、図９及び図１０に示すJavaScript（登録商標）のソースは、jqueryというライブラリの利用を前提とするが、この限りではない。
【００６１】
図１１は、ＵＩ部品を描画するときのＵＲＬを生成するプログラムの一例を示す図である。図１１は、図８の（４）に対応するプログラムである。図１１に示す関数は、ブラウザがパーツを描画するときのＵＲＬを生成する関数である。ここでは、図９の「set_param」でＤＯＭ内の「panes」に設定された値を取得して、ＵＲＬのパラメータにセットする。図９〜図１０に示すデータは、ＤＢ１３２に保存される。
【００６２】
（ＵＩパーツの設定）
次に、ＵＩパーツ（ＵＩ部品）の設定例について説明する。図１２は、セレクトボックスの定義データの一例を示す図である。図１２のライン１２０１に示す「div_id」は、ＵＩパーツのＩＤであり、ＩＤは、「layer_1_select」の例を示す。ライン１２０３に示す「component」は、利用するＵＩ部品名である。この例では、ＵＩ部品名は「select_box」の例を示す。ライン１２０５に示す「relative_url」は、データを取得するＡＰＩのＵＲＬである。
【００６３】
ライン１２０７に示す「display_fields」は、セレクトボックスに表示するデータの中のフィールド名である。ライン１２０９に示す「value_fields」は、セレクトボックスが変更されたときに、ペインに設定される値のデータのフィールドである。ライン１２１０に示す「pane」は、このＵＩパーツが属するペインである。この例では、属するペインは「tab_left」の例を示す。ライン１２１１は、ペインの値としてセットするときの名前であり、「layer_1」の例を示す。
【００６４】
図１３は、セレクトボックスの一例を示す図である。図１３では、フォルダ階層を選択するためのセレクトボックスの一例を示す。例えば、「時期」は第１階層であり、「HAWB番号検索」は第２階層である。このフォルダ階層については後述する。
【００６５】
図１３に示す１３０１のセレクトボックスは、図１２に示すＵＩパーツがブラウザを用いて表示されたときの例である。例えば、セレクトボックスのプルダウンボタンが押下された場合には、ＰＣ１０３は、例えばＡｊａｘを利用し、ライン１２０５のＡＰＩのＵＲＬにより取得された「layer_1」内のデータを表示する。
【００６６】
図１４は、ＡＰＩで取得されたデータの一例を示す図である。例えば、データ１４０１に示す「2009.11」、「2009.12」、「2010.01」、「2010.02」を取得したとする。このとき、図１３に示すブルダウンボタンが押下されると、データ１４０１内の「2009.11」、「2009.12」、「2010.01」、「2010.02」が画面に表示されることになる。なお、「layer＝layer_1」と「level＝１」は同じ第１階層のフォルダを示す。
【００６７】
次に、他のＵＩパーツの設定例について説明する。図１５は、フォルダリストの定義データの一例を示す図である。図１５に示す例では、フォルダリストの表示、また、セレクトボックスの変更を受けて、リストが再描画される設定を含む。変数１５０１は、「tab_left」のペインで「layer_0」〜「stag_15」のイベントが発生したときにそのイベントによって再描画を行なう関連付けを行う変数である。変数１５０１の情報をもとに、図９に示す関数によって、イベントに再描画用の関数が紐付けられ、図１１に示すURL生成で検索パラメータが生成される。
【００６８】
図１６は、フォルダリストの一例を示す図である。図１６に示すフォルダリスト１６０１は、図１５に示すＵＩパーツの定義データを表示した例である。例えば、左のセレクトボックス内でデータがセレクトされると、それに応じて図１６に示すフォルダリストが再描画される。
【００６９】
（レンダリング）
次に、上記のＵＩ定義データ、画面構成などを用いて、ＰＣ１０３でのレンダリングと、ＭＦＰ１０１でのレンダリングとについての概略を説明する。図１７は、レンダリングの例を説明する図である。図１７（Ａ）は、ＰＣ１０３でのレンダリングの概略を示す。
【００７０】
まず、ＰＣ１０３は表示画面の表示要求を行う。表示要求には、表示画面を示す識別情報や要求元のＩＰアドレス、ＰＣ１０３にログインしたユーザの情報などが含まれる。
【００７１】
サーバ１１０の受信手段３０１は、ＰＣ１０３から表示要求を受けると、画面生成手段３０５に表示要求を出力する。画面生成手段３０５は、ユーザの情報及び表示画面の識別情報等により、どのＵＩ定義データを用いればよいかを判断する。また、画面生成手段３０５は、ＩＰアドレスなどから第１生成手段３０７、第２生成手段３０９のどちらを用いるかを決定する。ここで、ＰＣ１０３は、非同期通信に対応しているＡｊａｘを利用することができるとする。
【００７２】
第１生成手段３０７は、表示画面のＵＩ定義データを取得し、取得したＵＩ定義データと、ＵＩ定義データに含まれるＵＩ部品の情報と、Ａｊａｘを利用するJavaScript（登録商標）のプログラムとを含む第１画面情報をＨＴＭＬ形式で生成する。第１生成手段３０７は、生成した第１画面情報を、送信手段３０３を介してＰＣ１０３に送信する。
【００７３】
ＰＣ１０３は、受信したＨＴＭＬ形式の第１画面情報に含まれるJavaScript（登録商標）のプログラムを実行し、ＵＩ部品の情報を利用してＵＩ部品をＨＴＭＬのＤＯＭ上に追加する。ＰＣ１０３は、ブラウザ上でJavaScript（登録商標）によって各ＵＩ部品のレンダリングを行う。例えば、表示データが必要なＵＩ部品の場合、ＰＣ１０３は、初期描画時や他のＵＩ部品の値（表示データ）が変更になったというイベントが発生した時にＡｊａｘを利用してＡＰＩからデータを取得する。
【００７４】
サーバ１１０の第１生成手段３０７は、ＰＣ１０３からのデータ取得要求に対して、リクエストされたＵＲＬやパラメータ（メタデータや階層など）を参照して、ＰＣ１０３が必要とするデータをＤＢ１３２から検索し、ＪＳＯＮ形式で応答データを生成する。
【００７５】
ＰＣ１０３は、ＪＳＯＮ形式で応答データを取得すると、取得したデータをＵＩ部品に表示するよう描画処理を行う。なお、複数のＵＩ部品で表示データが必要な場合は、各ＵＩ部品で非同期にデータを取得できる。ＰＣ１０３は、上記のＡＰＩを利用し、表示データを取得して描画することを繰り返す。
【００７６】
図１７（Ｂ）は、ＭＦＰ１０１でのレンダリングの概略を示す。まず、ＭＦＰ１０１は、表示画面の表示要求を行う。表示要求には、表示画面を示す識別情報や要求元のIPアドレス、ＭＦＰ１０１を利用しているユーザの情報などが含まれる。
【００７７】
サーバ１１０の受信手段３０１は、ＭＦＰ１１０から表示要求を受けると、画面生成手段３０５に表示要求を出力する。画面生成手段３０５は、ユーザの情報及び表示画面の識別情報により、どのＵＩ定義データを用いればよいかを判断する。また、画面生成手段３０５は、非同期通信に対応していないＭＦＰ１０１からの要求であるため、第２生成手段３０９を用いることを決定する。
【００７８】
第２生成手段３０９は、表示画面のＵＩ定義データに含まれるＵＩ部品の定義情報をもとにレンダリング関数を呼び出して、各ＵＩ部品に表示する表示データを取得する。第２生成手段３０９は、ＵＩ定義データとパラメータ（メタデータや階層など）を用いて表示データを検索し、表示データを表示するＵＩパーツを含む画面の第２画面情報をＨＴＭＬ形式で生成する。このとき、画面生成手段３０９は、１ページ分のＨＴＭＬ（第２画面情報）をＭＦＰ１０１に送信する。ＭＦＰ１０１は、取得したＨＴＭＬを用いて表示画面を描画する。
【００７９】
また、表示しているＵＩ部品の表示データが変更された場合、他のＵＩ部品の再描画が必要であれば、ＭＦＰ１０１は、サーバ１１０に対し、再度表示要求を行う。サーバ１１０は、再度表示要求を受けた場合、前述した処理と同様にして１ページ分のＨＴＭＬ形式の第３の画面情報をＭＦＰ１０１に送信する。
【００８０】
ここで、ビュー（タブ）設定の例について説明する。実施例では、各装置はタブを用いてビューを切り替えることも可能である。図１８は、ＰＣ用のタブ設定の一例を示す図である。図１８は、「文書リスト」を表示する簡単なビューの例を示す。図１８に示すように、枠１８０１で、このビューに表示するデータを取得するデータのＵＲＬを指定する。ここでは、「cabinets/A_project/entries.json」に保存されているデータを取得することを意味する。また、「pane」は、どこのペインに属するかを示す。「per_page」は、１ページに表示するデータ数を示す。この例では、１ページに１０個のドキュメントが表示されることを意味する。
【００８１】
図１９は、ＭＦＰ用のビュー設定の一例を示す図である。図１９に示す枠１９０１で、取得する表示データの種類を指定する。図１９に示す例では、「A_project」というフォルダに保存されているファイル（「entries」）を取得する。枠１９０３では、取得する表示データの条件を指定する。図１９に示す例では、１ページに５つのファイルを表示することを意味する。
【００８２】
次に、ＨＴＭＬソースと表示画面との関係について説明する。図２０は、ＰＣ用のＨＴＭＬソースの一例を示す図である。図２０に示す枠２００１では、JavaScript（登録商標）のプログラムの読み込みを行う。枠２００３では、ＵＩ部品の表示データの埋め込みを行う。ライン２００５などでは、ログアウトボタンなど共通の部分が定義される。ライン２００７などでは、タブの切替を行う部分である。枠２００９では、実際にＵＩ部品が設置されるＤＩＶ要素が定義される。第１生成手段３０７は、例えば図２０に示す画面情報を生成し、ＰＣ１０３に送信する指示を出す。ＰＣ１０３は、図２０に示すような画面情報を受信し、受信した画面情報に基づいて表示画面を描画する。図２０に示す画面情報は、第１生成手段３０７により生成される。ＰＣ１０３は、図２０に示すような画面情報を受信し、受信した画面情報に基づいて表示画面を描画する。
【００８３】
図２１は、ＰＣ用の画面の一例を示す図である。図２１は、図２０に示す画面情報を描画した例を示す。図２１に示す画面には、図２０に示す枠２００３の「title」の「文書リスト」が表示され、「disp_fields」の「文書名」、「Size」、「更新日時」が順に表示される。また、枠２００３の「per_page」の通り、最大「１０」個のファイルが１ページに表示される。
【００８４】
次に、図２２は、ＭＦＰ用のＨＴＭＬソースの一例を示す図である。図２２に示す枠２２０１は、印刷ボタン用のＭＦＰ特有のJavaScript（登録商標）が記載されている。枠２２０３は、ＨＴＭＬに埋め込まれたファイルのリストを表す。つまり、図１９に示す枠１９０１により取得された文書が、枠１９０３の条件に従って図２２に示す枠２２０３内に埋め込まれている例である。第２生成手段３０９は、例えば図２２に示す画面情報を生成し、ＭＦＰ１０１に送信する指示を出す。ＭＦＰ１０１は、図２２に示すような画面情報を受信し、受信した画面情報に基づいて表示画面を描画する。
【００８５】
図２３は、ＭＦＰ用の画面の一例を示す図である。図２３は、図２２に示す画面情報を描画した例を示す。図２３に示す画面には、図２２に示す枠２２０３内の「Title」と「Size」とボタンとが表示される。また、図１９の枠１９０３に示す通り、１ページには最大５つのファイルが表示される。
【００８６】
次に、ＰＣ１０３が、ＡＰＩを利用して表示データを取得する例について説明する。図２４は、ＪＳＯＮデータの取得とＵＩ部品の描画の一例を示す図である。ＰＣ１０３は、図２４の下部のＪＳＯＮ形式のＵＲＬから取得してきた表示データを、ブラウザ上でＡｊａｘを利用して描画する。図２４に示す例では、ＵＲＬが示す位置に格納されているファイルを表示する。このように、実施例におけるＰＣ１０３は、セレクトボックスでデータが選択されると、Ａｊａｘを利用してＪＳＯＮ形式で表示データを取得し、表示画面を再描画する。
【００８７】
＜動作＞
次に、画面制御システム１００の動作について説明する。図２５は、ログインの一例を示すシーケンス図である。図２５に示すステップＳ１０１で、ＰＣ１０３は、ブラウザを用いてサーバ１１０に対し、ページリクエストを行う。
【００８８】
ステップＳ１０２で、サーバ１１０は、ログイン用のチケットがリクエストに含まれていないため、ユーザ管理サーバにリダイレクトする。ステップＳ１０３で、ユーザ管理サーバは、ログイン画面をＰＣ１０３に送信する。
【００８９】
ステップＳ１０４で、ＰＣ１０３は、ログインするための情報をユーザ管理サーバに送信する。ログインするための情報とは、組織情報、ユーザ情報、パスワードなどである。
【００９０】
ステップＳ１０５で、ユーザ管理サーバは、認証が成功すると、ログイン用のチケットをＰＣ１０３に送信するとともに、サーバ１１０へのリダイレクトを行うようＰＣ１０３に指示する。
【００９１】
ステップＳ１０６で、ＰＣ１０３は、ログイン用のチケットとともにページリクエストをサーバ１１０に対して行う。ステップＳ１０７で、サーバ１１０は、ログイン用のチケットを確認し、リクエストされたページのＨＴＭＬソース（図２０参照）をＰＣ１０３に送信する。ブラウザによる描画処理は図２６を用いて説明する。なお、ユーザ管理サーバは、サーバ１１０に含まれる構成であってもよい。
【００９２】
図２６は、画面の描画処理の一例を示すシーケンス図である。図２６に示すステップＳ２０１で、ＰＣ１０３は、ログイン用のチケットを含むページリクエストをサーバに１１０に行う。
【００９３】
ステップＳ２０２で、サーバ１１０は、リクエストされたページのＨＴＭＬソースをＰＣ１０３に送信する。ＨＴＭＬソースには、ペインやＵＩの定義データを含む。
【００９４】
ステップＳ２０３で、ＰＣ１０３は、ＨＴＭＬソースのヘッダ内に記載されているＣＳＳ（Cascading Style Sheets）、JavaScript（登録商標）をサーバ１１０に要求する。
【００９５】
ステップＳ２０４で、サーバ１１０は、要求されたＣＳＳ、JavaScript（登録商標）をＰＣ１０３に送信する。ステップＳ２０５で、ＰＣ１０３は、取得したＨＴＭＬソースやＣＳＳ、JavaScript（登録商標）に基づき、画面のレンダリングが行われる。ＵＩ部品は初期化され、ＵＩ部品が描画されていく。このとき、複数のＵＩ部品がある場合、Ａｊａｘを利用して非同期に描画が実行される。
【００９６】
ステップＳ２０６で、ＰＣ１０３は、ＵＩ部品に表示データがある場合（例えば、ＵＲＬが記述されている場合）、サーバ１１０に対し、ＵＩ部品用の表示データを要求する。ステップＳ２０７で、サーバ１１０は、要求された表示データをＪＳＯＮ形式のデータで生成し、ＰＣ１０３に送信する。
【００９７】
ＰＣ１０３は、サーバ１１０からＪＳＯＮデータを取得すると、JavaScript（登録商標）を実行し、画面の再描画を行なう。
【００９８】
以上の構成により、サーバ１１０は、ページリクエストをした装置が非同期通信に対応しているか否かで画面情報の生成方法を変更し、各装置に適した画面情報をＨＴＭＬ形式で生成することができる。
【００９９】
＜ＤＢの構造＞
次に、ＤＢ１３２に保存されるデータのデータ構造の一例を説明する。以下、説明するＤＢ１３２のデータ構造は、フォルダ階層になっており、階層に意味を持たせる。さらに、各階層のフォルダに付与され、階層の意味に関連するメタデータを付与してもよい。
【０１００】
このデータ構造を用いることで、サーバ１１０は、個々の業務に合わせてＵＩのカスタマイズをしたり、ビューのアクセス制限をしたりすることが容易になる。
【０１０１】
図２７は、フォルダ階層の概要を説明する図である。図２７に示すように、フォルダ階層の定義を「キャビネット（cabinet）」とし、キャビネット毎に階層の定義付けを行う。例えば、第１階層を「顧客」とし、第２階層を「図面番号」とし、第３階層を「案件」とする。また、各階層のフォルダには、階層の定義に関連するメタデータを付与することもできる。例えば、第１階層のフォルダに、「顧客」に関連するメタデータとして「業種」、「地区」を付与し、第２階層のフィルダに、「図面番号」に関連するメタデータとして「製品種別」、「材料」を付与し、第３階層のフォルダに、「案件」に関連するメタデータとして「案件状態」、「納期」、「個数」を付与する。
【０１０２】
各フォルダには、文書ファイル（ドキュメント）が保存される。また、文書ファイルには、文書タイプが付与され、さらにメタデータを付与することも可能である。例えば、文書タイプ「見積書」の文書ファイルには、「文書状態」、「送付状態」のメタデータを付与する。
【０１０３】
また、キャビネット毎に異なる階層の定義を行うこともできる。さらに、契約アカウント毎に、異なるキャビネットを有することもできる。また、階層毎にＵＩ部品を定義しておくことで、階層に応じた表示画面を生成しやすくする。
【０１０４】
次に、フォルダ階層に関するデータについて説明する。図２８は、フォルダ階層に関するデータのデータ構造の一例を示す図である。図２８（Ａ）は、フォルダ定義情報の一例を示す図である。
【０１０５】
図２８（Ａ）に示す例では、フォルダ定義情報は、フォルダ定義情報の識別子２８００、組織ＩＤ２８０１、フォルダ階層のタイトル、フォルダ階層の定義２８０２、各階層のフォルダに付与され、階層の定義に関連するメタデータの定義２８０３、ファイルに付与されるメタデータの定義２８０４、フォルダに付与されるメタデータ２８０５、ファイルに付与されるメタデータ２８０６などを含む。
【０１０６】
フォルダ階層の定義２８０２は、各階層にフォルダの定義がなされ、各階層に意味を持たせる。例えば、フォルダ定義情報「２」では、階層１（layer_0）に「部署名」、階層２（layer_1）に「営業担当者」、階層３（layer_2）に「顧客名」、階層４（layer_3）に「案件名」が定義されている。
【０１０７】
フォルダに付与されるメタデータの定義２８０３は、各階層に付与され、階層の定義に関連するメタデータが定義される。例えば、図２８（Ａ）に示す例では、階層４に「stag_0」が付与されている。「stag_0」は、「処理状態」を示す。これは、階層４のフォルダには、処理状態（例えば、未処理、処理済み）を示すメタデータが付与されることを意味する。
【０１０８】
ファイルに付与されるメタデータの定義２８０４は、フォルダに保存されるファイルに付与されるメタデータを定義する。例えば、図２８（Ａ）に示す例では、「e_stag_0」がファイルに付与されている。「e_stag_0」は、「文書タイプ」を示すメタデータである。これは、ファイルには、文書タイプ（例えば、見積書、注文書など）を示すメタデータが付与されることを意味する。
【０１０９】
メタデータには、文字列を示すメタデータ「stag（string-tag）」と年月日を示すメタデータ「dtag（data-tag）」などがある。メタデータは、他にも「ntag（number-tag）」や「btag（boolean-tag）」などがあってもよい。また、フォルダに付与されるメタデータと、ファイルに付与されるメタデータとは識別可能である。なお、フォルダに付与されるメタデータは、そのフォルダに保存されるファイルに対応付けられる。
【０１１０】
図２８（Ｂ）は、フォルダ情報の一例を示す図である。フォルダ情報は、フォルダ毎に、フォルダＩＤ２８２０、組織ＩＤ２８０１、フォルダ定義情報の識別子２８００、親フォルダの識別子２８０２１、どの階層かを示すレベル２８２２、各階層の定義に対応するデータ２８２３、フォルダに付与されるメタデータの定義に対応するメタデータ２８２４などを含む。
【０１１１】
なお、フォルダ情報の各階層は、自階層以上の階層のフォルダ定義に対応するデータを保持してもよい。例えば、階層（level）が「２」のフォルダ情報として、「layer_0」の「東京本社」、「layer_1」の「若本」、「layer_2」の「ＢＢＢ工業」が保持されている。これにより、上位階層のフォルダの定義に対応するデータを取得する際、親フォルダを辿らなくても容易に取得可能となる。また、階層の定義に対応するデータが、その階層のフォルダの名称とされてもよい。
【０１１２】
メタデータ２８２４は、「stag_0」２８０５に対応するデータである。「stag_0」２８０５が「処理状態」を定義しているため、メタデータ２８２４は、処理状態を示すデータとなる。図２８（Ｂ）に示す例では、メタデータ２８２４は、「処理済み」を示す。
【０１１３】
図２８（Ｃ）は、ファイル情報の一例を示す図である。ファイル情報は、ファイルＩＤ２８４０、組織ＩＤ２８０１、どのフォルダに保存されているかを示すフォルダＩＤ２８２０、ファイルのタイトル２８４１、ファイルが格納されている位置を示すＵＲＬ２８４２、ファイルサイズ２８４３、ファイルのメタデータ２８４４などを含む。
【０１１４】
なお、ファイルのメタデータ２８４４は、フォルダのメタデータ２８２４と識別可能である。例えば、ファイルのメタデータ２８４４には、「e_stag」というように、ファイルのメタデータを示す「e_」が付与されている。これにより、フォルダのメタデータとファイルのメタデータとを区別して管理、検索などをすることができる。
【０１１５】
図２８に示すデータ構造を有することで、フォルダ階層に意味を持たせ、その階層のフォルダにメタデータを付与してファイルを管理することができる。サーバ１１０は、階層毎にＵＩ部品を定義することで、階層に沿った形式でのＵＩのカスタマイズなどが可能になる。ユーザは業務内容に合わせてフォルダ階層を生成する場合が多いので、階層に沿った形でＵＩがカスタマイズされると、業務に連動したＵＩが生成されることになる。
【０１１６】
次に、階層の定義とメタデータの例について説明する。図２９は、階層の定義とメタデータの一例を示す図である。図２９（Ａ）は、階層の定義を示す図である。図２９（Ａ）に示す例では、第１階層は「部署名」、第２階層は「営業担当者」、第３階層は「顧客名」、第４階層「案件名」が階層に定義づけられている。図２９（Ｂ）は、各階層のフォルダに付与されるメタデータの定義を示す図である。図２９（Ｂ）に示す例では、第４階層のフォルダには、「状態」がメタデータとして定義付けられている。なお、第１階層のフォルダには、「所在地」、第３階層のフォルダには、「業種」などのメタデータが定義付けられてもよい。
【０１１７】
図３０は、図２８に示すデータの画面例を示す図である。表示画面３００１は、領域３００３と領域３００５を含む。領域３００３は、フォルダ定義情報及びフォルダ情報から記述されるフォルダ構成が描画される。領域３００３のフォルダ構成は、図２８（Ａ）に示すフォルダ定義情報の識別情報「２」のフォルダ構成である。
【０１１８】
例えば、図３０の領域３００３に示すように、東京本社（第１階層）、若本（第２階層）、ＢＢＢ工業（第３階層）、計測器部品受注（第４階層）が階層順に描画される。領域３００３に示すフォルダ構成は、第３階層までの例である。
【０１１９】
図３０の領域３００５は、ファイル情報から記述されるファイル構成が描画される。図２８（Ｃ）を参照すると、フォルダＩＤ「４」の「計測器部品受注」フォルダには、「見積書.pdf」、「注文書.pdf」、「納品書.pdf」が保存されている。これにより、領域３００５には、「見積書.pdf」、「注文書.pdf」、「納品書.pdf」が描画される。
【０１２０】
図３０に示す画面の場合、第１生成手段３０７は、各フォルダに対し、フォルダの格納位置を示すURLを記述しておく。ＰＣ１０３は、フォルダへのダブルクリックなどでイベントを検出し、ダブルクリックされたフォルダに対応するＵＲＬから表示データを取得し、取得した表示データを領域３００５に再描画する。この場合の表示データは、文書ファイルである。
【０１２１】
（ビュー及びビューセット）
次に、ビュー及びビューセットについて説明する。ビューセットとは、１又は複数のビューがグループ化され、グループ内のビューが切替可能である画面のことをいう。実施例において、サーバ１１０は、ビューセットを定義しておくことで、例えば部署毎に表示可能なビューを容易に切り替えることができる。
【０１２２】
図３１は、ビューセットデータの一例を示す図である。図３１に示すように、ビューセットには、ビューセットＩＤ（id）、組織ＩＤ（organization_id）、タブを表示するためのＵＲＬのパス名（tiltle）、表示用のタブ名（display_name）、ＵＩ部品が定義されている情報（config）、ビューのタイプ（view_type）、スキン（skin）、ビューの順番（view_order）が関連付けられている。
【０１２３】
例えば、ビューセットＩＤ「２」には、ＵＲＬのパス名「factory」、タブ名「工場向け」、ビュータイプ「ＰＣ」、スキン「smoothness」、順番「１、４」が設定されている。「スキン」は、画面の色調などを変更して、ユーザに違いを強調するためのデータである。例えば「smoothness」、「normal」などがある。「smoothness」は、「normal」に比べて明度や彩度を変更し滑らかなイメージを与える色調にする。また、ビューセットの「config」には、ロゴやログアウトボタンなど共通のＵＩ部品が定義されている。「view_order」には、ビューの識別情報が左からの表示順に設定されている。「view_order」の「＊」は、「view_type」が同じ全てのビューを示すと解釈される。
【０１２４】
図３２は、ビュー（タブ）データの一例を示す図である。図３２に示すように、ビューのデータ構造は、ビューセットと同様である。図３２に示す「config」は、一覧を表示するような場合、例えば図１５に示すようなドキュメントリストの定義データが設定される。ここで、図３１に示す「view_order」の「＊」は、「view_type」が同じ「ＰＣ」のビューＩＤ「１，２，３，４」を示すと解釈される。
【０１２５】
図３３は、ビュー形成のためのデータの一例を示す図である。図３３（Ａ）は、図３１に示すようなビューセットデータを形成するために定義されたデータを示す。図３３（Ａ）に示す例では、種類（string、text、datetime、integerなど）に応じてデータが定義されている。例えば、「view_type」は、文字列形式（string）であり、「config」は、テキスト形式（text）であり、「view_order」は、整数形式（integer）である。
【０１２６】
図３３（Ｂ）は、図３２に示すようなビューデータを形成するために定義されたデータを示す。例えば、「display_name」は、文字列形式（string）である。図３３に示すように、各データには、定義された形式でデータが入力される。
【０１２７】
図３４は、ビューのＵＲＬ、ビュー、ビューセットの画面切替例を説明する図である。図３４に示す例では、図３１に示すビューセットのid「２」のビューセットについて説明する。
（１）ビューセットのid「２」のビューセットを表示する場合
ＰＣ１０３は、例えば「https://host_name/APP_name/view/factory」のＵＲＬを表示する場合、ＵＲＬ末尾の「factory」が示すビューセットを表示する。また、ビューセット「factory」は、ビューのid「１」が一番上に表示される。なお、ビューのid「１」は、図３２に示す例によると、「案件一覧」が表示される。
（２）ビューセットのid「２」の二番目のビューを表示する場合
ＰＣ１０３は、例えば「https://host_name/APP_name/view/factory/drawing」のＵＲＬを表示する場合、ＵＲＬ末尾の「drawing」が示すビューを表示する。
（３）ビューセットのid「１」のビューセット（display_name=Default）を表示した場合
ＰＣ１０３は、例えば「https://host_name/APP_name/view/all」のＵＲＬを表示した場合、図３４の下部に示すような画面が表示される。ビューセットのid「１」のビューセットは、「view_type」が「ＰＣ」であるビュー全てを表示可能とする。このとき、ビューのidの番号が一番小さい「１」の「案件一覧」が表示される。また、ユーザが「未回答一覧」のタブを押下すると、ビューのid「２」を表示するため（図３２参照）、ＰＣ１０３のブラウザは、ＵＲＬ「・・・/view/all/to_be_respond」により取得した表示画面を表示する。
【０１２８】
上記のようなビューやビューセットのデータ構造がＤＢ１３２に保存されることで、例えば、同じ会社であっても、ビュー（タブ）毎に「config」を作成し、保存しておくことで、タブ毎に違った見せ方、使い方をすることができる。
【０１２９】
画面生成手段３０５は、ビューセットの表示要求を受けた場合、上記のようなタブのＵＲＬを第１画面情報に含めておくことで、ＰＣ１０３のブラウザはＡｊａｘを利用して各タブを非同期通信により取得することができる。
【０１３０】
図３５は、タブの違いによる画面の違いを説明する図である。図３５（Ａ）は、案件検索用のタブを表示する画面例である。図３５（Ｂ）は、見積り依頼対応用のタブを表示する画面例である。このように、同じ会社であっても、タブによって、違う見せ方（例えばスキン）や違う使い方（コンポーネントの数）をすることができる。
【０１３１】
また、図３１を用いて説明したように、実施例におけるサーバ１１０は、タブの組み合わせをビューのセットとして管理することができる。例えば、営業部向けタブセット、製造部向けタブセット、経理向けタブセットなどである。
【０１３２】
図３６は、ビューセットとタブの関係を示す図である。図３６（Ａ）は、「Advanced」セットであるため、「案件」タブ、「見積り依頼対応」タブ、「製造予定日順」タブの全てが表示可能である。図３６（Ｂ）は、「Simple」セットであるため、「案件」タブしか表示できないし、案件リストについても図３６（Ａ）に比べると項目が少ない。これは、ＵＩ定義データで設定するコンポーネントを少なくすればよい。上記のように、各タブのＵＩ定義データやビューセット画面の定義データなどをＤＢ１３２に保存しておく。
【０１３３】
また、上記例では、ＰＣ１０３用のビューやビューセットの例を示したが、図１７に基づいて、ＭＦＰ１０１からタブの切替要求を受けたサーバ１１０は、切替後のタブ１ページ分のＨＴＭＬを生成して、ＭＦＰ１０１に送信すればよい。よって、ＭＦＰ１０１でもＤＢ１３２に保存されているビューセットの表示は可能である。
【０１３４】
＜ビュー制限＞
図３７は、アカウント情報の一例を示す図である。図４に示す例では、アカウント情報は、ユーザＩＤ３７０１、ログイン名３７０３、パスワード３７０５、ユーザに割り当てられたグループ３７０７が関連付けられている。例えばユーザＩＤ「１」は、ログイン名が「tanabe」である。また、ユーザＩＤ「３」は、ログイン名が「iwata」であり、「managers」グループに属する。
【０１３５】
図３８は、組織情報の一例を示す図である。図３８に示す例では、組織情報は、組織ＩＤ３８０１、組織名３８０３、ディスプレイに表示される名称を示す表示名３８０５、所在地を示すタイムゾーン３８０７、使用言語を示す言語３８０９が関連付けられている。例えば組織ＩＤ「１」は、組織名「CompanyA」であり、表示部への表示名は「Ａ社」であり、所在地は「Tokyo」であり、使用言語は「Japanese」である。
【０１３６】
図３９は、ユーザ情報の一例を示す図である。図３９に示す例では、ユーザＩＤ３７０１は、図３７に示す「id」と同じ識別情報であり、組織ＩＤ３８０１は、図３８に示す「id」と同じ識別情報である。
【０１３７】
図３９に示す例では、ユーザ情報は、ユーザＩＤ３７０１、組織ＩＤ３８０１、ログイン名３９０１、タグ（第１メタデータ）３９０３、タグ（第２メタデータ）３９０５やグループ３９０７が関連付けられている。例えば、ユーザＩＤ「２」は、組織ＩＤ「３」であり、ログイン名が「wakamoto」であり、第１メタデータである「u_stag_0」が「営業部」であり、第２メタデータである「u_stag_1」が「埼玉工場」である。このようにユーザ情報にはメタデータを付与することができるようにする。
【０１３８】
ユーザ認証手段３１１は、装置から取得したログイン名及びパスワードと、図３７に示すアカウント情報のログイン名及びパスワードとを照合する。照合が一致すれば、ユーザ認証手段３１１は、ユーザＩＤを基に、図３８に示すユーザ情報を参照して組織ＩＤを取得し、認証チケットにユーザＩＤ、組織ＩＤ、及びメタデータを含める。実施例では、これらのユーザ情報を用いてビューに対してアクセス制限を加える。
【０１３９】
図４０は、ビューフィルタ情報の一例を示す図である。図４０に示すビューフィルタには、フィルタid、組織id（organization_id）、ビューセットid（view_set_id）、タイトル（title）、説明（description）、条件（user_condition）が関連付けられている。
【０１４０】
例えば、id「１」のフィルタ情報は、組織id「３」であり、ビューセットidが「１」であり、タイトルが「管理部門用」であり、条件が「"u_stag_0":"管理部"」である。このフィルタが示すのは、管理部は全てのＰＣ用のビューが見えるということである。
【０１４１】
アクセス制御手段３１３又は画面生成手段３０５は、ビューのアクセス制限を以下の手順で行う。
ａ）リクエストＵＲＬを解析
ｂ）ログインユーザの情報をＤＢから取得
ｃ）ビューセットをＤＢから取得
ｄ）ビューフィルタをＤＢから取得
ｅ）ログインユーザが閲覧可能なビューセットのリストを生成（ビューセット切替セレクトボックス用）
ｆ）リクエストされているビューセットが表示可か判定（許可されない場合はエラーを返す）
ｇ）ビューセットに含まれるビューをＤＢから取得（ビューの切替タブ用）
ｈ）リクエストされているビューの「config」情報を元に、JavaScript（登録商標）とＵＩ部品の情報を含むＨＴＭＬ形式の画面情報を生成して装置に返す。
【０１４２】
ａ）〜ｃ）の処理は、画面生成手段３０５が行う。次に、アクセス制御手段３１３は、ｄ）において、ログインのユーザのメタデータや組織情報などに基づいてビューフィルタを取得すると、ログインユーザが閲覧可能なビューセットのidを画面生成手段３０５に出力する。
【０１４３】
画面生成手段３０５は、ｅ）において、アクセス制御手段３１３から取得したビューセットのidに基づいてビューセットのリストを生成する。アクセス制御手段３１３は、ｆ）でリクエストされたＵＲＬのビューセットが表示可か判定する。例えば、アクセス制御手段３１３は、リクエストされたＵＲＬのビューセットのＵＲＬのパス名が、取得されたビューセットのidに対応するＵＲＬのパス名と一致すれば、そのビューセットは表示可と判定する。ｇ）〜ｈ）の処理は、画面生成手段３０５が行う。
【０１４４】
また、アクセス制御手段３１３は、先にｄ）のビューフィルタを取得し、ビューフィルタの制約のもとでビューセットのＤＢから表示可能なビューのリストを取得することも可能である。
【０１４５】
これにより、ビューフィルタ情報を用いることで、ユーザに関連する情報を用いて、ビューセットにアクセス制限を加えることができる。ユーザに関する情報とは、ユーザのメタデータ、ユーザの組織情報、ユーザＩＤなどである。
【０１４６】
＜ＡＰＩ＞
図４１は、ＡＰＩの例を示す図である。図４１は、サーバ１１０で用いるＡＰＩ（Application Program Interface）の例を示す図である。図４１に示すパス４１０１「cabinets/{id}/folders.json」は、フォルダの一覧を取得するときのＡＰＩである。例４１０２は、レイヤー「２」（第２階層）かつレイヤー「０」の定義に対応するデータが「ＪＰ」であるフォルダ一覧を取得するＡＰＩの例である。このときフォルダ一覧には、レイヤー２以上の階層の定義に対応するデータが表示される。
【０１４７】
パス４１０３「cabinets/{id}/layers.json」は、指定した階層のフォルダ名の一覧を取得するときのＡＰＩである。例４１０４は、レイヤー「１」（第１階層）のフォルダのフォルダ名の一覧を取得するＡＰＩの例である。このときフォルダ名一覧には、例えば、「2007.01」「2007.02」などが表示される。
【０１４８】
なお、「layers」は、「folders」と違いがあり、ユニークなデータとなっている。例えば、担当者名でフォルダを作成すると、全ての年度に担当者名のフォルダが出来る。このとき、「folders」で階層を指定した場合、同じ担当者のフォルダが何度も表示されるが、「layers」で指定した場合、全て異なる担当者のフォルダが表示される。
【０１４９】
パス４１０５「cabinets/{id}/entries.json」は、ファイル一覧を取得するときのＡＰＩである。例４１０６は、レイヤー「２」（第２階層）のフォルダ名が「00000012344891」であるフォルダに保存されているファイル一覧を取得するＡＰＩの例と、フォルダＩＤが「2108」であるフォルダに保存されているファイル一覧を取得するＡＰＩの例である。このときファイル一覧には、例えば、ファイルＩＤ、位置、サイズ、タイトルなどが表示される。
【０１５０】
パス４１０７「cabinets/{id}/tags.json」は、タグ候補の一覧を取得するときのＡＰＩである。例４１０８は、「stag_2」の候補となるタグの一覧を取得するＡＰＩの例である。このとき、キャビネットＩＤ、フォルダＩＤ、タグ名、タグタイプなどが表示される。図４１に示すＡＰＩを用いて、ＰＣ１０３は、各種データを取得することが可能となる。
【０１５１】
以上、実施例によれば、各装置に対応するＵＩ画面を適切に表示制御することができる。また、実施例によれば、ペイン単位でイベント発生を検知するため、ＵＩ部品毎に対応付けを行わなくてもよい。また、実施例によれば、ビューセットやタブを効率よく用いることで、例えば部署毎に表示可能なビューを容易に切り替えることができる。また、実施例によれば、ビューフィルタ情報を用いることで、ユーザに関連する情報に基づいてビューのアクセスを適切に制限することができる。
【０１５２】
また、携帯端末でＡｊａｘを利用可能であれば、画面生成手段３０５は、モバイル用もＰＣ用と同様にして画面情報を生成することができる。このとき、モバイル用は表示画面が小さいので、表示するＵＩ部品を少なくしたり、表示データの項目を減らしたりすればよい。
【０１５３】
実施例のサーバで実行されるプログラムは、前述した各手段を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記記憶媒体からプログラムを読み出して実行することにより上記各手段が主記憶装置上にロードされ、上記各手段が主記憶装置上に生成されるようになっている。
【０１５４】
なお、本発明は、上記実施例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施例に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施例に示される全構成要素からいくつかの構成要素を削除してもよい。
【符号の説明】
【０１５５】
１０１ ＰＣ
１０３ ＭＦＰ
１０５ 携帯端末
１０７ ＭＦＰ
１１０ サーバ
１１３ 画面制御部
１１５ インタフェース部
１１９ メタデータ管理部
１２１ 画面データ管理部
１３３ ＤＢ
３０１ 受信手段
３０３ 送信手段
３０５ 画面生成手段
３０７ 第１生成手段
３０９ 第２生成手段
３１１ ユーザ認証手段
３１３ アクセス制御手段
【先行技術文献】
【特許文献】
【０１５６】
【特許文献１】特開２００９−４８３９７号公報
【特許請求の範囲】
【請求項１】
情報処理装置と、画像形成装置と、サーバとが接続された画面制御システムであって、
前記サーバは、
画面のＵＩ部品が定義されているＵＩ定義情報を画面毎に記憶する第１記憶手段と、
前記ＵＩ部品に表示する表示データを記憶する第２記憶手段と、
前記情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、該ＵＩ定義情報に含まれるＵＩ部品に表示する表示データを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成手段と、
前記画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示する表示データをレンダリング関数を用いて取得し、該ＵＩ部品及び該ＵＩ部品に表示する表示データを含む画面を描画するための第２画面情報を生成する第２生成手段と、
前記第１生成手段により生成された第１画面情報を前記情報処理装置に送信し、又は、前記第２生成手段により生成された第２画面情報を前記画像形成装置に送信する送信手段と、
を備える画面制御システム。
【請求項２】
前記第１記憶手段は、
１又は複数の画面を切替可能にグループ化した画面を示すセット画面の定義情報をさらに記憶し、
前記第１又は第２生成手段は、
前記セット画面の表示要求を受けた場合、前記セット画面に含まれる画面を選択可能にして前記第１又は第２画面情報をそれぞれ生成する請求項１記載の画面制御システム。
【請求項３】
前記第１生成手段は、
前記情報処理装置からＡＰＩを利用してＵＩ部品に表示する表示データの取得要求を受けた場合、要求された表示データを検索し、検索された表示データを、前記ＡＰＩを利用して取得可能なデータ形式で生成する請求項１又は２記載の画面制御システム。
【請求項４】
前記第２生成手段は、
前記画像形成装置からＵＩ部品に表示される表示データの変更による再描画要求を受けた場合、要求された表示データを検索し、検索された表示データが表示されるＵＩ部品を含む画面を描画するための第３画面情報を生成する請求項１乃至３いずれか一項に記載の画面制御システム。
【請求項５】
前記画面は、前記ＵＩ部品を表示する所定の表示領域が１又は複数設定されており、前記表示領域は、他の表示領域内でのＵＩ部品の表示データの変更に基づいて自表示領域のＵＩ部品に表示される表示データの再描画を行なうよう定義されている請求項１乃至４いずれか一項に記載の画面制御システム。
【請求項６】
前記第２記憶手段は、
ユーザの認証情報及びユーザの所属や所在地を含むメタデータと、前記メタデータと前記セット画面の識別情報とを関連付けたフィルタ情報をさらに記憶し、
ログインされたユーザのメタデータに対応するセット画面の識別情報を、前記フィルタ情報を参照して取得し、取得したセット画面の識別情報に基づくセット画面を前記ユーザがアクセス可能とするアクセス制御手段をさらに備える請求項２記載の画面制御システム。
【請求項７】
前記第２記憶手段は、
フォルダ階層の階層毎の定義を示す階層定義、及び付与されるメタデータの定義を示すメタデータ定義を含むフォルダ定義データと、
前記フォルダ階層内のフォルダ毎に、該フォルダの階層以上のフォルダ定義に対応するデータ、及び該フォルダに付与されるメタデータ定義に対応するメタデータを含むフォルダデータと、
前記フォルダ階層内のフォルダの階層及び該フォルダに付与されたメタデータに関連付けられるファイルと、を記憶し、
前記表示データは、前記フォルダ定義データ、前記フォルダデータ、又は前記ファイルのいずれかのデータである請求項１乃至４いずれか一項に記載の画面制御システム。
【請求項８】
情報処理装置と、画像形成装置とに接続されるサーバであって、
画面のＵＩ部品が定義されているＵＩ定義情報を画面毎に記憶する第１記憶手段と、
前記ＵＩ部品に表示する表示データを記憶する第２記憶手段と、
前記情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、該ＵＩ定義情報に含まれるＵＩ部品に表示するデータを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成手段と、
前記画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示する表示データをレンダリング関数を用いて取得し、該ＵＩ部品及び該ＵＩ部品に表示する表示データを含む画面を構成する第２画面情報を生成する第２生成手段と、
前記第１生成手段により生成された第１画面情報を前記情報処理装置に送信し、又は、前記第２生成手段により生成された第２画面情報を前記画像形成装置に送信する送信手段と、
を備えるサーバ。
【請求項９】
情報処理装置と、画像形成装置とに接続され、画面のＵＩ部品が定義されているＵＩ定義情報を画面毎に記憶する第１記憶手段と、前記ＵＩ部品に表示する表示データを記憶する第２記憶手段とを備えるサーバにおける画面制御方法であって、
前記情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、該ＵＩ定義情報に含まれるＵＩ部品に表示するデータを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成ステップと、
前記画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示するデータをレンダリング関数を用いて取得し、該ＵＩ部品及び該ＵＩ部品に表示するデータを含む画面を構成する第２画面情報を生成する第２生成ステップと、
前記第１生成ステップにより生成された第１画面情報を前記情報処理装置に送信し、又は、前記第２生成ステップにより生成された第２画面情報を前記画像形成装置に送信する送信ステップと、
を有する画面制御方法。
【請求項１】
情報処理装置と、画像形成装置と、サーバとが接続された画面制御システムであって、
前記サーバは、
画面のＵＩ部品が定義されているＵＩ定義情報を画面毎に記憶する第１記憶手段と、
前記ＵＩ部品に表示する表示データを記憶する第２記憶手段と、
前記情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、該ＵＩ定義情報に含まれるＵＩ部品に表示する表示データを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成手段と、
前記画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示する表示データをレンダリング関数を用いて取得し、該ＵＩ部品及び該ＵＩ部品に表示する表示データを含む画面を描画するための第２画面情報を生成する第２生成手段と、
前記第１生成手段により生成された第１画面情報を前記情報処理装置に送信し、又は、前記第２生成手段により生成された第２画面情報を前記画像形成装置に送信する送信手段と、
を備える画面制御システム。
【請求項２】
前記第１記憶手段は、
１又は複数の画面を切替可能にグループ化した画面を示すセット画面の定義情報をさらに記憶し、
前記第１又は第２生成手段は、
前記セット画面の表示要求を受けた場合、前記セット画面に含まれる画面を選択可能にして前記第１又は第２画面情報をそれぞれ生成する請求項１記載の画面制御システム。
【請求項３】
前記第１生成手段は、
前記情報処理装置からＡＰＩを利用してＵＩ部品に表示する表示データの取得要求を受けた場合、要求された表示データを検索し、検索された表示データを、前記ＡＰＩを利用して取得可能なデータ形式で生成する請求項１又は２記載の画面制御システム。
【請求項４】
前記第２生成手段は、
前記画像形成装置からＵＩ部品に表示される表示データの変更による再描画要求を受けた場合、要求された表示データを検索し、検索された表示データが表示されるＵＩ部品を含む画面を描画するための第３画面情報を生成する請求項１乃至３いずれか一項に記載の画面制御システム。
【請求項５】
前記画面は、前記ＵＩ部品を表示する所定の表示領域が１又は複数設定されており、前記表示領域は、他の表示領域内でのＵＩ部品の表示データの変更に基づいて自表示領域のＵＩ部品に表示される表示データの再描画を行なうよう定義されている請求項１乃至４いずれか一項に記載の画面制御システム。
【請求項６】
前記第２記憶手段は、
ユーザの認証情報及びユーザの所属や所在地を含むメタデータと、前記メタデータと前記セット画面の識別情報とを関連付けたフィルタ情報をさらに記憶し、
ログインされたユーザのメタデータに対応するセット画面の識別情報を、前記フィルタ情報を参照して取得し、取得したセット画面の識別情報に基づくセット画面を前記ユーザがアクセス可能とするアクセス制御手段をさらに備える請求項２記載の画面制御システム。
【請求項７】
前記第２記憶手段は、
フォルダ階層の階層毎の定義を示す階層定義、及び付与されるメタデータの定義を示すメタデータ定義を含むフォルダ定義データと、
前記フォルダ階層内のフォルダ毎に、該フォルダの階層以上のフォルダ定義に対応するデータ、及び該フォルダに付与されるメタデータ定義に対応するメタデータを含むフォルダデータと、
前記フォルダ階層内のフォルダの階層及び該フォルダに付与されたメタデータに関連付けられるファイルと、を記憶し、
前記表示データは、前記フォルダ定義データ、前記フォルダデータ、又は前記ファイルのいずれかのデータである請求項１乃至４いずれか一項に記載の画面制御システム。
【請求項８】
情報処理装置と、画像形成装置とに接続されるサーバであって、
画面のＵＩ部品が定義されているＵＩ定義情報を画面毎に記憶する第１記憶手段と、
前記ＵＩ部品に表示する表示データを記憶する第２記憶手段と、
前記情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、該ＵＩ定義情報に含まれるＵＩ部品に表示するデータを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成手段と、
前記画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示する表示データをレンダリング関数を用いて取得し、該ＵＩ部品及び該ＵＩ部品に表示する表示データを含む画面を構成する第２画面情報を生成する第２生成手段と、
前記第１生成手段により生成された第１画面情報を前記情報処理装置に送信し、又は、前記第２生成手段により生成された第２画面情報を前記画像形成装置に送信する送信手段と、
を備えるサーバ。
【請求項９】
情報処理装置と、画像形成装置とに接続され、画面のＵＩ部品が定義されているＵＩ定義情報を画面毎に記憶する第１記憶手段と、前記ＵＩ部品に表示する表示データを記憶する第２記憶手段とを備えるサーバにおける画面制御方法であって、
前記情報処理装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報と、該ＵＩ定義情報に含まれるＵＩ部品に表示するデータを非同期通信で取得するためのプログラムとを含む第１画面情報を生成する第１生成ステップと、
前記画像形成装置から画面の表示要求を受けた場合、表示要求を受けた画面に対応するＵＩ定義情報に含まれるＵＩ部品に表示するデータをレンダリング関数を用いて取得し、該ＵＩ部品及び該ＵＩ部品に表示するデータを含む画面を構成する第２画面情報を生成する第２生成ステップと、
前記第１生成ステップにより生成された第１画面情報を前記情報処理装置に送信し、又は、前記第２生成ステップにより生成された第２画面情報を前記画像形成装置に送信する送信ステップと、
を有する画面制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【公開番号】特開２０１１−１９７８３４（Ｐ２０１１−１９７８３４Ａ）
【公開日】平成２３年１０月６日（２０１１．１０．６）
【国際特許分類】
【出願番号】特願２０１０−６１６８４（Ｐ２０１０−６１６８４）
【出願日】平成２２年３月１７日（２０１０．３．１７）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２３年１０月６日（２０１１．１０．６）
【国際特許分類】
【出願日】平成２２年３月１７日（２０１０．３．１７）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]