JP2014197827A - 情報処理システム、機器、情報処理方法、及び情報処理プログラム - Google Patents

Abstract

【課題】機器の機能を利用させるための異なる形態の複数のインタフェース間の機能差の発生を抑制すること。【解決手段】機器と、当該機器に対して表示データを提供するコンピュータとを含む情報処理システムであって、前記機器は、プログラムより当該機器の機能の利用要求を第一のインタフェースを介して受け付け、当該利用要求に応じた処理を実行する第一のインタフェース手段と、前記表示データより当該機器の機能の利用要求を第二のインタフェースを介して受け付け、当該利用要求に応じた処理を実行する第二のインタフェース手段とを有し、前記第二のインタフェース手段は、前記第二のインタフェースを介した前記利用要求の受け付けに応じ、当該利用要求に対応する第一のインタフェースの呼び出し要求を、前記第一のインタフェース手段に入力する。【選択図】図４

Description

本発明は、情報処理システム、機器、情報処理方法、及び情報処理プログラムに関する。

従来、例えば、複合機又は融合機と呼ばれる画像形成装置において、公開されたＡＰＩ（Application Program Interface）を有し、当該ＡＰＩを用いて開発されたアプリケーション（以下、「ＳＤＫ（Software Development Kit：ソフトウェア開発キット）アプリ」という。）の実行環境を提供するアプリケーションプラットフォーム（以下、「ＳＤＫプラットフォーム」という。）を備えた画像形成装置が有る（例えば、特許文献１）。

また、ＳＤＫプラットフォームを備えた画像形成装置において、ＨＴＭＬ（Hyper Text Markup Language）データを機器の操作画面として表示するブラウザソフトが搭載された画像形成装置が存在する。このようなブラウソフトの中には、画面を表示するだけでなく、機器制御用に拡張されたスクリプト（以下、「拡張スクリプト」という。）を解釈して機器制御を実行することが可能なものも有る。拡張スクリプトの一例として、「ｄｏＳｃａｎ」というメソッドが挙げられる。「ｄｏＳｃａｎ」は、スキャンの実行命令を示す拡張スクリプトである。拡張スクリプトを解釈可能なブラウザソフトによれば、拡張スクリプトをブラウザベースのＡＰＩとして、カスタマイズ用に提供することができる（例えば、特許文献２）。

上記のような画像形成装置に対するアプリケーションの開発者は、アプリケーションの特性等に合わせて、ＳＤＫプラットフォームが提供するＡＰＩ（以下、「ＳＤＫＡＰＩ」という。）を利用したＳＤＫアプリといった形態、又は拡張スクリプト等を利用したＷｅｂページといった形態のいずれかを選択して、アプリケーションを開発することができる。

しかしながら、ＳＤＫプラットフォームとブラウザソフトとは、それぞれ異なるプログラムであるため、画像形成装置の機能に対する対応状況にずれが生じる可能性が有る。例えば、或る機能を利用するためのＳＤＫＡＰＩは提供されているが、拡張スクリプトは提供されていないといった状況が生じうる。そうすると、ＳＤＫアプリとしては実現可能な機能であるのに、Ｗｅｂページでは実現できないといった状況が生じうる。

なお、上記問題点は、ＳＤＫという提供形態に関わらず、公開されたＡＰＩを用いて開発されたアプリケーションが機器に処理を実行させる形態において共通の課題であると考えられる。

本発明は、上記の点に鑑みてなされたものであって、機器の機能を利用させるための異なる形態の複数のインタフェース間の機能差の発生を抑制することを目的とする。

そこで上記課題を解決するため、機器と、当該機器に対して表示データを提供するコンピュータとを含む情報処理システムであって、前記機器は、プログラムより当該機器の機能の利用要求を第一のインタフェースを介して受け付け、当該利用要求に応じた処理を実行する第一のインタフェース手段と、前記表示データより当該機器の機能の利用要求を第二のインタフェースを介して受け付け、当該利用要求に応じた処理を実行する第二のインタフェース手段とを有し、前記第二のインタフェース手段は、前記第二のインタフェースを介した前記利用要求の受け付けに応じ、当該利用要求に対応する第一のインタフェースの呼び出し要求を、前記第一のインタフェース手段に入力する。

