図面 (/)

技術 情報処理システム、情報処理装置、及び情報処理方法

出願人 株式会社リコー
発明者 杉村和徳林雄一郎
出願日 2015年11月12日 (5年0ヶ月経過) 出願番号 2015-222330
公開日 2016年8月25日 (4年3ヶ月経過) 公開番号 2016-154000
状態 特許登録済
技術分野 計算機間の情報転送 計算機・データ通信 付属装置、全体制御 タイプライター等へのデジタル出力 ファクシミリ一般
主要キーワード 各選択要素 型変換処理 保存結果 処理実行手順 変換コンポーネント OCR処理後 ロジック処理 ドキュメントサービス
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年8月25日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

外部サービス連携した処理を行うためのアプリケーションの開発を支援することができる情報処理システム情報処理装置、及び情報処理方法を提供することを課題とする。

解決手段

所定の処理をそれぞれ実行する複数のプログラムを有する情報処理システムであって、電子データを用いた一連の処理を外部サービスと連携して実行するアプリ毎に、該アプリ識別情報と、該一連の処理を前記プログラムを組み合わせて実行するための一連の処理に関する情報とを関連付けて記憶する記憶手段と、前記識別情報と、前記一連の処理に用いる電子データに関する情報とを含む要求を受け付ける受付手段と、前記電子データを用いた前記一連の処理を、前記識別情報に関連付けられている前記一連の処理に関する情報に基づいて、前記複数のプログラムのうちの1以上のプログラムを組み合わせて実行する処理実行手段とを有することにより、上記課題を解決する。

概要

背景

近年、クラウドコンピューティング等により多種多様外部サービスが提供されるようになった。例えば、ユーザにより指定された電子データを外部ストレージ保管する外部サービス等が知られている。

また、例えば画像形成装置原稿スキャンして取得した画像データを外部ストレージに保管する技術が知られている(例えば特許文献1参照)。このように、画像形成装置と外部サービスとが連携して処理を行う技術が従来より知られている。

概要

外部サービスと連携した処理を行うためのアプリケーションの開発を支援することができる情報処理システム情報処理装置、及び情報処理方法を提供することを課題とする。所定の処理をそれぞれ実行する複数のプログラムを有する情報処理システムであって、電子データを用いた一連の処理を外部サービスと連携して実行するアプリ毎に、該アプリ識別情報と、該一連の処理を前記プログラムを組み合わせて実行するための一連の処理に関する情報とを関連付けて記憶する記憶手段と、前記識別情報と、前記一連の処理に用いる電子データに関する情報とを含む要求を受け付ける受付手段と、前記電子データを用いた前記一連の処理を、前記識別情報に関連付けられている前記一連の処理に関する情報に基づいて、前記複数のプログラムのうちの1以上のプログラムを組み合わせて実行する処理実行手段とを有することにより、上記課題を解決する。

目的

また、ある外部サービスが固有の機能(他の外部サービスが提供していない機能)を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

1以上の情報処理装置を含み、所定の処理をそれぞれ実行する複数のプログラムを有する情報処理システムであって、電子データを用いた一連の処理を外部サービス連携して実行するアプリケーション毎に、該アプリケーション識別する識別情報と、該一連の処理を前記プログラムを組み合わせて実行するための一連の処理に関する情報とを関連付けて記憶する記憶手段と、前記情報処理システムに接続される1以上の機器のうちの一の機器から前記識別情報と、前記一連の処理に用いる電子データに関する情報とを含む要求を受け付ける受付手段と、前記受付手段により受け付けた前記要求に含まれる前記電子データに関する情報に基づく電子データを用いた前記一連の処理を、前記要求に含まれる前記識別情報に関連付けて前記記憶手段に記憶されている前記一連の処理に関する情報に基づいて、前記複数のプログラムのうちの1以上のプログラムを組み合わせて実行する処理実行手段とを有する情報処理システム。

請求項2

前記処理実行手段は、さらに、前記電子データのデータ型を所定のデータ型に変換する型変換手段を1以上有し、前記電子データを用いた前記一連の処理を、前記一連の処理に関する情報に基づいて、前記1以上のプログラムと、前記型変換手段とを組み合わせて、前記型変換手段により前記電子データのデータ型を前記プログラムが処理可能な所定のデータ型に変換した後、該プログラムが処理を実行することにより実行する、請求項1記載の情報処理システム。

請求項3

前記複数のプログラムは、外部サービスに関する処理を実行するプログラムを含み、前記外部サービスに関する処理を実行するプログラムは、外部サービスに対して電子データをアップロードする処理を実行するプログラム及び外部サービスから電子データをダウンロードする処理を実行するプログラムを少なくとも含む、請求項1又は2記載の情報処理システム。

請求項4

前記外部サービス毎に、複数の前記外部サービスに対して共通に定義された共通APIと、前記外部サービス毎に固有に定義された固有APIとを含む外部サービス連携手段を有し、前記外部サービスに関する処理を実行するプログラムは、前記共通API又は前記固有APIを用いて、前記外部サービスに関する処理を実行する、請求項3に記載の情報処理システム。

請求項5

前記共通APIは、複数の前記外部サービスのいずれもが共通に提供する機能を利用するためのAPIであり、前記固有APIは、複数の前記外部サービスのうちのいずれかの外部サービスが提供する機能を利用するためのAPIである、請求項4記載の情報処理システム。

請求項6

前記外部サービスに関する処理を実行するプログラムは、前記共通API又は前記固有APIの可変部分に、外部サービスの識別情報を指定することにより該指定された識別情報に対応する外部サービスに対して前記外部サービスに関する処理を実行する、請求項4又は5記載の情報処理システム。

請求項7

前記情報処理システムは、所定の処理をそれぞれ実行する複数の外部プログラムを有する外部システムと接続され、前記処理実行手段は、前記電子データを用いた前記一連の処理を、前記一連の処理に関する情報に基づいて、前記1以上のプログラムと、前記外部プログラムとを組み合わせて実行する、請求項1ないし6のいずれか1項に記載の情報処理システム。

請求項8

前記処理実行手段は、前記一連の処理に含まれる一の処理が前記外部プログラムにより実行される処理か否かを判定する判定手段を有し、前記判定手段により前記一の処理が前記外部プログラムにより実行される処理であると判定された場合、該外部プログラムによる処理を前記外部システムに要求する、請求項7に記載の情報処理システム。

請求項9

前記処理実行手段により実行された前記一連の処理の結果を、前記一の機器に送信する送信手段を有する、請求項1ないし8のいずれか1項に記載の情報処理システム。

請求項10

前記アプリケーションは、前記一の機器から送信された電子データを前記外部サービスに対してアップロードするアプリケーションを少なくとも含む、請求項1ないし9のいずれか1項に記載の情報処理システム。

請求項11

前記アプリケーションは、前記外部サービスに蓄積されている電子データをダウンロードして前記一の機器に送信するアプリケーションを少なくとも含む、請求項9に記載の情報処理システム。

請求項12

前記送信手段は、前記外部サービスからダウンロードした電子データを、前記一連の処理の結果として前記一の機器に送信する、請求項11に記載の情報処理システム。

請求項13

所定の処理をそれぞれ実行する複数のプログラムを有する情報処理装置であって、電子データを用いた一連の処理を外部サービスと連携して実行するアプリケーション毎に、該アプリケーションを識別する識別情報と、該一連の処理を前記プログラムを組み合わせて実行するための一連の処理に関する情報とを関連付けて記憶する記憶手段と、前記情報処理装置に接続される1以上の機器のうちの一の機器から前記識別情報と、前記一連の処理に用いる電子データに関する情報とを含む要求を受け付ける受付手段と、前記受付手段により受け付けた前記要求に含まれる前記電子データに関する情報に基づく電子データを用いた前記一連の処理を、前記要求に含まれる前記識別情報に関連付けて前記記憶手段に記憶されている前記一連の処理に関する情報に基づいて、前記複数のプログラムのうちの1以上のプログラムを組み合わせて実行する処理実行手段とを有する情報処理装置。

請求項14

1以上の情報処理装置を含み、所定の処理をそれぞれ実行する複数のプログラムを有する情報処理システムであって、電子データを用いた一連の処理を外部サービスと連携して実行するアプリケーション毎に、該アプリケーションを識別する識別情報と、該一連の処理を前記プログラムを組み合わせて実行するための一連の処理に関する情報とを関連付けて記憶する記憶手段を有する情報処理システムに用いられる情報処理方法において、前記情報処理システムに接続される1以上の機器のうちの一の機器から前記識別情報と、前記一連の処理に用いる電子データに関する情報とを含む要求を受け付ける受付手順と、前記受付手順により受け付けた前記要求に含まれる前記電子データに関する情報に基づく電子データを用いた前記一連の処理を、前記要求に含まれる前記識別情報に関連付けて前記記憶手段に記憶されている前記一連の処理に関する情報に基づいて、前記複数のプログラムのうちの1以上のプログラムを組み合わせて実行する処理実行手順とを有する情報処理方法。

技術分野

0001

本発明は、情報処理システム情報処理装置、及び情報処理方法に関する。

背景技術

0002

近年、クラウドコンピューティング等により多種多様外部サービスが提供されるようになった。例えば、ユーザにより指定された電子データを外部ストレージ保管する外部サービス等が知られている。

0003

また、例えば画像形成装置原稿スキャンして取得した画像データを外部ストレージに保管する技術が知られている(例えば特許文献1参照)。このように、画像形成装置と外部サービスとが連携して処理を行う技術が従来より知られている。

発明が解決しようとする課題

0004

しかしながら、上記の従来技術においては、外部サービスと連携して処理を行うためには画像形成装置に搭載されるアプリケーションの開発が必要となる。また、ある外部サービスが固有の機能(他の外部サービスが提供していない機能)を提供するようになった場合には、この固有の機能を利用するためのモジュールプラグイン等を開発する必要がある。したがって、画像形成装置に搭載されるアプリケーションの追加や修正等の開発に要する工数が大きくなる場合があった。

0005

本発明の一実施形態は、上記の点に鑑みてなされたもので、外部サービスと連携した処理を行うためのアプリケーションの開発を支援することを目的とする。

課題を解決するための手段

0006

上記目的を達成するため、本発明の一実施形態は、1以上の情報処理装置を含み、所定の処理をそれぞれ実行する複数のプログラムを有する情報処理システムであって、電子データを用いた一連の処理を外部サービスと連携して実行するアプリケーション毎に、該アプリケーションを識別する識別情報と、該一連の処理を前記プログラムを組み合わせて実行するための一連の処理に関する情報とを関連付けて記憶する記憶手段と、前記情報処理システムに接続される1以上の機器のうちの一の機器から前記識別情報と、前記一連の処理に用いる電子データに関する情報とを含む要求を受け付ける受付手段と、前記受付手段により受け付けた前記要求に含まれる前記電子データに関する情報に基づく電子データを用いた前記一連の処理を、前記要求に含まれる前記識別情報に関連付けて前記記憶手段に記憶されている前記一連の処理に関する情報に基づいて、前記複数のプログラムのうちの1以上のプログラムを組み合わせて実行する処理実行手段とを有することを特徴とする。

発明の効果

0007

本発明の一実施形態によれば、外部サービスと連携した処理を行うためのアプリケーションの開発を支援することができる。

図面の簡単な説明

0008

第1の実施形態に係る情報処理システムの一例の構成図である。
第1の実施形態に係るサービス提供システムの一例のハードウェア構成図である。
第1の実施形態に係る画像形成装置の一例のハードウェア構成図である。
第1の実施形態に係る情報処理システムの一例の処理ブロック図である。
共通I/F及び固有I/Fの一例を説明するための図である。
データ定義の一例を説明するための図である。
レイアウト情報の一例を説明するための図である。
処理内容の一例を説明するための図である。
第1の実施形態に係るスキャン配信サービスの全体処理の一例のシーケンス図である。
スキャン配信サービスを利用するためのアプリ画面の一例を説明するための図である。
第1の実施形態に係るロジック処理部の一例の処理ブロック図である。
型変換テーブルの一例を説明するための図である。
第1の実施形態に係るOCRから配信実行までの処理の一例のシーケンス図である。
第1の実施形態に係るクラウドプリントサービスの全体処理の一例のシーケンス図である。
クラウドプリントサービスを利用するためのアプリ画面の一例を説明するための図である。
第1の実施形態に係るファイル取得実行から印刷変換までの処理の一例のシーケンス図である。
第2の実施形態に係る情報処理システムの一例の処理ブロック図である。
第2の実施形態に係るアプリ画面の表示処理の一例のシーケンス図である。
第3の実施形態に係る情報処理システムの一例の構成図である。
第3の実施形態に係る情報処理システムの一例の処理ブロック図である。
第3の実施形態に係るロジック処理部の一例の処理ブロック図である。
コンポーネント管理テーブルの一例を説明するための図である。
第3の実施形態に係る外部コンポーネント処理部の一例の処理ブロック図である。
型変換テーブルの一例を説明するための図である。
第3の実施形態に係るOCRから配信実行までの処理の一例のシーケンス図である。
処理内容の他の例を説明するための図である。
第3の実施形態に係る外部コンポーネント処理の一例のシーケンス図である。
第3の実施形態に係る処理内容の作成処理の一例のシーケンス図である。
処理内容の作成の一例を説明するための図である。