機器の機能を利用させるための異なる形態の複数のインタフェース間の機能差の発生を抑制することができる。

本発明の実施の形態におけるシステム構成例を示す図である。 本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。 本発明の実施の形態におけるＷｅｂサーバ装置のハードウェア構成例を示す図である。 本発明の実施の形態における各装置の機能構成例を示す図である。 画像形成装置及びＷｅｂサーバ装置によって実行される処理手順の一例を説明するためのシーケンス図である。 判定テーブルの構成例を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を示す図である。図１において、画像形成装置１０とＷｅｂサーバ装置２０とは、ＬＡＮ（Local Area Network）又はインターネット等のネットワークを介して通信可能とされている。

画像形成装置１０は、印刷、スキャン、コピー、及びＦＡＸ送受信等のうちの２以上の機能を一台の筐体によって実現する複合機である。但し、いずれか一つの機能を有する機器が画像形成装置１０として用いられてもよい。本実施の形態において、各画像形成装置１０は、操作パネル（後述される、操作パネル１５）にＷｅｂページの表示等を実行させるプログラムとしてＷｅｂブラウザを有する。当該Ｗｅｂブラウザは、画像形成装置１０用に機能拡張が図られている。例えば、当該Ｗｅｂブラウザは、画像形成装置１０に固有のハードウェアを制御するための（スキャンや印刷等の実行指示を受け付けるための）スクリプト（以下、「拡張スクリプト」という。）を解釈可能である。以下、画像形成装置１０が有するＷｅｂブラウザを「機器ブラウザ」という。

Ｗｅｂサーバ装置２０は、Ｗｅｂページを介してサービスを提供するＷｅｂアプリケーションを備える。本実施の形態において、Ｗｅｂページとは、ＨＴＭＬ（HyperText Markup Language）等、所定の形式に基づいて定義された画面情報や、当該画面情報に基づいて表示される画面に対する操作等に応じて実行される処理命令を示すスクリプト等が定義又は記述されているデータをいう。本実施の形態において、Ｗｅｂサーバ装置２０によって提供されるＷｅｂページに基づく画面は、画像形成装置１０の操作パネルに表示される。

なお、２台以上の画像形成装置１０が一つのＷｅｂサーバ装置２０よりＷｅｂページの提供を受けてもよい。また、一台の画像形成装置１０が、複数のＷｅｂサーバ装置２０よりＷｅｂページの提供を受けてもよい。また、Ｗｅｂサーバ装置２０は、一つのコンピュータであってもよいし、複数のコンピュータを含むコンピュータシステムであってもよい。

図２は、本発明の実施の形態における画像形成装置のハードウェア構成例を示す図である。図２において、画像形成装置１０は、コントローラ１１、スキャナ１２、プリンタ１３、モデム１４、操作パネル１５、ネットワークインタフェース１６、及びＳＤカードスロット１７等のハードウェアを有する。

コントローラ１１は、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３、ＨＤＤ１１４、及びＮＶＲＡＭ１１５等を有する。ＲＯＭ１１３には、各種のプログラムやプログラムによって利用されるデータ等が記憶されている。ＲＡＭ１１２は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。ＣＰＵ１１１は、ＲＡＭ１１２にロードされたプログラムを処理することにより、各種の機能を実現する。ＨＤＤ１１４には、プログラムやプログラムが利用する各種のデータ等が記憶される。ＮＶＲＡＭ１１５には、各種の設定情報等が記憶される。

スキャナ１２は、原稿より画像データを読み取るためのハードウェア（画像読取手段）である。プリンタ１３は、印刷データを印刷用紙に印刷するためのハードウェア（印刷手段）である。モデム１４は、電話回線に接続するためのハードウェアであり、ＦＡＸ通信による画像データの送受信を実行するために用いられる。操作パネル１５は、ユーザからの入力の受け付けを行うためのボタン等の入力手段や、液晶パネル等の表示手段等を備えたハードウェアである。液晶パネルは、タッチパネル機能を有していてもよい。この場合、当該液晶パネルは、入力手段の機能をも兼ねる。ネットワークインタフェース１６は、ＬＡＮ等のネットワーク（有線又は無線の別は問わない。）に接続するためのハードウェアである。ＳＤカードスロット１７は、ＳＤカード８０に記憶されたプログラムを読み取るために利用される。すなわち、画像形成装置１０では、ＲＯＭ１１３に記憶されたプログラムだけでなく、ＳＤカード８０に記憶されたプログラムもＲＡＭ１１２にロードされ、実行されうる。なお、他の記録媒体（例えば、ＣＤ−ＲＯＭ又はＵＳＢ（Universal Serial Bus）メモリ等）によってＳＤカード８０が代替されてもよい。すなわち、ＳＤカード８０の位置付けに相当する記録媒体の種類は、所定のものに限定されない。この場合、ＳＤカードスロット１７は、記録媒体の種類に応じたハードウェアによって代替されればよい。

図３は、本発明の実施の形態におけるＷｅｂサーバ装置のハードウェア構成例を示す図である。図２のＷｅｂサーバ装置２０は、それぞれバスＢで相互に接続されているドライブ装置２００、補助記憶装置２０２、メモリ装置２０３、ＣＰＵ２０４、及びインタフェース装置２０５等を有する。

Ｗｅｂサーバ装置２０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体２０１によって提供される。プログラムを記憶した記録媒体２０１がドライブ装置２００にセットされると、プログラムが記録媒体２０１からドライブ装置２００を介して補助記憶装置２０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体２０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置２０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置２０３は、プログラムの起動指示があった場合に、補助記憶装置２０２からプログラムを読み出して格納する。ＣＰＵ２０４は、メモリ装置２０３に格納されたプログラムに従ってＷｅｂサーバ装置２０に係る機能を実行する。インタフェース装置２０５は、ネットワークに接続するためのインタフェースとして用いられる。

図４は、本発明の実施の形態における各装置の機能構成例を示す図である。図４において、画像形成装置１０は、機器ブラウザ１２１、拡張スクリプト実行部１２２、１以上のＳＤＫアプリ１２３、ＳＤＫプラットフォーム１２４、コントロールサービス１２５、ＶＡＳ１２６、及びＯＳ１２７等を有する。これらは、ＣＰＵ１１１に処理を実行させることにより、それぞれの機能を実現するプログラムである。

機器ブラウザ１２１は、上述した機器ブラウザである。拡張スクリプト実行部１２２は、拡張スクリプトに応じた処理を制御する。拡張スクリプトは、画像形成装置１０の機能の利用要求又は実行要求をＷｅｂページより受け付けるためのインタフェースの一例である。機器ブラウザ１２１は、Ｗｅｂページ内に拡張スクリプトを検出した場合、当該拡張スクリプトの実行を拡張スクリプト実行部１２２に要求する。拡張スクリプト実行部１２２は、当該拡張スクリプトに対応する処理要求を、ＶＡＳ１２６を介して、コントロールサービス１２５に入力する。

ＳＤＫアプリ１２３は、画像形成装置１０の出荷後において、画像形成装置１０の機能拡張等を図るために追加的にインストールされるアプリケーションプログラム又はプラグインである。

ＳＤＫプラットフォーム１２４は、ＳＤＫアプリ１２３を開発するためのＡＰＩ（Application Program Interface）を備えると共に、ＳＤＫアプリ１２３の実行環境を提供する。ＡＰＩの形態は、例えば、関数であってもよいし、オブジェクト指向のクラス及びクラスのメソッド等であってもよい。以下、ＳＤＫプラットフォーム１２４が提供するＡＰＩを、「ＳＤＫＡＰＩ」という。ＳＤＫＡＰＩは、画像形成装置１０の機能の利用要求又は実行要求をＳＤＫアプリ１２３より受け付けるためのインタフェースの一例である。