実施例

0009

以下、本発明の実施形態について図面を参照しながら詳細に説明する。

0010

[第1の実施形態]
システム構成
図1は、第1の実施形態に係る情報処理システムの一例の構成図である。図1に示される情報処理システム1は、サービス提供環境E1、ユーザ環境E2、及び外部ストレージシステム30を含み、インターネット等の広域的ネットワークN1を介して通信可能に接続されている。

0011

サービス提供環境E1は、ネットワークを介してクラウドサービス等の外部サービスを提供するシステム環境である。なお、本実施形態では、外部サービスの具体例としてクラウドサービスを採用して説明するが、ASP(Application Service Provider)によって提供されるサービスやWebサービス等、ネットワークを介して提供されるサービスに関して本実施の形態が適用されてもよい。

0012

サービス提供環境E1は、一台以上の情報処理装置で実現されるサービス提供システム10を有する。サービス提供システム10は、ネットワークを介して所定のサービスを提供する。例えば、サービス提供システム10は、ユーザ環境E2の画像形成装置20において原稿をスキャンして生成された電子ファイルを、OCR(Optical Character Reader)処理して、外部ストレージシステム30に保存するサービス(スキャン配信サービス)を提供する。また、例えば、サービス提供システム10は、外部ストレージシステム30に保存されている電子ファイルを、ユーザ環境E2の画像形成装置20で印刷するサービス(クラウドプリントサービス)を提供する。本実施形態では、サービス提供システム10は、このようなスキャン配信サービス及びクラウドプリントサービスを提供するものとして説明する。

0013

ただし、サービス提供システム10により提供されるサービスは、これらに限られず、例えば、外部ストレージシステム30に保存されている電子ファイルを、ユーザ環境E2のプロジェクタ投影するサービス等であってもよい。また、画像形成装置20において原稿をスキャンして生成された電子ファイルを、OCR処理した後、所定の言語に翻訳(例えば、英語から日本語に翻訳)して、外部ストレージシステム30に保存するサービス等であってもよい。

0014

なお、サービス提供システム10の全部又は一部は、ユーザ環境E2に設置されていてもよい。すなわち、サービス提供システム10を構成する情報処理装置の全部又は一部は、ユーザ環境E2に包含されていてもよい。

0015

ユーザ環境E2は、例えば画像形成装置20を使用するユーザである企業等におけるシステム環境である。ユーザ環境E2は、一台以上の画像形成装置20が例えばLAN(Local Area Network)等のネットワークを介して接続されている。

0016

本実施形態に係る画像形成装置20は、プリント機能及びスキャン機能を有する画像形成装置である。なお、画像形成装置20は、プリント機能及びスキャン機能以外に、コピー機能ファックスFAX通信機能等を備える複合機等でもよい。

0017

外部ストレージシステム30は、ネットワークを介してストレージサービス(又はオンラインストレージ)と呼ばれるクラウドサービスを提供するコンピュータシステムである。ストレージサービスとは、外部ストレージシステム30のストレージの記憶領域を貸し出すサービスである。本実施形態では、スキャン配信サービスにおいて、外部ストレージシステム30によって貸し出される記憶領域に、OCR処理された電子ファイルを保存(アップロード)する。また、本実施形態では、クラウドプリントサービスにおいて、外部ストレージシステム30によって貸し出される記憶領域から印刷対象となる電子ファイルを取得(ダウンロード)する。なお、以降では、複数の外部ストレージシステム30について、各々を区別するときは、「外部ストレージシステム301」、「外部ストレージシステム302」等と添え字を用いて記載する。また、外部ストレージシステム301によって提供されるサービスの名称を「ストレージサービスA」、ストレージシステム302によって提供されるサービスの名称を「ストレージサービスB」等とする。

0018

なお、外部ストレージシステム30は、複数台の情報処理装置によって実現されるシステムであってもよい。また、図1に示される情報処理システム1の構成は一例であって、他の構成であってもよい。例えば、上述したように、ユーザ環境E2は、画像形成装置20に加えて又は画像形成装置20に代えて、プロジェクタ、電子黒板等の各種機器を有していてもよい。

0019

<ハードウェア構成>
≪サービス提供システム≫
図1に示されるサービス提供システム10は、例えば図2に示されるようなハードウェア構成を有する。図2は、第1の実施形態に係るサービス提供システムの一例のハードウェア構成図である。図2に示すサービス提供システム10は、入力装置11と、表示装置12と、外部I/F13と、RAM(Random Access Memory)14とを有する。また、サービス提供システム10は、ROM(Read Only Memory)15と、CPU(Central Processing Unit)16と、通信I/F17と、HDD(Hard Disk Drive)18とを有する。これらの各ハードウェアは、それぞれがバスBで接続されている。

0020

入力装置11は、キーボードマウスタッチパネル等を含み、ユーザが各操作信号を入力するのに用いられる。表示装置12は、ディスプレイ等を含み、サービス提供システム10による処理結果を表示する。なお、入力装置11及び/又は表示装置12は、必要なときにサービス提供システム10に接続して利用する形態であってもよい。

0021

通信I/F17は、サービス提供システム10をネットワークN1に接続するインタフェースである。これにより、サービス提供システム10は、通信I/F17を介してデータ通信を行うことができる。

0022

HDD18は、プログラムやデータを格納している不揮発性記憶装置の一例である。格納されるプログラムやデータには、サービス提供システム10全体を制御する基本ソフトウェアであるOS(Operating System)、及びOS上において各種機能を提供するアプリケーションソフトウェア等がある。なお、サービス提供システム10は、HDD18に代え、記憶媒体としてフラッシュメモリを用いるドライブ装置(例えばソリッドステートドライブSSD)を利用するものであってもよい。また、HDD18は、格納しているプログラムやデータを所定のファイルシステム及び/又はDBにより管理している。

0023

外部I/F13は、外部装置とのインタフェースである。外部装置には、記録媒体13a等がある。これにより、サービス提供システム10は、外部I/F13を介して記録媒体13aの読み取り及び/又は書き込みを行うことができる。記録媒体13aには、フレキシブルディスク、CD、DVD、SDメモリカードUSBメモリ等がある。

0024

ROM15は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ(記憶装置)である。ROM15には、サービス提供システム10の起動時に実行されるBIOS(Basic Input/Output System)、OS設定、及びネットワーク設定等のプログラムやデータが格納されている。RAM14は、プログラムやデータを一時保持する揮発性の半導体メモリ(記憶装置)である。

0025

CPU16は、ROM15やHDD18等の記憶装置からプログラムやデータをRAM14上に読み出し、処理を実行することで、サービス提供システム10全体の制御や機能を実現する演算装置である。

0026

本実施形態に係るサービス提供システム10は、上記のハードウェア構成を有することにより、後述するような各種処理を実現できる。

0027

≪画像形成装置≫
図1に示される画像形成装置20は、例えば図3に示されるようなハードウェア構成を有する。図3は、第1の実施形態に係る画像形成装置の一例のハードウェア構成図である。図3に示す画像形成装置20は、コントローラ21と、操作パネル22と、外部I/F23と、通信I/F24と、プリンタ25と、スキャナ26とを有する。また、コントローラ21は、CPU211と、RAM212と、ROM213と、NVRAM214と、HDD215とを有する。ROM213は、各種プログラムやデータが格納されている。RAM212はプログラムやデータを一時保持する。NVRAM214は、例えば設定情報等が格納されている。また、HDD215は各種プログラムやデータが格納されている。

0028

CPU211は、ROM213やNVRAM214、HDD215等からプログラムやデータ、設定情報等をRAM212上に読み出し、処理を実行することで、画像形成装置20全体の制御や機能を実現する。

0029

操作パネル22は、ユーザからの入力を受け付ける入力部と、表示を行う表示部とを備えている。外部I/F23は、外部装置とのインタフェースである。外部装置には、記録媒体23a等がある。これにより、画像形成装置20は、外部I/F23を介して記録媒体23aの読み取り及び/又は書き込みを行うことができる。記録媒体23aにはICカード、フレキシブルディスク、CD、DVD、SDメモリカード、USBメモリ等がある。

0030

通信I/F24は、画像形成装置20をネットワークN1に接続するインタフェースである。これにより、画像形成装置20は通信I/F24を介してデータ通信を行うことができる。プリンタ25は、印刷データを印刷するための印刷装置である。スキャナ26は原稿を読み取り画像ファイル(電子ファイル)を生成するための読取装置である。

0031

本実施形態に係る画像形成装置20は、上記のハードウェア構成を有することにより、後述するような各種処理を実現できる。

0032

ソフトウェア構成
第1の実施形態に係る情報処理システム1は、例えば図4に示されるような処理ブロックにより実現することができる。図4は、第1の実施形態に係る情報処理システムの一例の処理ブロック図である。

0033

画像形成装置20は、例えばCPU211等により実現されるブラウザ210を有する。画像形成装置20のユーザは、ブラウザ210を介して、サービス提供システム10により提供されるサービスを利用することができる。このように、本実施形態に係る画像形成装置20では、ブラウザ210が搭載されていればよく、サービスを利用するための専用のアプリケーションを開発等する必要がない。

0034

サービス提供システム10は、サービス処理部110と、ドキュメントサービス部150と、ストレージサービス連携部160とを有する。これら各部は、例えばCPU16等により実現される。

0035

また、サービス提供システム10は、アプリ情報記憶部190を有する。このアプリ情報記憶部190は、HDD18により実現される。なお、アプリ情報記憶部190は、サービス提供システム10とネットワークを介して接続される記憶装置等により実現されてもよい。

0036

サービス処理部110は、アプリ管理部120と、ロジック処理部130と、データI/F部140とを有する。

0037

アプリ管理部120は、アプリ情報記憶部190に記憶されているアプリ情報1000を管理する。アプリ管理部120は、ブラウザ210からの要求に応じて、アプリ情報1000に含まれる画面定義に基づくアプリ画面を返信する。これにより、画像形成装置20のブラウザ210には、サービス提供システム10により提供されるサービスを利用するためのアプリ画面が表示される。ここで、アプリ情報1000は、詳細は後述するが、上述したアプリ画面を画像形成装置20に表示させるための画面定義と、当該アプリ情報1000により実現されるサービスの処理内容とが記述された情報である。

0038

また、アプリ管理部120は、ロジック処理部130からの要求に応じて、アプリ情報1000に含まれる処理内容を返信する。処理内容は、詳細は後述するが、スキャン配信サービスやクラウドプリントサービス等を実現するための一連の処理が記述されている。なお、一連の処理は、「処理フロー」又は「フロー」とも称される。

0039

ロジック処理部130は、ブラウザ210からの要求に応じて、アプリ管理部120から処理内容を取得する。そして、ロジック処理部130は、取得した処理内容に従ってドキュメントサービス部150又は/及びストレージサービス連携部160のファイル処理部170に対して、処理の実行を要求する。これにより、サービス提供システム10による各種サービスが、画像形成装置20に提供される。なお、ロジック処理部130の詳細な処理ブロックについては、後述の<処理の詳細>の中で説明する。

0040

データI/F部140は、ブラウザ210からの要求に応じて、ストレージサービス連携部160のデータ処理部180に対して、例えばフォルダ一覧の取得等を要求する。

0041