図４において、ＳＤＫプラットフォーム１２４に含まれるＳＤＫコンポーネント１２４１は、ＳＤＫＡＰＩを提供するソフトウェアコンポーネントである。各ＳＤＫコンポーネント１２４１は、それぞれ機能の共通性に基づいてＳＤＫコンポーネント１２４１ごとに分類されるＳＤＫＡＰＩを提供する。例えば、ＳＤＫコンポーネント１２４１ａは、スキャン機能に関するＳＤＫＡＰＩを提供し、ＳＤＫコンポーネント１２４１ｂは、印刷機能に関するＳＤＫＡＰＩを提供し、ＳＤＫコンポーネント１２４１ｃは、ＦＡＸ機能に関するＳＤＫＡＰＩ等をＳＤＫアプリ１２３に提供するといった具合である。各ＳＤＫコンポーネント１２４１は、呼び出されたＳＤＫＡＰＩに対応する処理要求を、ＶＡＳ１２６を介して、コントロールサービス１２５に入力する。なお、ＳＤＫＡＰＩは公開されており、サードベンダ等によってもＳＤＫアプリ１２３は開発されうる。また、ＳＤＫプラットフォーム１２４は、Ｊａｖａ（登録商標）ＶＭ（Virtual Machine）を含んでいてもよい。この場合、ＳＤＫアプリ１２３は、Ｊａｖａ（登録商標）言語によって実装される。

コントロールサービス１２５は、各種のハードウェアリソース等を制御するためのインタフェース（ＡＰＩ）を上位層のプログラムに対して提供したり、画像形成装置１０の基盤的な機能等を実行したりするプログラムモジュール群である。

ＶＡＳ（Virtual Application Service）１２６は、コントロールサービス１２５のインタフェースをラッピングし、コントロールサービス１２５のバージョンアップに伴うインタフェースの相違点を吸収する。したがって、ＶＡＳ１２６上で動作するプログラムに対しては、コントロールサービス１２５の各パージョンに対する互換性が保証される。

ＯＳ１２７は、いわゆるＯＳ（Operating System）である。画像形成装置１０上の各ソフトウェアは、ＯＳ１２７上においてプロセス又はスレッドとして動作する。

ところで、図４において、拡張スクリプト実行部１２２は、判定部１２２１及び処理要求部１２２２等を含む。判定部１２２１は、機器ブラウザ１２１からの拡張スクリプトの実行要求に応じ、当該要求に応じた処理を実行する責務（以下、「実行責務」という。）が、拡張スクリプト実行部１２２及びＳＤＫプラットフォーム１２４のいずれに有るのかを判定する。処理要求部１２２２は、判定部１２２１によって、ＳＤＫプラットフォーム１２４に実行責務が有ると判定された場合に、実行対象の拡張スクリプトに応じた処理要求を、ＳＤＫプラットフォーム１２４に入力する。

ＳＤＫプラットフォーム１２４は、要求受付部１２４２を有する。要求受付部１２４２は、拡張スクリプト実行部１２２の処理要求部１２２２からの処理要求を受け付けるためのインタフェースを提供する。当該インタフェースは、例えば、プロセス間通信を用いて実現されてもよい。要求受付部１２４２は、受け付けた処理要求に応じた処理を、いずれかのＳＤＫコンポーネント１２４１に実行させる。

このように、拡張スクリプト実行部１２２の処理要求と、ＳＤＫプラットフォーム１２４の要求受付部１２４２とによって、拡張スクリプト実行部１２２とＳＤＫプラットフォーム１２４との連携が実現される。その結果、Ｗｅｂページに記述された拡張スクリプトに応じた処理を、ＳＤＫプラットフォーム１２４へ委譲することが可能となる。

一方、Ｗｅｂサーバ装置２０は、Ｗｅｂページ提供部２１等を含む。Ｗｅｂページ提供部２１は、機器ブラウザ１２１が画像形成装置１０に送信させる要求（ＨＴＴＰリクエスト）に応じたＷｅｂページを提供する。Ｗｅｂページ提供部２１は、Ｗｅｂサーバ装置２０にインストールされたプログラムが、ＣＰＵ２０４に実行させる処理により実現される。

Ｗｅｂページは、要求に応じて動的に生成されてもよいし、Ｗｅｂサーバ装置２０、又はＷｅｂサーバ装置２０にネットワークを介して接続される記憶装置等に、予め記憶されていてもよい。 なお、画像形成装置１０がＷｅｂページ提供部２１を有していてもよい。すなわち、Ｗｅｂページは、画像形成装置１０の内部から取得されてもよい。