ドキュメントサービス部150は、サービス提供システム10により提供されるサービスを実現するためのプログラム(モジュール)群である。ドキュメントサービス部150には、例えば、電子ファイルに対してOCR処理を実行するOCR処理151や電子ファイルを画像形成装置20が印刷可能なデータ形式(印刷データ)に変換する印刷変換処理152等が含まれる。ドキュメントサービス部150には、これら以外にも、例えば、電子ファイルの圧縮又は解凍するためのプログラム、電子ファイルのデータ形式を変換(例えばPDF形式に変換)するためのプログラム等、各種の処理を実行するプログラムが含まれていてもよい。

0042

ストレージサービス連携部160は、ロジック処理部130及びデータI/F部140からの要求に応じて、外部ストレージシステム30に対して、各種処理の実行を要求する。ここで、サービス提供システム10は、外部ストレージシステム30毎に、ストレージサービス連携部160をそれぞれ有する。すなわち、サービス提供システム10は、外部ストレージシステム301に対して処理を要求するためのストレージサービスA連携部1601、外部ストレージシステム302に対して処理を要求するためのストレージサービスB連携部1602等を有する。このように、サービス提供システム10は、連携して処理を行う外部ストレージシステム30毎に、それぞれ対応するストレージサービス連携部160を有する。なお、以降では、複数のストレージサービス連携部160について、各々を区別するときは、上記のように「ストレージサービスA連携部1601」、「ストレージサービスB連携部1602」等と添え字を用いて記載する。

0043

ストレージサービス連携部160は、上述したように、ロジック処理部130からの要求を受け付けるファイル処理部170と、データI/F部140からの要求を受け付けるデータ処理部180とを有する。

0044

ファイル処理部170は、外部ストレージシステム30に保存されている電子ファイルに対する操作(例えば、取得、保存、編集等)を行うためのAPI(Application Programming Interface)が定義された共通I/F171及び固有I/F172を有する。共通I/F171は、複数の外部ストレージシステム30間で共通に利用できるAPIであり、例えば図5(a)に示すようなAPIが挙げられる。換言すれば、ファイル処理部170の共通I/F171は、すべての外部ストレージシステム30が利用できるファイル操作に関する機能(例えば、ファイルの取得、保存等)を利用するためのAPI群である。一方、固有I/F172は、特定の外部ストレージシステム30において利用できるAPIであり、例えば図5(b)に示すようなAPIが挙げられる。換言すれば、ファイル処理部170の固有I/F172は、ある特定の外部ストレージシステム30において利用できるファイル操作に関する機能(例えば、ファイルの編集等)を利用するためのAPI群である。したがって、共通I/F171は、すべてのストレージサービス連携部160に対して同様に定義される一方、固有I/F172は、当該固有I/F172で定義されるAPIが利用可能な特定のストレージサービス連携部160に対して定義される。

0045

一方、データ処理部180は、外部ストレージシステム30に保存されている電子ファイルの書誌情報等のメタデータ(例えば、ファイル一覧、フォルダ一覧等)を取得等するためのAPIが定義された共通I/F181及び固有I/F182を有する。共通I/F181は、複数の外部ストレージシステム30間で共通に利用できるAPIであり、例えば図5(c)に示すようなAPIが挙げられる。換言すれば、データ処理部180の共通I/F181は、すべての外部ストレージシステム30で利用できるメタデータ取得等の機能を利用するためのAPI群である。一方、固有I/F182は、ある特定の外部ストレージシステム30において利用できるAPIであり、例えば図5(d)に示すようなAPIが挙げられる。換言すれば、データ処理部180の固有I/F182は、ある特定の外部ストレージシステム30において利用できるメタデータ取得等の機能(例えば、画像ファイル一覧の取得等)を利用するためのAPI群である。したがって、共通I/F181は、すべてのストレージサービス連携部160に対して同様に定義される一方、固有I/F182は、当該固有I/F182で定義されるAPIが利用可能な特定のストレージサービス連携部160に対して定義される。

0046

以上のように、本実施形態に係るサービス提供システム10は、連携して処理を行う外部ストレージシステム30毎に、それぞれストレージサービス連携部160を有する。このため、連携先となる外部ストレージシステム30が追加等する場合には、対応するストレージサービス連携部160をサービス提供システム10に追加等すればよい。したがって、連携先となる外部ストレージシステム30の追加等に伴う影響を局所化することができる。換言すれば、他の処理ブロック(サービス処理部110やドキュメントサービス部150等)に影響を与えることなく(すなわち、他の処理ブロックを修正等する必要なく)、連携先となる外部ストレージシステム30の追加等を行うことができる。これにより、連携先の外部ストレージシステム30の追加等の開発に要する工数を削減することができる。なお、ストレージサービス連携部160の追加等は、SDK(Software Development Kit)を用いて行うことができる。

0047

また、ストレージサービス連携部160は、共通I/F171と固有I/F172とを異なるモジュール等で定義している。また、共通I/F171及び固有I/F172で定義されるAPIは、「ストレージサービス名」を指定することで利用することができる(すなわち、「ストレージサービス名」が可変部分となっている)。したがって、連携先の外部ストレージシステム30を追加する場合には、他のストレージサービス連携部160に定義されている共通I/F171を再利用することができる。換言すれば、連携先の外部ストレージシステム30を追加する場合には、当該追加する外部ストレージシステム30の固有I/F172のみ開発すればよい。これにより、連携先の外部ストレージシステム30の追加等の開発に要する工数をさらに削減することができる。なお、このことは共通I/F181と固有I/F182に関しても同様である。

0048

アプリ情報記憶部190は、アプリ情報1000を記憶する。アプリ情報1000は、アプリ画面を画像形成装置20に表示させるための画面定義と、サービスを実現するため一連の処理を示す処理内容とが記述された情報であり、アプリ情報1000を一意に識別するためのアプリID毎に、アプリ情報記憶部190に記憶されている。本実施形態では、クラウドサービスAと連携したスキャン配信サービスを実現するためのアプリ情報を「アプリ情報10001」とし、このアプリ情報10001のアプリID「app001」とする。また、本実施形態では、クラウドサービスAと連携したクラウドプリントサービスを実現するためのアプリ情報を「アプリ情報10002」、このアプリ情報10002のアプリIDを「app002」とする。

0049

ここで、アプリ情報10001の画面定義に含まれるデータ定義及びアプリ情報10002の画面定義に含まれるデータ定義を、それぞれ図6(a)及び図6(b)に示す。データ定義は、画像形成装置20のブラウザ210により操作パネル22等に表示されるアプリ画面の入力欄入力ボックス)や選択欄選択ボックス)等を構成するための情報が記述されている。例えば、図6(a)におけるデータ定義部1101では、ユーザがスキャンにより生成される電子ファイルのファイル名を入力するための入力欄を構成するための情報が記述されている。また、データ定義部1102では、ストレージサービスAにおける保存先フォルダを選択するための選択欄を構成するための情報が記述されている。なお、データ定義部1102の「data_source」には選択欄の各選択要素(ここでは、保存先候補フォルダ名及びフォルダID)の取得先のURL(Uniform Resource Locator)が記述されている。

0050

次に、アプリ情報10001の画面定義に含まれるレイアウト情報及びアプリ情報10002の画面定義に含まれるレイアウト情報を、それぞれ図7(a)及び図7(b)に示す。レイアウト情報は、画像形成装置20のブラウザ210により操作パネル22等に表示されるアプリ画面に表示される文字(入力欄の表示名称等)、入力欄や選択欄の表示位置等の情報が記述されている。例えば、図7(a)におけるレイアウト定義部1301では、データ定義における「"data_id":1」(すなわち、データ定義部1101)の表示位置及び表示名称の情報が記述されている。これにより、具体例は後に示すが、アプリ画面には、表示名称が「ファイル名」である入力欄が、1番目の位置に表示される。また、レイアウト定義部1302では、データ定義における「"data_id":2」(すなわち、データ定義部1102)の表示位置及び表示名称の情報が記述されている。これにより、具体例は後に示すが、アプリ画面には、表示名称が「保存先フォルダ選択」である選択欄が、2番目の位置に表示される。

0051

次に、アプリ情報10001の処理内容及びアプリ情報10002の処理内容を、それぞれ図8(a)及び図8(b)に示す。処理内容は、サービス提供システム10により提供されるサービスを実現するために、ドキュメントサービス部150やストレージサービス連携部160に要求する一連の処理が記述されている。例えば、図8(a)に示す処理内容には、本実施形態に係るスキャン配信サービスを実現するための一連の処理(すなわち、スキャンされた電子ファイルをOCR処理した後、ストレージサービスAの指定されたフォルダに配信する一連の処理)が記述されている。また、図8(b)に示す処理内容には、本実施形態に係るクラウドプリントサービスを実現するための一連の処理(すなわち、ストレージサービスAから取得した電子ファイルを印刷データに変換した後、画像形成装置20に送信する一連の処理)が記述されている。これらの処理内容についての詳細については、後述する。

0052

以上のように、本実施形態に係るサービス提供システム10は、画像形成装置20にアプリ画面を表示させるための画面定義と、サービスを実現するための一連の処理内容とが記述されたアプリ情報1000を利用してサービスを提供する。このため、サービス提供システム10により提供されるサービスを追加等する場合には、アプリ情報記憶部190にアプリ情報1000を追加等すればよい。また、アプリ情報1000を追加するには、上述したように、画面定義と処理内容とを記述すればよいため、簡易に開発することができる。したがって、サービスの追加・変更等に伴う開発工数を削減させることができるとともに、例えばサードベンダー等によるサービスの追加・変更等を容易に行うことができる。

0053

<処理の詳細>
次に、本実施形態に係る情報処理システム1の処理の詳細について説明する。

0054

≪スキャン配信サービスの全体処理≫
まず、画像形成装置20のユーザが本実施形態に係るスキャン配信サービスを利用する場合の全体的な処理について説明する。図9は、第1の実施形態に係るスキャン配信サービスの全体処理の一例のシーケンス図である。

0055

まず、画像形成装置20のユーザは、ブラウザ210を用いて、サービス提供システム10により提供されるサービスの一覧を取得するための操作を行う。すると、画像形成装置20は、サービスの一覧の取得要求をサービス提供システム10のサービス処理部110に送信する(ステップS901)。そして、サービス処理部110のアプリ管理部120は、当該取得要求を受信すると、サービス提供システム10により提供されるサービスの一覧を画像形成装置20に送信する。これにより、画像形成装置20のブラウザ210により、画像形成装置20の操作パネル22にサービス提供システム10により提供されるサービスの一覧が表示される。なお、サービスの一覧には、サービス提供システム10により提供されるサービスのサービス名と、このサービスを実現するためのアプリ情報1000のアプリIDとが含まれる。

0056

ユーザは、画像形成装置20の操作パネル22に表示されたサービスの一覧から、自身が利用を所望するサービスを選択する。すると、ブラウザ210は、選択されたサービスを実現するためのアプリ情報1000のアプリIDをアプリ管理部120に送信する(ステップS902)。ここでは、ユーザによりサービス名「スキャン配信サービス」の利用が選択されたものとする。したがって、ブラウザ210は、アプリ情報10001のアプリID「app001」をアプリ管理部120に送信する。

0057

そして、アプリ管理部120は、ブラウザ210から受け取ったアプリID「app001」のアプリ情報10001に含まれる画面定義に基づきHTML(HyperText Markup Language)形式のアプリ画面を生成し、ブラウザ210に送信する。

0058

ブラウザ210は、アプリ管理部120からアプリ画面を受け取ると、表示用情報の取得をデータI/F部140に要求する(ステップS903)。ここで表示用情報とは、例えばアプリ画面の選択欄の各選択要素のことである。すなわち、本実施形態では、ブラウザ210は、スキャン配信の配信先保存先)となるストレージサービスAのフォルダの一覧の取得を、データI/F部140に要求する。このような要求は、図6(a)のデータ定義部1102に記述されている「"data_source"」に定義されているURL「http://sample.xxx.co.jp/service-a/data/folders」にHTTPリクエストを送信することで行うことができる。なお、当該URLのうち、「http://sample.xxx.co.jp」の部分がサービス提供システム10のホスト名、「/service-a/data/folders」の部分がストレージサービス連携部160におけるAPI(すなわち、図5に示すAPI)の指定となる。

0059

次に、データI/F部140は、ブラウザ210から表示用情報の取得要求を受け付けると、当該要求を対応するストレージサービス連携部160のデータ処理部180に送信する(ステップS904)。本実施形態では、データI/F部140は、上記のURLに含まれる「service-a」(ストレージサービス名)に基づき、当該要求を、ストレージサービスA連携部1601のデータ処理部1801に送信する。

0060

データ処理部180は、データI/F部140から要求を受け付けると、当該要求に含まれるURLに基づき、対応する処理要求を外部ストレージシステム30に送信する(ステップS905)。すなわち、データ処理部180は、データI/F部140から受け付けた要求に含まれるURLに基づき、共通I/F181又は固有I/F182に定義されているAPIを利用して、該当の外部ストレージシステム30に処理を要求する。本実施形態では、上記のURLに含まれる「/service-a/data/folders」に基づき、データ処理部180は、共通I/F181に定義されているAPIを用いて、ストレージサービスAにフォルダ一覧の取得を要求する。すると、ブラウザ210は、ストレージサービスA連携部1601を介して、フォルダ一覧を受信する。フォルダ一覧は、本実施形態のスキャン配信サービスにおいて、電子ファイルの保存先の候補となるストレージサービスAのフォルダ名及びフォルダID等の情報である。

0061

次に、ブラウザ210は、ステップS902でアプリ管理部120から受け取ったアプリ画面及びフォルダ一覧に基づき、例えば図10(a)に示すようなアプリ画面2000を、操作パネル22に表示させる(ステップS906)。

0062

ここで、図10(a)で示すスキャン配信サービスを利用するためのアプリ画面2000は、ファイル名入力欄2001と、保存先フォルダ選択欄2002と、スキャン実行ボタン2003とから構成されている。このうち、ファイル名入力欄2001及び保存先フォルダ選択欄2002は、図10(b)に示すように、それぞれHTMLソースコード2101及び2102で記述されている。このようなHTMLソースコード2101及び2102は、アプリ管理部120により、図6(a)に示すデータ定義部1101及び1102並びに図7(b)に示すレイアウト定義部1301及び1302に基づいて生成される。ただし、HTMLソースコード2102に指定されている「option」の設定値は、外部ストレージシステム30から取得したフォルダ一覧に基づき、ブラウザ210で設定される。このように、アプリ画面2000は、アプリ情報10001の画面定義に基づきアプリ管理部120で生成されたHTMLに対して、外部ストレージシステム301から取得したフォルダ一覧の情報を設定することで生成される。

0063

次に、ユーザは、図10(a)のアプリ画面2000において、ファイル名入力欄2001に所望のファイル名を入力して、保存先フォルダ選択欄2002から所望の保存先フォルダを選択する。そして、画像形成装置20のスキャナ26に原稿をセットして、スキャン実行ボタン2003を押下する(ステップS907)。ここで、ユーザはファイル名入力欄2001にファイル名「test」を入力し、保存先フォルダ選択欄2002から「FolderB」を選択して、スキャン実行ボタン2003を押下したものとする。これにより、画像形成装置20のスキャナ26により原稿が読み取られ、ファイル名「test」の電子ファイルが生成される(ステップS908)。

0064

すると、ブラウザ210は、スキャン配信サービスの処理の実行要求をロジック処理部130に送信する(ステップS909)。ここで、当該実行要求には、アプリID「app001」と、上記のステップS908で生成された電子ファイルと、選択された保存先フォルダ「FolderB」のフォルダID「folder_id_b」とが含まれる。

0065

そして、ロジック処理部130は、処理の実行要求を受け付けると、アプリ管理部120を介して、当該処理の実行要求に含まれるアプリIDのアプリ情報1000から処理内容を取得し、当該処理内容に従って処理を実行する(ステップS910)。すなわち、本実施形態に係るスキャン配信サービスでは、当該処理の実行要求に含まれる電子ファイルに対してOCR処理を行った後、ストレージサービスAのフォルダ「FolderB」に対して当該OCR処理後の電子ファイルを配信(アップロード)する。このステップS910の処理の詳細については、後述する。ここでは、ロジック処理部130は、OCR処理後の電子ファイルと、フォルダ「FolderB」のフォルダID「folder_id_b」とを含む配信実行の要求を、ストレージサービスA連携部1601のファイル処理部1701に送信したものとして説明を続ける。

0066

ファイル処理部170は、ロジック処理部130から配信実行の要求を受け付けると、共通I/F171又は固有I/F172に定義されているAPIを利用して、該当の外部ストレージシステム30に処理を要求する(ステップS911)。具体的には、本実施形態では、ファイル処理部1701の共通I/F1711に定義されているストレージサービスAにファイルを保存するためのAPI「/service-a/process/folder」を用いて、当該電子ファイルをフォルダ「FolderB」に配信(アップロード)する。そして、電子ファイルのアップロードが完了すると、処理結果がブラウザ210に表示される。これにより、本実施形態に係るスキャン配信サービスが完了する。

0067

≪OCRから配信実行までの処理≫
次に、図9のステップS910の処理の詳細について説明する。この処理は、主に、ロジック処理部130により実行される。したがって、図9のステップS910の処理の詳細について説明するに前に、ロジック処理部130の詳細な処理ブロックについて説明する。図11は、第1の実施形態に係るロジック処理部の一例の処理ブロック図である。ロジック処理部130は、フロー実行部131と、コンポーネント管理部132と、コンポーネント群133と、型変換管理部134と、型変換群135とを有する。また、ロジック処理部130は、型変換テーブル3000を利用する。

0068

フロー実行部131は、ブラウザ210からスキャン配信サービスの処理の実行要求を受け付けると、アプリ管理部120を介して、アプリ情報1000から処理内容を取得する。そして、フロー実行部131は、取得した処理内容に従ってコンポーネントに対して処理の実行を要求する。なお、ここで、コンポーネントとは、各種処理を実行するためのプログラム(モジュール)であり、例えばクラスや関数等で定義される。

0069

コンポーネント管理部132は、フロー実行部131からの要求に応じて、コンポーネントの生成を行う。なお、コンポーネントの生成とは、例えばクラスで定義されたコンポーネントを、メモリ(例えばRAM14)上に展開することを意味する。

0070

コンポーネント群133は、コンポーネントの集合である。コンポーネント群133には、外部ストレージシステム30に電子ファイルを配信するための配信コンポーネント1331、外部ストレージシステム30から電子ファイルを取得するための取得コンポーネント1332が含まれる。また、コンポーネント群133には、電子ファイルにOCR処理を行うためのOCRコンポーネント1333、電子ファイルを印刷データに変換するための印刷変換コンポーネント1334が含まれる。

0071

さらに、これらの各コンポーネントは、コンポーネント共通I/F1330を有する。コンポーネント共通I/F1330は、各コンポーネントに対して共通に定義されたAPIであり、コンポーネントを生成するためのAPIと、コンポーネントに対して処理の実行を要求するためのAPIとが含まれる。このように、各コンポーネントがコンポーネント共通I/F1330を有するようにすることで、コンポーネントの追加等に伴う影響を局所化することができる。換言すれば、フロー実行部131及びコンポーネント管理部132に影響を与えることなく、コンポーネントの追加等を行うことができる。これにより、コンポーネントの追加等の開発に要する工数を削減することができる。

0072

型変換管理部134は、データ型の型変換を管理する。ここで、各コンポーネントは、自身が扱えるデータ型が予め定まっている。したがって、型変換管理部134は、コンポーネントからの要求に応じて、図12に示すような型変換テーブル3000を参照して、型変換群135に定義されている型変換を生成する。そして、型変換管理部134は、生成された型変換に対して型変換処理の実行を要求する。ここで、型変換とは、データ型の型変換処理を実行するためのプログラム(モジュール)であり、例えばクラスや関数等で定義される。

0073

なお、型変換の生成とは、例えばクラスで定義された型変換を、メモリ(例えばRAM14)上に展開することを意味する。また、データ型には、例えば、ストリームデータを示すデータ型「InputStream」、記憶装置等に格納されている電子ファイルのパスアドレス)を示す「LocalFilePath」、電子ファイルの実体を示す「File」等が挙げられる。

0074

型変換群135は、型変換の集合である。型変換群135には、データ型「InputStream」を「LocalFilePath」に変換する第1の型変換1351、「LocalFilePath」を「File」に変換する第2の型変換1352等が含まれる。

0075

さらに、これらの各型変換は、型変換共通I/F1350を有する。型変換共通I/F1350は、各型変換に対して共通に定義されたAPIであり、型変換を生成するためのAPIと、型変換に対して処理の実行を要求するためのAPIとが含まれる。このように、各型変換が型変換共通I/F1350を有するようにすることで、型変換の追加等に伴う影響を局所化することができる。換言すれば、型変換管理部134に影響を与えることなく、コンポーネントの追加等を行うことができる。これにより、型変換の追加等の開発に要する工数を削減することができる。

0076

続いて、図9のステップS910の処理の詳細について、図13を用いて説明する。図13は、第1の実施形態に係るOCRから配信実行までの処理の一例のシーケンス図である。

0077

まず、フロー実行部131は、ブラウザ210からスキャン配信サービスの処理の実行要求を受け付ける(ステップS1301)。ここで、当該実行要求には、アプリID「app001」と、図9のステップS908で生成された電子ファイルと、選択された保存先フォルダ「FolderB」のフォルダID(保存先)とが含まれる。ここで、当該電子ファイルは、データ型が「InputStream」(すなわち、ストリームデータ)としてブラウザ210から渡されるものとする。

0078

フロー実行部131は、当該実行要求を受け付けると、アプリ管理部120に処理内容の取得を要求する(ステップS1302)。ここで、当該処理内容の取得要求には、アプリID「app001」が含まれる。そして、フロー実行部131は、アプリ管理部120からアプリID「app001」に対応するアプリ情報10001に含まれる処理内容を取得する。すなわち、フロー実行部131は、図8(a)に示す処理内容を取得する。

0079

フロー実行部131は、取得した処理内容に従ってコンポーネントの取得を、コンポーネント管理部132に要求する(ステップS1303)。より具体的には、フロー実行部131は、図8(a)に示す処理内容の「From("file:input")」の次に指定されている「.to("process:ocr")」に基づき、OCRコンポーネント1333の取得を、コンポーネント管理部132に要求する。

0080

コンポーネント管理部132は、OCRコンポーネント1333の取得要求を受け付けると、OCRコンポーネント1333を生成する(ステップS1304)。OCRコンポーネント1333の生成は、コンポーネント共通I/F1330に定義されたコンポーネントを生成するためのAPIを用いて行うことができる。そして、OCRコンポーネント1333が生成されると、コンポーネント管理部132は、OCRコンポーネント1333をフロー実行部131に返却する。これは、例えば、コンポーネント管理部132は、OCRコンポーネント1333が展開されたメモリ(例えばRAM14)上のアドレスを、フロー実行部131に返却する。

0081

フロー実行部131は、生成されたOCRコンポーネント1333に対して、データを指定して処理の実行を要求する(ステップS1305)。なお、ここで指定されるデータは、データ型が「InputStream」としてブラウザ210から渡される電子ファイルである。すなわち、フロー実行部131は、ブラウザ210からデータ型「InputStream」として渡される電子ファイルを、単に「データ」として(データ型を意識することなく)、OCRコンポーネント1333に渡して処理の実行を要求する。図13では、このようにデータ型を意識することなく渡される電子ファイル等を、単に「データ」と表す。

0082

OCRコンポーネント1333は、型変換管理部134に対して、型変換を要求する(ステップS1306)。ここで、当該型変換要求には、データと、OCRコンポーネント1333が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。

0083

型変換管理部134は、受け取った型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする(ステップS1307)。ここでは、受け取った型変換要求に含まれるデータのデータ型は「InputStream」である一方、指定されたデータ型は「LocalFilePath」であるから、一致しないものと判断される。

0084

すると、型変換管理部134は、型変換テーブル3000を参照して、「InputStream」を「LocalFilePath」に変換するための型変換を特定して(ここでは、第1の型変換1351が特定される)、当該特定された型変換を生成する(ステップS1308)。

0085

そして、型変換管理部134は、生成された第1の型変換1351に対して、データを指定して型変換処理の実行を要求する(ステップS1309)。そして、第1の型変換1351は、指定されたデータのデータ型を「InputStream」から「LocalFilePath」に変換して(ステップS1310)、当該変換後のデータを型変換管理部134に返信する。その後、型変換管理部134は、型変換後のデータをOCRコンポーネント1333に送信する(ステップS1311)。

0086