以下、画像形成装置１０及びＷｅｂサーバ装置２０によって実行される処理手順を説明する。図５は、画像形成装置及びＷｅｂサーバ装置によって実行される処理手順の一例を説明するためのシーケンス図である。

ステップＳ１０１において、Ｗｅｂページ提供部２１は、機器ブラウザ１２１からの要求に応じたＷｅｂページを含む応答を、機器ブラウザ１２１に対して返信する。機器ブラウザ１２１からの要求は、例えば、操作パネル１５に対するユーザによる操作に応じてＷｅｂサーバ装置２０に送信される。機器ブラウザ１２１は、Ｗｅｂページを解析し、拡張スクリプトを検出すると、当該拡張スクリプトの実行を、拡張スクリプト実行部１２２に要求する（Ｓ１０２）。なお、標準のスクリプト（例えば、標準のＪａｖａ（登録商標）スクリプト）に関しては、機器ブラウザ１２１によって実行される。また、ステップＳ１０２は、Ｗｅｂページに含まれている画面情報に基づく、操作パネル１５への画面の表示過程において自動的に行われてもよいし、画面の表示後に行われてもよい。画面の表示後にステップＳ１０２が実行される場合、当該画面上におけるいずれかの操作部品に対するユーザによる操作に応じて、ステップＳ１０２が実行されてもよい。どのようなタイミングでステップＳ１０２が実行されるかについては、Ｗｅｂページの定義に依存する。

拡張スクリプト実行部１２２の判定部１２２１は、実行要求に係る拡張スクリプトに応じた処理の実行主体を判定する（Ｓ１０３）。実行主体とは、実行責務の有る主体である。実行主体の判定は、例えば、ＨＤＤ１１４に記憶されている判定テーブルに基づいて行われる。

図６は、判定テーブルの構成例を示す図である。図６において、判定テーブルは、拡張スクリプトの関数名ごとに、実行主体の識別情報を記憶する。図６では、拡張スクリプトの関数として、ｄｏＳｃａｎ、ｄｏＰｒｉｎｔ、及びｄｏＦｕｎｃｔｉｏｎが例示されている。

ｄｏＳｃａｎは、画像形成装置１０に対するスキャンの実行要求（スキャン機能の利用要求）を示す、拡張スクリプトの関数である。ｄｏＰｒｉｎｔは、画像形成装置１０に対する印刷の実行要求（印刷機能の利用要求）を示す、拡張スクリプトの関数である。図６によれば、ｄｏＳｃａｎ及びｄｏＰｒｉｎｔの実行主体は、拡張スクリプト実行部１２２とされている。ｄｏＳｃａｎ及びｄｏＰｒｉｎｔに対する実装は、拡張スクリプト実行部１２２に含まれているからである。

一方、ｄｏＦｕｎｃｔｉｏｎは、関数名のみでは機能が特定されない関数であり、例えば、以下のようなインタフェース仕様を有する。

ｄｏＦｕｎｃｔｉｏｎ（＜サービス名＞、＜メソッド名＞、引数１、引数２、・・・、引数Ｎ、＜コールバック関数名＞）
第一引数である＜サービス名＞には、ＳＤＫコンポーネント１２４１の識別情報が指定される。例えば、ＳＤＫコンポーネント１２４１ごとに名前が付与されており、当該名前が第一引数に指定される。第二引数である＜メソッド名＞には、ＳＤＫコンポーネント１２４１が提供するメソッドのメソッド名を示す文字列が指定される。第三引数以降は、当該メソッド名に係るメソッドの引数が指定される。したがって、第三引数以降の引数の数は、第一引数に指定されるメソッド名に応じて異なりうる。

最終引数の＜コールバック関数＞は、＜サービス名＞及び＜メソッド名＞によって特定されるメソッドの応答が、当該メソッドの呼び出しに対して同期的にではなく、非同期に行われる場合に、当該応答を受けるためのコールバック関数の識別情報である。コールバック関数の識別情報とは、例えば、コールバック関数のアドレス情報又は関数名である。

このように、「ｄｏＦｕｎｃｉｔｏｎ」は、ＳＤＫコンポーネント１２４１が提供する複数のメソッドを、Ｗｅｂページから呼び出し可能とする拡張スクリプトの関数である。図６において、ｄｏＦｕｎｃｔｉｏｎの実行主体は、ＳＤＫプラットフォーム１２４とされている。

続いて、判定部１２２１による判定結果に応じて処理が分岐する。すなわち、実行主体がＳＤＫプラットフォーム１２４であると判定された場合、すなわち、実行対象の拡張スクリプトがｄｏＦｕｎｃｉｔｏｎである場合、ステップＳ１１１〜Ｓ１１４が実行される。

ステップＳ１１１において、拡張スクリプト実行部１２２の処理要求部１２２２は、ｄｏＦｕｎｃｔｉｏｎに指定された引数の値を含む処理要求を、ＳＤＫプラットフォーム１２４の要求受付部１２４２に入力する。本実施の形態では、例えば、ｄｏＦｕｎｃｔｉｏｎの各引数に対して以下のような値が指定されていることとする。

ｄｏＦｕｎｃｔｉｏｎ（"ＦＡＸ"、"ｓｅｎｄ"、＜宛先＞、＜送信ファイルＩＤ＞、"ｃａｌｌｂａｃｋＦｕｎｃ"）
したがって、"ＦＡＸ"、"ｓｅｎｄ"、＜宛先＞、＜送信ファイルＩＤ＞、"ｃａｌｌｂａｃｋＦｕｎｃ"を含む処理要求が、要求受付部１２４２に入力される。当該処理要求は、引数で特定されるメソッドの呼び出し要求に相当する。

続いて、要求受付部１２４２は、ＳＤＫコンポーネント１２４１の中から、第一引数の"ＦＡＸ"に対応するＳＤＫコンポーネント１２４１ｃを検索し、ＳＤＫコンポーネント１２４１ｃが有する、以下のメソッドを、例えば、以下の形式で呼び出す（Ｓ１１２）。

ｓｅｎｄ（＜宛先＞、＜送信ファイルＩＤ＞、"ｃａｌｌｂａｃｋＦｕｎｃ"）
すなわち、要求受付部１２４２は、ｄｏＦｕｎｃｔｉｏｎの第二引数に指定された文字列を、呼び出すべきメソッド名として解釈し、第三引数以降を、当該メソッド名に係るメソッドに対する引数として解釈する。したがって、ｓｅｎｄメソッドの引数には、「ｄｏＦｕｎｃｔｉｏｎ」の第二引数以降の値がそのまま指定される。

このように、要求受付部１２４２は、ｄｏＦｕｎｃｔｉｏｎの各引数の位置に基づいて、機械的にＳＤＫコンポーネント１２４１に対するメソッドの呼び出し形式を生成する。換言すれば、要求受付部１２４２は、ｄｏＦｕｎｃｔｉｏｎの引数の値に応じて処理内容を変化させることはない。したがって、例えば、新たなＳＤＫコンポーネント１２４１が追加された場合、要求受付部１２４２は、当該ＳＤＫコンポーネント１２４１のメソッドに関しても、既存のＳＤＫコンポーネント１２４１のメソッドと同様に機械的又は動的に呼び出すことができる。

なお、ｓｅｎｄメソッドは、ＳＤＫＡＰＩを構成するメソッドであってもよい。すなわち、要求受付部１２４２が呼び出すメソッドは、ＳＤＫＡＰＩであってもよい。そうすることにより、各ＳＤＫコンポーネント１２４１に対して、要求受付部１２４２から呼び出されるためのメソッドを改めて実装する必要性を低減させることができる。

ｓｅｎｄメソッドを呼び出されたＳＤＫコンポーネント１２４１ｃは、ｓｅｎｄメソッドに応じた処理要求を、ＶＡＳ１２６を介してコントロールサービス１２５に入力する（Ｓ１１３、Ｓ１１４）。その結果、例えば、ＦＡＸの送信が実行される。なお、ＳＤＫコンポーネント１２４１ｃ内で解決可能なメソッドが呼び出された場合、ＶＡＳ１２６を介したコントロールサービス１２５への処理要求の入力は実行されなくてもよい。ＳＤＫコンポーネント１２４１ｃ内で解決可能なメソッドとは、例えば、画像形成装置１０のハードウェアリソースの制御等を必要としない処理を実行するメソッドである。