OCRコンポーネント1333は、型変換後のデータを受け取ると、処理を実行する(ステップS1312)。すなわち、データ型「LocalFilePath」のデータ(すなわち、パス又はアドレス)により示される電子ファイルに対して、OCR処理を実行する。ここで、より具体的には、OCRコンポーネント1333は、ドキュメントサービス部150のOCR処理151に処理を要求し、OCR処理151が当該電子ファイルに対して処理を実行する。そして、OCRコンポーネント1333は、データをフロー実行部131に返信する。なお、ここで、返信されるデータは、OCR処理後の電子ファイルを示すパス又はアドレスである(すなわち、返信されるデータのデータ型は「LocalFilePath」である。)。

0087

次に、フロー実行部131は、取得した処理内容に従ってコンポーネントの取得を、コンポーネント管理部132に要求する(ステップS1313)。より具体的には、フロー実行部131は、図8(a)に示す処理内容の「.to("process:ocr")」の次に指定されている「.to("storage:send_to_folder?type=service-a")」に基づき、配信コンポーネント1331の取得を、コンポーネント管理部132に要求する。なお、ここで、指定されている処理内容のうち「?type=service-a」の部分はオプションパラメータであり、配信コンポーネント1331の処理によるデータのアップロード先のストレージサービスが「ストレージサービスA」であることを示している。また、ここで、上記の指定されている処理内容に、上記のステップS1301の実行要求に含まれる保存先(保存先フォルダのフォルダID)をオプションパラメータとして付加して「.to("storage:send_to_folder? type=service-a&targetfolder=folder_id_b")」としてもよい。同様に、ファイル名をオプションパラメータとしてさらに付加して「.to("storage:send_to_folder? type=service-a&targetfolder=folder_id_b&filename=test.pdf")」としてもよい。

0088

コンポーネント管理部132は、配信コンポーネント1331の取得要求を受け付けると、配信コンポーネント1331を生成する(ステップS1314)。配信コンポーネント1331の生成は、コンポーネント共通I/F1330に定義されたコンポーネントを生成するためのAPIを用いて行うことができる。そして、配信コンポーネント1331が生成されると、コンポーネント管理部132は、配信コンポーネント1331をフロー実行部131に返却する。これは、例えば、コンポーネント管理部132は、配信コンポーネント1331が展開されたメモリ(例えばRAM14)上のアドレスを、フロー実行部131に返却する。

0089

フロー実行部131は、生成された配信コンポーネント1331に対して、データを指定して処理の実行を要求する(ステップS1315)。なお、ここで指定されたデータのデータ型は「LocalFilePath」である。

0090

配信コンポーネント1331は、型変換管理部134に対して、型変換を要求する(ステップS1316)。ここで、当該型変換要求には、データと、配信コンポーネント1331が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。

0091

型変換管理部134は、受け取った型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする(ステップS1317)。ここでは、受け取った型変換要求に含まれるデータのデータ型は「LocalFilePath」であり、指定されたデータ型も「LocalFilePath」であるから、一致するものと判断される。そして、型変換管理部134は、型変換要求に含まれていたデータを、そのまま配信コンポーネント1331に送信する(ステップS1318)。このように、データ型チェック(ステップS1317の処理)で両者のデータ型が一致する場合には、型変換管理部134は型変換の生成を行わない。

0092

配信コンポーネント1331は、型変換管理部134からデータを受け取ると、処理を実行する(ステップS1319)。すなわち、本実施形態では、配信コンポーネント1331は、ストレージサービスA連携部1601のファイル処理部1701に対して、共通I/F1711として定義されているファイル保存のAPIを用いて、データの配信実行を要求する。より具体的には、配信コンポーネント1331は、ストレージサービスA連携部1601のファイル処理部1701に対して、図5(a)に示されるようにAPIとして「service-a/process/folder」を用いてデータの配信実行を要求する。これにより、ストレージサービスAのフォルダ「FolderB」に、ファイル名「test」の電子ファイル(スキャンにより生成された電子ファイルに対してOCR処理した電子ファイル)が保存される。そして、処理結果がフロー実行部131を介して、ブラウザ210に送信される。

0093

≪クラウドプリントサービスの全体処理≫
次に、画像形成装置20のユーザが本実施形態に係るクラウドプリントサービスを利用する場合の全体的な処理について説明する。図14は、第1の実施形態に係るクラウドプリントサービスの全体処理の一例のシーケンス図である。

0094

まず、画像形成装置20のユーザは、ブラウザ210を用いて、サービス提供システム10により提供されるサービスの一覧を取得するための操作を行う。すると、画像形成装置20は、サービスの一覧の取得要求をサービス提供システム10のサービス処理部110に送信する(ステップS1401)。そして、サービス処理部110のアプリ管理部120は、当該取得要求を受信すると、サービス提供システム10により提供されるサービスの一覧を画像形成装置20に送信する。

0095

ユーザは、画像形成装置20の操作パネル22に表示されたサービスの一覧から、自身が利用を所望するサービスを選択する。すると、ブラウザ210は、選択されたサービスを実現するためのアプリ情報1000のアプリIDをアプリ管理部120に送信する(ステップS1402)。ここでは、ユーザによりサービス名「クラウドプリントサービス」の利用が選択されたものとする。したがって、ブラウザ210は、アプリ情報10002のアプリID「app002」をアプリ管理部120に送信する。

0096

そして、アプリ管理部120は、ブラウザ210から受け取ったアプリID「app002」のアプリ情報10002に含まれる画面定義に基づきHTML形式のアプリ画面を生成し、ブラウザ210に送信する。

0097

ブラウザ210は、アプリ管理部120からアプリ画面を受け取ると、表示用情報の取得をデータI/F部140に要求する(ステップS1403)。本実施形態では、ブラウザ210は、クラウドプリントサービスを用いた印刷対象の候補となるストレージサービスAの電子ファイルの一覧の取得を、データI/F部140に要求する。このような要求は、図6(b)のデータ定義部1201に記述されている「"data_source"」に定義されているURL「http://sample.xxx.co.jp/service-a/data/files」にHTTPリクエストを送信することで行うことができる。

0098

次に、データI/F部140は、ブラウザ210から表示用情報の取得要求を受け付けると、当該要求を対応するストレージサービス連携部160のデータ処理部180に送信する(ステップS1404)。

0099

データ処理部180は、データI/F部140から要求を受け付けると、当該要求に含まれるURLに基づき、対応する処理要求を外部ストレージシステム30に送信する(ステップS1405)。本実施形態では、データ処理部180は、上記のURLに含まれる「/service-a/data/files」に基づき、ストレージサービスAにファイル一覧の取得を要求する。すると、ブラウザ210は、ストレージサービスA連携部1601を介して、ファイル一覧を受信する。ファイル一覧は、本実施形態のクラウドプリントサービスにおいて、印刷対象の候補となるストレージサービスAに保存されている電子ファイルのファイル名及びファイルID等の情報である。

0100

次に、ブラウザ210は、ステップS1402でアプリ管理部120から受け取ったアプリ画面及びファイル一覧に基づき、例えば図15(a)に示すようなアプリ画面4000を、操作パネル22に表示させる(ステップS1406)。

0101

ここで、図15(a)で示すクラウドプリントサービスを利用するためのアプリ画面4000は、印刷対象のファイルを選択するためのファイル選択欄4001と、プリント実行タン4002とから構成されている。このうち、ファイル選択欄4001は、図15(b)に示すように、HTMLソースコード4101で記述されている。このようなHTMLソースコード4101は、アプリ管理部120により、図6(b)に示すデータ定義部1201及び図7(b)に示すレイアウト定義部1401に基づいて生成される。ただし、HTMLソースコード4101に指定されている「option」の設定値は、外部ストレージシステム30から取得したファイル一覧に基づき、ブラウザ210で設定される。

0102

次に、ユーザは、図15(a)のアプリ画面4000のファイル選択欄4001から所望のファイルを選択して、プリント実行ボタン4002を押下する(ステップS1407)。ここで、ユーザはファイル選択欄4001から「FileA」を選択して、プリント実行ボタン4002を押下したものとする。

0103

すると、ブラウザ210は、クラウドプリントサービスの処理の実行要求をロジック処理部130に送信する(ステップS1408)。ここで、当該実行要求には、アプリID「app002」と、ファイル選択欄4001から選択されたファイル「FileA」のファイルID「file_id_a」とが含まれる。

0104

そして、ロジック処理部130は、処理の実行要求を受け付けると、アプリ管理部120を介して、当該処理の実行要求に含まれるアプリIDのアプリ情報1000から処理内容を取得し、当該処理内容に従って処理を実行する(ステップS1409)。すなわち、本実施形態に係るクラウドプリントサービスでは、ストレージサービスAから印刷対象の電子ファイルを取得(ダウンロード)した後、当該電子ファイルを画像形成装置20が印刷可能な印刷データに変換(印刷変換)する。このステップS1409の処理の詳細については、後述する。ここでは、ロジック処理部130は、ファイル「FileA」のファイルID「file_id_a」を含むファイル取得実行の要求を、ストレージサービスA連携部1601のファイル処理部1701に送信したものとして説明を続ける。

0105

ファイル処理部170は、ロジック処理部130からファイル取得実行の要求を受け付けると、共通I/F171又は固有I/F172に定義されているAPIを利用して、該当の外部ストレージシステム30に処理を要求する(ステップS1410)。具体的には、本実施形態では、ファイル処理部1701の共通I/F1711に定義されているストレージサービスAにファイルを取得するためのAPI「/service-a/process/file」を用いて、ファイル「FileA」を取得(ダウンロード)する。そして、ロジック処理部130は、取得したファイル「FileA」を、画像形成装置20で印刷可能なデータ形式である印刷データに変換した後、画像形成装置20に送信する。

0106

画像形成装置20のプリンタ25は、ロジック処理部130から印刷データを受け取ると、当該印刷データを印刷する(ステップS1411)。これにより、本実施形態に係るクラウドプリントサービスが完了する。

0107

≪ファイル取得実行から印刷変換までの処理≫
次に、図14のステップS1409の処理の詳細について説明する。図16は、第1の実施形態に係るファイル取得から印刷変換までの処理の一例のシーケンス図である。

0108

まず、フロー実行部131は、ブラウザ210からクラウドプリントサービスの処理の実行要求を受け付ける(ステップS1601)。ここで、当該実行要求には、アプリID「app002」と、選択された印刷対象のファイルのファイルID「file_id_a」とが含まれる。ここで、当該ファイルIDは、データ型が「InputStream」(すなわち、ストリームデータ)としてブラウザ210から渡されるものとする。

0109

フロー実行部131は、当該実行要求を受け付けると、アプリ管理部120に処理内容の取得を要求する(ステップS1602)。ここで、当該処理内容の取得要求には、アプリID「app002」が含まれる。そして、フロー実行部131は、アプリ管理部120からアプリID「app002」に対応するアプリ情報10002に含まれる処理内容を取得する。すなわち、フロー実行部131は、図8(b)に示す処理内容を取得する。

0110

フロー実行部131は、取得した処理内容に従ってコンポーネントの取得を、コンポーネント管理部132に要求する(ステップS1603)。より具体的には、フロー実行部131は、図8(b)に示す処理内容の「From("file:input")」の次に指定されている「.to("storage:receive_file?type=service-a")」に基づき、取得コンポーネント1332の取得を、コンポーネント管理部132に要求する。なお、ここで、指定されている処理内容のうち「?type=service-a」の部分はオプションパラメータであり、取得コンポーネント1332の処理の電子ファイルの取得(ダウンロード)先ストレージサービスが「ストレージサービスA」であることを示している。また、ここで、上記の指定されている処理内容に、上記のステップS1601の実行要求に含まれる印刷対象のファイルである「FileA」のファイルIDをオプションパラメータとして付加して「.to("storage:receive_file?type=service-a&targetfile=file_id_a")」としてもよい。

0111

コンポーネント管理部132は、取得コンポーネント1332の取得要求を受け付けると、取得コンポーネント1332を生成する(ステップS1604)。取得コンポーネント1332の生成は、コンポーネント共通I/F1330に定義されたコンポーネントを生成するためのAPIを用いて行うことができる。そして、取得コンポーネント1332が生成されると、コンポーネント管理部132は、取得コンポーネント1332をフロー実行部131に返却する。これは、例えば、コンポーネント管理部132は、OCRコンポーネント1333が展開されたメモリ(例えばRAM14)上のアドレスを、フロー実行部131に返却する。

0112