一方、ステップＳ１０３において、実行主体が拡張スクリプト実行部１２２であると判定された場合、すなわち、実行対象の拡張スクリプトがｄｏＳｃａｎ又はｄｏＰｒｉｎｔである場合、ステップＳ１２１〜Ｓ１２３が実行される。

ステップＳ１２１において、拡張スクリプト実行部１２２は、実行対象の関数に応じたコンポーネント（拡張スクリプト実行部１２２内のコンポーネント）に対して、実行要求を入力する。当該関数が、画像形成装置１０のハードウェアリソースの制御等を必要とする処理を実行する場合、当該コンポーネントは、当該関数に応じた処理要求を、ＶＡＳ１２６を介してコントロールサービス１２５に入力する（Ｓ１２２、Ｓ１２３）。その結果、例えば、ｄｏＳｃａｎであれば、スキャンが実行され、ｄｏＰｒｉｎｔであれば、印刷が実行される。

なお、判定部１２２１による判定は実行されずに、単に、スクリプトの関数が呼び出されてもよい。この場合、スクリプトの関数内において、実行主体がいずれであるかが明確に実装されていればよい。そうすることで、ステップＳ１１１〜Ｓ１１４と、ステップＳ１２１〜Ｓ１２３との分岐を実現することができる。

上述したように、本実施の形態では、拡張スクリプトとして、ＳＤＫコンポーネント１２４１における複数のメソッドに対して共通に利用な拡張スクリプトである「ｄｏＦｕｎｃｔｉｏｎ」をＷｅｂページに記述することができる。すなわち、「ｄｏＦｕｎｃｔｉｏｎ」は、ｓｅｎｄメソッドのみでなく、本実施の形態において、ＳＤＫコンポーネント１２４１が有する他の複数のメソッド（例えば、ｓｃａｎメソッド、ｐｒｉｎｔメソッド等）に関して共通に利用可能である。したがって、ＳＤＫコンポーネント１２４１が公開するメソッドごとに、拡張スクリプトが定義される必要性を低減させることができる。その結果、ＳＤＫプラットフォーム１２４においてＳＤＫＡＰＩを介して利用可能な画像形成装置１０の機能を、Ｗｅｂページから利用可能とするための機器ブラウザ１２１の改変の必要性を低減させることができる。すなわち、ＳＤＫＡＰＩと、拡張スクリプトといった、画像形成装置１０の機能を利用させるための異なる形態のインタフェース間の機能差の発生を抑制することができる。

なお、ｄｏＳｃａｎやｄｏＰｒｉｎｔに関しても、内部的にｄｏＦｕｎｃｔｉｏｎが呼び出されるように実装されてもよい。そうすることにより、スクリプトの記述の容易性を確保しつつ、スクリプトの呼び出しに応じた処理の実装を、ＳＤＫプラットフォーム１２４側に一元化することができる。スクリプトの記述の容易性を確保できるのは、ｄｏＳｃａｎやｄｏＰｒｉｎｔのように、実行する機能が特定されている関数の方が、ｄｏＦｕｎｃｔｉｏｎよりも、引数の指定が容易であるからである。

なお、Ｗｅｂページと異なる形式のデータであって、Ｗｅｂページにおけるスクリプトのような命令を記述可能な表示データが、Ｗｅｂページの代わりに用いられてもよい。

また、プロジェクタ、ＴＶ会議用機器、デジタルカメラ、又はその他の機器等、画像形成装置以外の機器に関して、本実施の形態が適用されてもよい。