フロー実行部131は、生成された取得コンポーネント1332に対して、データを指定して処理の実行を要求する(ステップS1605)。なお、ここで指定されるデータは、データ型が「InputStream」としてブラウザ210から渡された、印刷対象のファイルのファイルIDである。すなわち、フロー実行部131は、ブラウザ210からデータ型「InputStream」として渡されるファイルIDを、単に「データ」として(データ型を意識することなく)、取得コンポーネント1332に渡して処理の実行を要求する。図16では、このようにデータ型を意識することなく渡されるファイルIDや電子ファイル等を、単に「データ」と表す。

0113

取得コンポーネント1332は、型変換管理部134に対して、型変換を要求する(ステップS1606)。ここで、当該型変換要求には、データと、取得コンポーネント1332が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。

0114

型変換管理部134は、受け取った型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする(ステップS1607)。ここでは、受け取った型変換要求に含まれるデータのデータ型は「InputStream」である一方、指定されたデータ型は「LocalFilePath」であるから、一致しないものと判断される。

0115

すると、型変換管理部134は、型変換テーブル3000を参照して、「InputStream」を「LocalFilePath」に変換するための型変換を特定して(ここでは、第1の型変換1351が特定される)、当該特定された型変換を生成する(ステップS1608)。

0116

そして、型変換管理部134は、生成された第1の型変換1351に対して、データを指定して型変換処理の実行を要求する(ステップS1609)。そして、第1の型変換1351は、指定されたデータのデータ型を「InputStream」から「LocalFilePath」に変換して(ステップS1610)、当該変換後のデータを型変換管理部134に返信する。その後、型変換管理部134は、型変換後のデータを取得コンポーネント1332に送信する(ステップS1611)。

0117

取得コンポーネント1332は、型変換後のデータを受け取ると、処理を実行する(ステップS1612)。すなわち、本実施形態では、取得コンポーネント1332は、ストレージサービスA連携部1601のファイル処理部1701に対して、共通I/F1711として定義されているファイル取得のAPIを用いて、ファイル取得実行を要求する。より具体的には、取得コンポーネント1332は、ストレージサービスA連携部1601のファイル処理部1701に対して、図5(a)に示されるようにAPIとして「service-a/process/file」を用いてファイル取得の実行を要求する。これにより、ストレージサービスAからファイルID「file_id_a」の電子ファイルが取得(ダウンロード)される。取得コンポーネント1332により取得された電子ファイルは、データとしてフロー実行部131に送信される。

0118

次に、フロー実行部131は、取得した処理内容に従ってコンポーネントの取得を、コンポーネント管理部132に要求する(ステップS1613)。より具体的には、フロー実行部131は、図8(b)に示す処理内容の「.to("storage:receive_file? type=service-a")」の次に指定されている「.to("process:conv")」に基づき、印刷変換コンポーネント1334の取得を、コンポーネント管理部132に要求する。

0119

コンポーネント管理部132は、印刷変換コンポーネント1334の取得要求を受け付けると、印刷変換コンポーネント1334を生成する(ステップS1614)。印刷変換コンポーネント1334の生成は、コンポーネント共通I/F1330に定義されたコンポーネントを生成するためのAPIを用いて行うことができる。そして、印刷変換コンポーネント1334が生成されると、コンポーネント管理部132は、印刷変換コンポーネント1334をフロー実行部131に返却する。これは、例えば、コンポーネント管理部132は、印刷変換コンポーネント1334が展開されたメモリ(例えばRAM14)上のアドレスを、フロー実行部131に返却する。

0120

フロー実行部131は、生成された印刷変換コンポーネント1334に対して、データを指定して処理の実行を要求する(ステップS1615)。なお、ここで指定されたデータのデータ型は「LocalFilePath」である。

0121

印刷変換コンポーネント1334は、型変換管理部134に対して、型変換を要求する(ステップS1616)。ここで、当該型変換要求には、データと、印刷変換コンポーネント1334が扱うことができるデータ型を示す「File」の指定とが含まれる。

0122

型変換管理部134は、受け取った型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする(ステップS1617)。ここでは、受け取った型変換要求に含まれるデータのデータ型は「LocalFilePath」である一方、指定されたデータ型は「File」であるから、一致しないものと判断される。

0123

すると、型変換管理部134は、型変換テーブル3000を参照して、「LocalFilePath」を「File」に変換するための型変換を特定して(ここでは、第2の型変換1352が特定される)、当該特定された型変換を生成する(ステップS1618)。

0124

そして、型変換管理部134は、生成された第2の型変換1352に対して、データを指定して型変換処理の実行を要求する(ステップS1619)。そして、第2の型変換1352は、指定されたデータのデータ型を「LocalFilePath」から「File」に変換して(ステップS1620)、当該変換後のデータを型変換管理部134に返信する。その後、型変換管理部134は、型変換後のデータを印刷変換コンポーネント1334に送信する(ステップS1621)。

0125

印刷変換コンポーネント1334は、型変換後のデータを受け取ると、処理を実行する(ステップS1622)。すなわち、データ型「File」のデータ(すなわち、電子ファイル)を、画像形成装置20が印刷可能なデータ形式である印刷データに変換する処理を実行する。ここで、より具体的には、印刷変換コンポーネント1334は、ドキュメントサービス部150の印刷変換処理152に処理を要求し、印刷変換処理152がデータ(電子ファイル)に対して処理を実行する。そして、印刷変換コンポーネント1334は、フロー実行部131を介して、印刷データを画像形成装置20に返信する。

0126

[第2の実施形態]
次に、第2の実施形態に係る情報処理システム1について説明する。第2の実施形態に係る情報処理システム1に含まれるサービス提供システム10は、ブラウザ210が搭載されていない画像形成装置20からの要求も受け付ける点が第1の実施形態と異なる。なお、以降では、第1の実施形態と実質的に同一の機能を有する箇所及び同一の処理を行う箇所については、第1の実施形態と同一の符号を用いて、その説明を省略する。

0127

<ソフトウェア構成>
第2の実施形態に係る情報処理システム1は、例えば図17に示されるような処理ブロックにより実現することができる。図17は、第2の実施形態に係る情報処理システムの一例の処理ブロック図である。

0128

画像形成装置20は、例えばCPU211等により実現されるブラウザ210又はクライアントアプリケーション220を有する。ここで、ブラウザ210はHTMLを解釈できる一方で、クライアントアプリケーション220はHTMLを解釈することができないものとする。したがって、本実施形態に係るクライアントアプリケーション220は、サービス提供システム10から受け取ったデータ定義に基づきアプリ画面を生成して、表示させる。

0129

サービス提供システム10は、アプリ管理部120Aの機能が異なる点、及び、さらに要求判断部121を有する点が第1の実施形態と異なる。

0130

要求判断部121は、画像形成装置20から受け取った情報に基づき、送信元がブラウザ210か又はクライアントアプリケーション220かを判断する。

0131

アプリ管理部120Aは、要求判断部121の判断結果に応じて、画像形成装置20に対してアプリ画面又はデータ定義を返信する。すなわち、アプリ管理部120Aは、要求判断部121により送信元がクライアントアプリケーション220であると判断された場合は、当該画像形成装置20に対して、データ定義を返信する。

0132

<処理の詳細>
次に、第2の実施形態に係る情報処理システム1の処理の詳細について説明する。第2の実施形態では、図9を用いて説明したスキャン配信サービスの全体処理及び図14を用いて説明したクラウドプリントサービスの全体処理において、画像形成装置20にアプリ画面を表示させるまでの処理が異なる。したがって、第2の実施形態では、サービス一覧の取得からアプリ画面の表示までの処理について説明する。図18は、第2の実施形態に係るアプリ画面の表示処理の一例のシーケンス図である。

0133

まず、画像形成装置20のユーザは、ブラウザ210又はクライアントアプリケーション220を用いて、サービス提供システム10により提供されるサービスの一覧を取得するための操作を行う(ステップS1801)。すると、サービス処理部110の要求判断部121は、サービス提供システム10により提供されるサービスの一覧を、アプリ管理部120Aから取得して(ステップS1802)、画像形成装置20に送信する。これにより、画像形成装置20の操作パネル22には、サービス提供システム10により提供されるサービスの一覧が表示される。

0134

ユーザは、画像形成装置20の操作パネル22に表示されたサービスの一覧から自身が利用を所望するサービスを選択する。すると、ブラウザ210又はクライアントアプリケーション220は、選択されたサービスを実現するためのアプリ情報1000のアプリIDを要求判断部121に送信する(ステップS1803)。

0135

すると、要求判断部121は、送信元がブラウザ210か又はクライアントアプリケーション220かを判断する(ステップS1804)。これは、要求判断部121は、例えば、User Agentに基づき判断することができる。以降では、要求判断部121により送信元がブラウザ210であると判断された場合、ステップS1805の処理が実行される一方、送信元がクライアントアプリケーション220であると判断された場合、ステップS1806及びS1807の処理が実行される。

0136

要求判断部121により送信元がブラウザ210であると判断された場合、要求判断部121は、アプリ管理部120Aに対してHTMLのアプリ画面の取得を要求する(ステップS1805)。なお、当該要求には、上記のステップS1803で選択されたサービスを実現するためのアプリ情報1000のアプリIDが含まれる。すると、アプリ管理部121Aは、当該要求に含まれるアプリIDのアプリ情報1000に含まれる画面定義に基づきHTML形式のアプリ画面を生成し、要求判断部121を介して、ブラウザ210に送信する。

0137

一方、送信元がクライアントアプリケーション220であると判断された場合、要求判断部121は、アプリ管理部120Aに対してJSON(JavaScript Object Notation)形式等の汎用的なデータ形式でデータ定義の取得を要求する(ステップS1806)。なお、当該要求には、上記のステップS1803で選択されたサービスを実現するためのアプリ情報1000のアプリIDが含まれる。すると、アプリ管理部121Aは、当該要求に含まれるアプリIDのアプリ情報1000に含まれるデータ定義を、要求判断部121を介して、JSON形式でクライアントアプリケーション220に送信する。このように、画像形成装置20にHTMLを解釈することができないクライアントアプリケーション220が搭載されている場合、サービス提供システム10は、画面定義に含まれるデータ定義のみを返信する。そして、画像形成装置20のクライアントアプリケーション220は、受け取ったJSON形式のデータ定義に基づき、アプリ画面を生成する(ステップS1807)。

0138

そして、画像形成装置20は、操作パネル22にアプリ画面を表示させる(ステップS1808)。ここで、画像形成装置20にブラウザ210が搭載されている場合は、上記のステップS1805で受け取ったHTML形式のアプリ画面を表示させる。一方、画像形成装置20にクライアントアプリケーション220が搭載されている場合は、上記のステップS1807で生成したアプリ画面を表示させる。このようにすることで、画像形成装置20には必ずしもブラウザ210が搭載されている必要はなくなる。したがって、ユーザは、画像形成装置20に、サービス提供システム10により提供されるサービスを利用するための任意のクライアントアプリケーション220を搭載させることができる。

0139

[第3の実施形態]
次に、第3の実施形態に係る情報処理システム1について説明する。第3の実施形態に係る情報処理システム1は、サードベンダー等により開発されたコンポーネントを用いた処理内容により実現されるサービスを提供できる点が第1の実施形態と異なる。また、第3の実施形態に係る情報処理システム1は、画像形成装置20のブラウザ210を用いて、ユーザが処理内容を作成することができる点が第1の実施形態と異なる。

0140

なお、以降では、サードベンダー等により開発されたコンポーネントを「外部コンポーネント」、サービス提供システム10に予め組み込まれているコンポーネント(すなわち、第1の実施形態及び第2の実施形態で説明したコンポーネント)を「内部コンポーネント」と表して区別する。さらに、内部コンポーネントと外部コンポーネントとを区別しないときは、単に、「コンポーネント」と表す。

0141

また、以降では、第1の実施形態と実質的に同一の機能を有する箇所及び同一の処理を行う箇所については、第1の実施形態と同一の符号を用いて、その説明を省略する。

0142

<システム構成>
図19は、第3の実施形態に係る情報処理システムの一例の構成図である。図19に示される情報処理システム1のサービス提供環境E1は、外部コンポーネント管理装置40を含む。

0143

外部コンポーネント管理装置40は、一台以上の情報処理装置で実現され、外部コンポーネントを管理する。このように、本実施形態に係る情報処理システム1では、サービス提供システム10とは異なる装置である外部コンポーネント管理装置40において外部コンポーネントを管理する。このため、例えば、外部コンポーネントが重大なバグを有していた場合等における影響を外部コンポーネント管理装置40に局所化させることができる。

0144

なお、図19では、サービス提供環境E1に一の外部コンポーネント管理装置40が含まれる例を示したが、これに限られない。サービス提供環境E1には、複数の外部コンポーネント管理装置40が含まれていてもよい。例えば、サービス提供環境E1には、A社が開発した外部コンポーネントを管理する外部コンポーネント管理装置401、B社が開発した外部コンポーネントを管理する外部コンポーネント管理装置402等が含まれていてもよい。

0145

<ソフトウェア構成>
第1の実施形態に係る情報処理システム1は、例えば図20に示されるような処理ブロックにより実現することができる。図20は、第3の実施形態に係る情報処理システムの一例の処理ブロック図である。

0146

サービス提供システム10のサービス処理部110は、アプリ管理部120Aと、ロジック処理部130Aと、処理内容作成部122とを有する。

0147

処理内容作成部122は、ブラウザ210からの要求に応じて、処理内容を作成するための画面(処理内容の作成画面)を作成する。

0148

アプリ管理部120Aは、処理内容作成部122からの要求に応じて、処理内容の作成画面において作成された処理内容をアプリ情報記憶部190に記憶させる。これにより、ユーザが作成した処理内容により示される一連の処理で実現されるサービスが追加される。

0149

ロジック処理部130Aは、アプリ管理部120Aから取得した処理内容により示される一連の処理において、外部コンポーネントにより実行される処理がある場合、当該処理の実行を外部コンポーネント処理部410に要求する。なお、ロジック処理部130Aの詳細な処理ブロックについては後述する。

0150

外部コンポーネント管理装置40は、外部コンポーネント処理部410を有する。外部コンポーネント処理部41は、例えば、外部コンポーネント管理装置40が備えるCPUにより実現される。

0151

外部コンポーネント処理部410は、ロジック処理部130Aからの要求に応じて、外部コンポーネントを実行する。なお、外部コンポーネント処理部410の詳細な処理ブロックについては後述する。

0152

次に、本実施形態に係るロジック処理部130Aの詳細な処理ブロックについて説明する。図21は、第3の実施形態に係るロジック処理部の一例の処理ブロック図である。

0153

本実施形態に係るロジック処理部130Aは、フロー実行部131Aと、コンポーネント管理部132Aとを有する。また、本実施形態に係るロジック処理部130Aのコンポーネント群133には、外部コンポ連携コンポーネント1335が含まれる。さらに、本実施形態に係るロジック処理部130Aは、コンポーネント管理テーブル5000を利用する。

0154

フロー実行部131Aは、アプリ管理部120Aから取得した処理内容に従ってコンポーネントの取得をコンポーネント管理部132Aに要求する。このとき、フロー実行部131Aは、処理内容に基づいて、後述するコンポーネント名を指定して、コンポーネントの取得を要求する。

0155

コンポーネント管理部132Aは、フロー実行部131Aからの要求に応じて、コンポーネント管理テーブル5000を参照し、当該要求に係るコンポーネントが内部コンポーネント又は外部コンポーネントのいずれであるかを判定する。そして、コンポーネント管理部132Aは、当該要求に係るコンポーネントが外部コンポーネントである場合、外部コンポ連携コンポーネント1335を生成する。

0156

コンポーネント群133に含まれる外部コンポ連携コンポーネント1335は、外部コンポーネント管理装置40の外部コンポーネント処理部410と処理の連携を行うためのコンポーネントである。外部コンポ連携コンポーネント1335は、外部コンポーネント処理部410に対して、外部コンポーネントの処理の実行を要求する。なお、外部コンポ連携コンポーネント1335は、コンポーネント共通I/F1330を有する。

0157

ここで、コンポーネント管理テーブル5000は、図22に示すようなデータ項目を有している。図22は、コンポーネント管理テーブルの一例を説明するための図である。

0158

図22に示すコンポーネント管理テーブル5000は、データ項目として、コンポーネントIDと、コンポーネント名と、ホスト名とを有する。コンポーネントIDは、コンポーネントを一意に識別する識別情報である。コンポーネント名は、コンポーネントの名称である。なお、本実施形態では、コンポーネント名は、コンポーネントに対して一意に付与されているものとする。

0159

ホスト名は、コンポーネントを管理している装置を識別する情報である。すなわち、例えば、内部コンポーネントには、ホスト名「localhost」が関連付けられており、サービス提供システム10で管理されていることが示されている。一方、例えば、外部コンポーネントには、ホスト名「server2.com」が関連付けられており、当該ホスト名の外部コンポーネント管理装置40で管理されていることが示されている。

0160

このように、コンポーネント管理テーブル5000では、コンポーネント毎に、当該コンポーネントが管理されている装置のホスト名が関連付けられている。なお、処理内容作成部122は、コンポーネント管理テーブル5000からコンポーネントの一覧を取得することで、処理内容の作成画面を作成する。

0161

次に、外部コンポーネント処理部410の詳細な処理ブロックについて説明する。図23は、第3の実施形態に係る外部コンポーネント処理部の一例の処理ブロック図である。

0162

外部コンポーネント処理部410は、要求受付部411と、コンポーネント管理部412と、外部コンポーネント群413と、型変換管理部414と、型変換群415とを有する。また、外部コンポーネント処理部410は、型変換テーブル6000を利用する。

0163

要求受付部411は、ロジック処理部130Aからの要求を受け付けると、コンポーネント管理部412に対して、外部コンポーネントの生成を要求する。そして、要求受付部411は、外部コンポーネントが生成されると、当該外部コンポーネントに対して処理の実行を要求する。

0164

コンポーネント管理部412は、要求受付部411からの要求に応じて、外部コンポーネントの生成を行う。

0165

外部コンポーネント群413は、外部コンポーネントの集合である。外部コンポーネント群413には、サードベンダー等により開発された各種の外部コンポーネントが含まれる。例えば、外部コンポーネント群413には、外部ストレージシステム30に電子ファイルを配信するための配信αコンポーネント4131、電子ファイルを印刷データに変換するための印刷変換βコンポーネント4132が含まれる。

0166

また、これらの各外部コンポーネントは、コンポーネント共通I/F4130を有する。コンポーネント共通I/F4130は、各外部コンポーネントに対して共通に定義されたAPIであり、外部コンポーネントを生成するためのAPIと、外部コンポーネントに対して処理の実行を要求するためのAPIとが含まれる。

0167

型変換管理部414は、データ型の型変換を管理する。ここで、外部コンポーネントは、自身が扱えるデータ型が予め定まっている。したがって、型変換管理部414は、外部コンポーネントからの要求に応じて、図24に示すような型変換テーブル6000を参照して、型変換群415に定義されている型変換を生成する。そして、型変換管理部414は、生成された型変換に対して型変換処理の実行を要求する。

0168

型変換群415は、型変換の集合である。型変換群415には、データ型「InputStream」を「LocalFilePath」に変換する第1の型変換4151、「LocalFilePath」を「File」に変換する第2の型変換4142等が含まれる。

0169

また、これらの各型変換は、型変換共通I/F4150を有する。型変換共通I/F4150は、各型変換に対して共通に定義されたAPIであり、型変換を生成するためのAPIと、型変換に対して処理の実行を要求するためのAPIとが含まれる。

0170

<処理の詳細>
次に、本実施形態に係る情報処理システム1の処理の詳細について説明する。本実施形態では、スキャン配信サービスを実現する一連の処理に、外部コンポーネントにより実行される処理が含まれる場合について説明する。すなわち、本実施形態に係るスキャン配信サービスは、内部コンポーネントにより実行される処理と、外部コンポーネントにより実行される処理とで構成される一連の処理により実現されるものとする。

0171

≪OCRから配信実行までの処理≫
図25は、第3の実施形態に係るOCRから配信実行までの処理の一例のシーケンス図である。まず、ステップS2501の処理は、図13を用いて説明したステップS1301の処理と同様であるため、その説明を省略する。

0172

フロー実行部131Aは、ブラウザ210からスキャン配信サービスの実行要求を受け付けると、アプリ管理部120Aに処理内容の取得を要求する(ステップS2502)。ここで、本実施形態では、フロー実行部131Aにより、図26に示す処理内容が取得されたものとする。

0173

フロー実行部131Aは、取得した処理内容に従ってコンポーネントの取得を、コンポーネント管理部132Aに要求する(ステップS2503)。より具体的には、フロー実行部131は、図26に示す処理内容の「From("file:input")」の次に指定されている「.to("process:ocr")」に基づき、コンポーネント名が「ocr」であるコンポーネントの取得を、コンポーネント管理部132Aに要求する。

0174

コンポーネント管理部132Aは、コンポーネントの取得要求を受け付けると、コンポーネント管理テーブル5000を参照して、当該取得要求に係るコンポーネントが内部コンポーネント又は外部コンポーネントのいずれであるかを判定する(ステップS2504)。

0175

すなわち、コンポーネント管理部132Aは、コンポーネント管理テーブル5000において、当該取得要求に含まれるコンポーネント名に関連付けられているホスト名が「localhost」であるか否かを判定する。そして、コンポーネント管理部132Aは、当該ホスト名が「localhost」である場合、当該取得要求に係るコンポーネントは内部コンポーネントであると判定する。一方、コンポーネント管理部132Aは、当該ホスト名が「localhost」でない場合、当該取得要求に係るコンポーネントは外部コンポーネントであると判定する。

0176

ここで、コンポーネント管理テーブル5000において、コンポーネント名「ocr」に関連付けられているホスト名は「localhost」である。したがって、コンポーネント管理部132Aは、当該取得要求に係るコンポーネントは内部コンポーネントであると判定する。

0177

コンポーネント管理部132Aは、コンポーネントの取得要求に係るコンポーネントが内部コンポーネントであると判定された場合、当該取得要求に含まれるコンポーネント名に対応する内部コンポーネントを生成する(ステップS2505)。すなわち、コンポーネント管理部132Aは、当該取得要求に含まれるコンポーネント名「ocr」に対応するOCRコンポーネント1333を生成する。

0178

そして、コンポーネント管理部132Aは、生成されたOCRコンポーネント1333をフロー実行部131Aに返却する。

0179

続くステップS2506〜ステップS2513の処理は、図13を用いて説明したステップS1305〜ステップS1312の処理と同様であるため、その説明を省略する。

0180

次に、フロー実行部131Aは、取得した処理内容に従ってコンポーネントの取得を、コンポーネント管理部132Aに要求する(ステップS2514)。より具体的には、フロー実行部131Aは、図26に示す処理内容の「.to("process:ocr")」の次に指定されている「.to("storage:send_to_folderα?type=service-b")」に基づき、コンポーネント名が「send_to_folderα」であるコンポーネントの取得を、コンポーネント管理部132Aに要求する。なお、ここで指定されている処理内容のうち「?type=service-b」の部分は、オプションパラメータであり、コンポーネント名「send_to_folderα」のコンポーネントの処理によるデータのアップロード先が「ストレージサービスB」であることを示している。

0181

コンポーネント管理部132Aは、コンポーネントの取得要求を受け付けると、コンポーネント管理テーブル5000を参照して、当該取得要求に係るコンポーネントが内部コンポーネント又は外部コンポーネントのいずれであるかを判定する(ステップS2515)。

0182

すなわち、コンポーネント管理部132Aは、コンポーネント管理テーブル5000において、当該取得要求に含まれるコンポーネント名に関連付けられているホスト名が「localhost」であるか否かを判定する。そして、コンポーネント管理部132Aは、当該ホスト名が「localhost」である場合、当該取得要求に係るコンポーネントは内部コンポーネントであると判定する。一方、コンポーネント管理部132Aは、当該ホスト名が「localhost」でない場合、当該取得要求に係るコンポーネントは外部コンポーネントであると判定する。

0183

ここで、コンポーネント管理テーブル5000において、コンポーネント名「send_to_folderα」に関連付けられているホスト名は「server2.com」である。したがって、コンポーネント管理部132Aは、当該取得要求に係るコンポーネントは外部コンポーネントであると判定する。

0184

コンポーネント管理部132Aは、コンポーネントの取得要求に係るコンポーネントが外部コンポーネントであると判定された場合、外部コンポ連携コンポーネント1335を生成する(ステップS2516)。

0185

このように、本実施形態に係るサービス提供システム10は、コンポーネントの取得要求に係るコンポーネントが外部コンポーネントである場合、外部コンポ連携コンポーネント1335を生成する。