なお、本実施の形態において、ＳＤＫＡＰＩは、第一のインタフェースの一例である。ＳＤＫプラットフォーム１２４又はＳＤＫコンポーネント１２４１は、第一のインタフェース手段の一例である。拡張スクリプトは、第二のインタフェースの一例である。機器ブラウザ１２１及び拡張スクリプト実行部１２２は、第二のインタフェース手段の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ 画像形成装置
１１ コントローラ
１２ スキャナ
１３ プリンタ
１４ モデム
１５ 操作パネル
１６ ネットワークインタフェース
１７ ＳＤカードスロット
２０ Ｗｅｂサーバ装置
２１ Ｗｅｂページ提供部
８０ ＳＤカード
１１１ ＣＰＵ
１１２ ＲＡＭ
１１３ ＲＯＭ
１１４ ＨＤＤ
１１５ ＮＶＲＡＭ
１２１ 機器ブラウザ
１２２ 拡張スクリプト実行部
１２３ ＳＤＫアプリ
１２４ ＳＤＫプラットフォーム
１２５ コントロールサービス
１２６ ＶＡＳ
１２７ ＯＳ
２００ ドライブ装置
２０１ 記録媒体
２０２ 補助記憶装置
２０３ メモリ装置
２０４ ＣＰＵ
２０５ インタフェース装置
１２２１ 判定部
１２２２ 処理要求部
１２４１ ＳＤＫコンポーネント
１２４１ａ ＳＤＫコンポーネント
１２４１ｂ ＳＤＫコンポーネント
１２４１ｃ ＳＤＫコンポーネント
１２４２ 要求受付部
Ｂ バス

特開２００５−２６９６１９号公報 特開２００６−３５２８４５号公報

Claims (6)

1. 機器と、当該機器に対して表示データを提供するコンピュータとを含む情報処理システムであって、
   前記機器は、
   プログラムより当該機器の機能の利用要求を第一のインタフェースを介して受け付け、当該利用要求に応じた処理を実行する第一のインタフェース手段と、
   前記表示データより当該機器の機能の利用要求を第二のインタフェースを介して受け付け、当該利用要求に応じた処理を実行する第二のインタフェース手段とを有し、
   前記第二のインタフェース手段は、前記第二のインタフェースを介した前記利用要求の受け付けに応じ、当該利用要求に対応する第一のインタフェースの呼び出し要求を、前記第一のインタフェース手段に入力する情報処理システム。
2. 前記第二のインタフェースは、前記第一のインタフェースの名前を引数の値とし、
   前記第二のインタフェース手段は、前記第二のインタフェースの引数に指定された名前に対応する前記第一のインタフェースの呼び出し要求を、前記第一のインタフェース手段に入力する請求項１記載の情報処理システム。
3. 前記表示データは、Ｗｅｂページであり、
   前記第二のインタフェースは、スクリプトである請求項１又は２記載の情報処理システム。
4. プログラムより当該機器の機能の利用要求を第一のインタフェースを介して受け付け、当該利用要求に応じた処理を実行する第一のインタフェース手段と、
   表示データより当該機器の機能の利用要求を第二のインタフェースを介して受け付け、当該利用要求に応じた処理を実行する第二のインタフェース手段とを有し、
   前記第二のインタフェース手段は、前記第二のインタフェースを介した前記利用要求の受け付けに応じ、当該利用要求に対応する第一のインタフェースの呼び出し要求を、前記第一のインタフェース手段に入力する機器。
5. 機器と、当該機器に対して表示データを提供するコンピュータとを含む情報処理システムにおいて、
   前記機器が、
   プログラムより当該機器の機能の利用要求を第一のインタフェースを介して受け付け、当該利用要求に応じた処理を実行する第一のインタフェース手順と、
   前記表示データより当該機器の機能の利用要求を第二のインタフェースを介して受け付け、当該利用要求に応じた処理を実行する第二のインタフェース手順とを実行し、
   前記第二のインタフェース手順は、前記第二のインタフェースを介した前記利用要求の受け付けに応じ、当該利用要求に対応する第一のインタフェースの呼び出し要求を、前記第一のインタフェース手順に入力する情報処理方法。
6. 機器に、
   プログラムより当該機器の機能の利用要求を第一のインタフェースを介して受け付け、当該利用要求に応じた処理を実行する第一のインタフェース手順と、
   表示データより当該機器の機能の利用要求を第二のインタフェースを介して受け付け、当該利用要求に応じた処理を実行する第二のインタフェース手順とを実行させ、
   前記第二のインタフェース手順は、前記第二のインタフェースを介した前記利用要求の受け付けに応じ、当該利用要求に対応する第一のインタフェースの呼び出し要求を、前記第一のインタフェース手順に入力する情報処理プログラム。

Images