0186

そして、コンポーネント管理部132Aは、生成された外部コンポ連携コンポーネント1335をフロー実行部131Aに返却する。

0187

フロー実行部131Aは、生成された外部コンポ連携コンポーネント1335に対して、データを指定して処理の実行を要求する(ステップS2517)。なお、ここで指定されたデータのデータ型は「LocalFilePath」である。

0188

外部コンポ連携コンポーネント1335は、型変換管理部134に対して、型変換を要求する(ステップS2518)。ここで、当該型変換要求には、データと、外部コンポ連携コンポーネント1335が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。

0189

型変換管理部134は、受け取った型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする(ステップS2519)。ここでは、受け取った型変換要求に含まれるデータのデータ型は「LocalFilePath」であり、指定されたデータ型も「LocalFilePath」であるから、一致するものと判断される。そして、型変換管理部134は、型変換要求に含まれていたデータを、そのまま外部コンポ連携コンポーネント1335に送信する(ステップS2520)。

0190

外部コンポ連携コンポーネント1335は、型変換管理部134からデータを受け取ると、処理を実行する(ステップS2521)。すなわち、外部コンポ連携コンポーネント1335は、コンポーネント名「send_to_folderα」と、データとを含む処理の実行を、ホスト名「server2.com」で示される外部コンポーネント管理装置40の外部コンポーネント処理部410に要求する。なお、当該実行要求には、上記で説明したアップロード先のストレージサービスを示すオプションパラメータ「?type=service-b」も含まれる。

0191

次に、外部コンポーネント処理部410は、外部コンポ連携コンポーネント1335から処理の実行要求を受け取ると、当該実行要求に応じて、外部コンポーネント処理を実行する(ステップS2522)。そして、外部コンポーネント処理部410は、処理結果を示すデータを返信する。

0192

ここで、上記のステップS2522の処理の詳細について説明する。図27は、第3の実施形態に係る外部コンポーネント処理の一例のシーケンス図である。

0193

まず、要求受付部411は、ロジック処理部130A(より詳細には、外部コンポ連携コンポーネント1335)から処理の実行要求を受け付ける(ステップS2701)。なお、当該実行要求には、外部コンポーネントのコンポーネント名「send_to_folderα」と、データと、オプションパラメータ「?type=service-b」とが含まれる。

0194

なお、処理内容にオプションパラメータが指定されていない場合は、処理の実行要求にオプションパラメータは含まれない。また、当該実行要求に含まれるデータは、データ型が「InputStream」として渡されるものとする。

0195

要求受付部411は、処理の実行要求を受け付けると、当該実行要求に含まれるコンポーネント名「send_to_folderα」の外部コンポーネントの取得を、コンポーネント管理部412に要求する(ステップS2702)。

0196

コンポーネント管理部412は、外部コンポーネントの取得要求を受け付けると、当該取得要求に含まれるコンポーネント名「send_to_folderα」に対応する配信αコンポーネント4131を生成する(ステップS2703)。配信αコンポーネント4131の生成は、コンポーネント共通I/F4130に定義されたコンポーネントを生成するためのAPIを用いて行うことができる。

0197

そして、コンポーネント管理部412は、生成された配信αコンポーネント4131を要求受付部411に返却する。これは、例えば、コンポーネント管理部412は、配信αコンポーネント4131が展開されたメモリ上(例えばRAM)上のアドレスを、要求受付部411に返却する。

0198

要求受付部411は、生成された配信αコンポーネント4131に対して、データを指定して処理の実行を要求する(ステップS2704)。

0199

配信αコンポーネント4131は、処理の実行要求を受け取ると、型変換管理部414に対して、型変換を要求する(ステップS2705)。ここで、当該型変換要求には、データと、配信αコンポーネント4131が扱うことができるデータ型を示す「LocalFilePath」の指定とが含まれる。

0200

型変換管理部414は、受け取った型変換要求に含まれるデータのデータ型と、指定されたデータ型とが一致するか否かをチェックする(ステップS2706)。受け取った型変換要求に含まれるデータのデータ型は「InputStream」である一方、指定されたデータ型は「LocalFilePath」であるから、一致しないものと判断される。

0201

すると、型変換管理部414は、型変換テーブル6000を参照して、「InputStream」を「LocalFilePath」に変換するための型変換を特定して(ここでは、第1の型変換4151が特定される)、当該特定された型変換を生成する(ステップS2707)。

0202

そして、型変換管理部414は、生成された第1の型変換4151に対して、データを指定して型変換処理の実行を要求する(ステップS2708)。すると、第1の型変換4151は、指定されたデータのデータ型を「InputStream」から「LocalFilePath」に変換して(ステップS2709)、当該変換後のデータを型変換管理部414に返信する。

0203

その後、型変換管理部414は、型変換後のデータを配信αコンポーネント4131に送信する(ステップS2710)。

0204

配信αコンポーネント4131は、型変換管理部414からデータを受け取ると、処理を実行する(ステップS2711)。すなわち、本実施形態では、配信αコンポーネント4131は、ストレージサービスBに対して、データの配信を実行する。

0205

なお、配信αコンポーネント4131は、ストレージサービスB連携部1602を介さずに、ストレージサービスBに対してデータを配信する。このように、外部コンポーネントは、内部コンポーネントと異なり、ストレージサービス連携部160やドキュメントサービス部150を用いずに、例えば配信処理やOCR処理等の各種の処理を実行する。ただし、これに限られず、外部コンポーネントは、内部コンポーネントと同様に、ストレージサービス連携部160やドキュメントサービス部150に処理要求を行うことで、各種の処理を実行しても良い。

0206

そして、配信αコンポーネント4131は、処理結果を示すデータ返信する。これにより、本実施形態に係るスキャン配信サービスが提供される。

0207

このように、本実施形態に係るサービス提供システム10は、処理内容に外部コンポーネントにより実行される処理が含まれる場合、当該外部コンポーネントを管理する外部コンポーネント管理装置40に処理の実行を要求する。そして、サービス提供システム10とは異なる装置である外部コンポーネント管理装置40において外部コンポーネントが実行される。

0208

したがって、例えば、サードベンダー等により開発された外部コンポーネントに重大なバグや不具合等が存在していた場合でも、当該バグや不具合等による影響を外部コンポーネント管理装置40内に局所化させることができる。換言すれば、サービス提供システム10は、外部コンポーネントのバグや不具合等に伴う影響を受けることなく、サービスの提供を継続することができるようになる。

0209

なお、本実施形態では、外部コンポーネント管理装置40において外部コンポーネントが管理されるものとしたが、例えば、外部コンポーネントの品質が確保された後は、当該外部コンポーネントをサービス提供システム10で管理するようにしてもよい。

0210

≪処理内容の作成処理≫
次に、例えば、アプリ情報1000の開発者等のユーザが、当該アプリ情報1000に含まれる処理内容を作成する処理について説明する。図28は、第3の実施形態に係る処理内容の作成処理の一例のシーケンス図である。

0211

まず、画像形成装置20のユーザは、ブラウザ210を用いて、処理内容の作成画面を表示するための操作を行う。すると、画像形成装置20のブラウザ210は、処理内容の作成画面の取得を、処理内容作成部122に要求する(ステップS2801)。

0212

処理内容作成部122は、コンポーネント管理テーブル5000からコンポーネントの一覧(例えば、コンポーネント名の一覧)を取得して、図29(a)に示すような処理内容の作成画面7000を作成する(ステップS2802)。そして、処理内容作成部122は、作成した処理内容の作成画面7000をブラウザ210に返信する。

0213

ここで、図29(a)に示す処理内容の作成画面7000は、アプリID表示欄7010と、コンポーネント表示欄7020と、処理内容作成欄7030とが含まれる。

0214

アプリID表示欄7010は、作成する処理内容が含まれるアプリ情報1000のアプリIDが表示される。このアプリIDは、例えば、上記のステップS2801でユーザにより指定されてもよい。

0215

コンポーネント表示欄7020は、それぞれのコンポーネントを示すアイコン表示部品)が一覧で表示されている。このようなコンポーネントを示すアイコンの一覧は、コンポーネント管理テーブル5000から取得されたコンポーネント名に基づいて作成される。処理内容作成欄7030は、ユーザが処理内容を作成するための領域であり、例えば、コンポーネント表示欄7020に含まれるコンポーネントを示すアイコンをドラッグアンドドロップすることで、処理内容を作成することができる。

0216

ここで、ユーザは、ブラウザ210を用いて、コンポーネント表示欄7020に含まれる取得コンポーネントと、印刷変換βコンポーネントとを、この順で、処理内容作成欄7030にドラッグアンドドロップしたものとする。すると、図29(b)に示すように処理内容の作成画面7100の処理内容作成欄7110には、処理内容を模式的に示すフロー図7120が作成される。フロー図7120は、内部コンポーネントである取得コンポーネントを実行した後、外部コンポーネントである印刷変換βコンポーネントを実行する処理内容を示している。

0217

これにより、ユーザにより処理内容が作成される。しかも、このとき、ユーザは、処理内容に含まれる一連の処理を実行するコンポーネントが、内部コンポーネントであるか外部コンポーネントであるかを意識することなく、処理内容を作成することができる。したがって、ユーザは、容易に処理内容を作成することができる。

0218

画像形成装置20のブラウザ210は、ユーザにより処理内容が作成されると、作成された処理内容を受け付ける(ステップS2803)。そして、画像形成装置20のブラウザ210は、作成された処理内容の保存を処理内容作成部122に要求する(ステップS2804)。なお、当該保存要求には、アプリIDと、ユーザにより作成された処理内容とが含まれる。

0219

サービス処理部110の処理内容作成部122は、処理内容の保存要求を受け取ると、当該保存要求をアプリ管理部120Aに転送する(ステップS2805)。次に、アプリ管理部120Aは、処理内容の保存要求を受け取ると、当該保存要求に含まれる処理内容をアプリIDと関連付けてアプリ情報記憶部190に保存する(ステップS2806)。そして、アプリ管理部120Aは、保存結果を返信する。これにより、ユーザにより作成された処理内容がアプリ情報記憶部190に記憶される。

0220

<まとめ>
以上のように、第1の実施形態に係る情報処理システム1によれば、サービス提供システム10は外部サービスと連携したサービスを画像形成装置20に提供することができる。また、サービス提供システム10は、連携先の外部サービスの追加・変更等を容易に行うことができる。さらに、サービス提供システム10は、画像形成装置20に提供するサービスの追加・変更等(すなわち、アプリ情報1000の追加・変更等)を容易に行うことができる。これらにより、第1の実施形態に係るサービス提供システム10は、サービスの追加・変更等に伴う開発・維持に要する工数を削減することができる。

0221

さらに、第2の実施形態に係る情報処理システム1によれば、サービス提供システム10は、ブラウザ210が搭載されていない画像形成装置20に対してもサービスを提供することができる。したがって、第2の実施形態に係るサービス提供システム10によれば、一般にブラウザが搭載されていない多様な電子機器に対してサービスを提供することができる。

0222

また、第3の実施形態に係る情報処理システム1によれば、サードベンダー等により開発された外部コンポーネントを、サービス提供システム10とは異なる装置である外部コンポーネント管理装置40で管理及び実行させることができる。これにより、例えば、外部コンポーネントにバグや不具合が存在する等、外部コンポーネントの品質が十分でない場合においても、バグや不具合等に伴う影響を外部コンポーネント管理装置40に局所化させることができる。

0223

したがって、第3の実施形態に係る情報処理システム1によれば、例えば、外部コンポーネントのバグや不具合等に伴いサービス提供システム10の処理能力が低下、又はサービス提供システム10が停止するような事態等を防止することができる。

0224

なお、アプリ情報記憶部190は、記憶手段の一例である。アプリ管理部120は、第1の送信手段の一例である。ロジック処理部130は、処理実行手段の一例である。

0225

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

0226

1情報処理システム
10サービス提供システム
20画像形成装置
30外部ストレージシステム
110サービス処理部
120アプリ管理部
130ロジック処理部
131フロー実行部
132コンポーネント管理部
133コンポーネント群
134型変換管理部
135 型変換群
140 データI/F部
150ドキュメントサービス部
151OCR処理
152印刷変換処理
160ストレージサービス連携部
170ファイル処理部
180データ処理部
190アプリ情報記憶部
1000 アプリ情報
3000 型変換テーブル

先行技術

0227

特開2014−032659号公報

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