JP2015114892A - サービス提供システム及びサービス提供方法 - Google Patents

Abstract

【課題】連携する電子機器のアプリケーション及びサービス提供システムのアプリケーションの開発を容易化できるサービス提供システム及びサービス提供方法を提供することを課題とする。【解決手段】電子機器に搭載されているアプリケーションと連携してサービスを提供するサービス提供システムであって、アプリケーションと連携して処理を行うアプリサービス提供手段と、アプリケーション及びアプリサービス提供手段からの要求を受け付ける要求受付手段と、アプリケーション及びアプリサービス提供手段が要求受付手段を介して共通に利用する記憶手段と、アプリサービス提供手段への通知対象として登録されている事象が記憶手段において発生したときに、要求受付手段を介してアプリサービス提供手段に通知を行う通知手段とを有することにより、上記課題を解決する。【選択図】 図１

Description

本発明はサービス提供システム及びサービス提供方法に関する。

従来、画像形成装置に関するアプリケーションプログラムの機能をクラウドサービスに代表されるようなＷｅｂアプリケーションやサーバ側のアプリケーションによって提供する情報処理システムが知られている（例えば特許文献１参照）。

画像形成装置等のデバイス装置のアプリケーションの機能をＷｅｂアプリケーションやサーバ装置側のアプリケーションによって提供するサービス提供システムはデバイス装置のアプリケーションとサービス提供システムのアプリケーションとが直接通信する。しかしながら、デバイス装置のアプリケーションとサービス提供システムのアプリケーションとが直接通信する情報処理システムでは、デバイス装置のアプリケーションとサービス提供システムのアプリケーションとが密に依存する構成となる場合が多い。

したがって、従来の情報処理システムはデバイス装置のアプリケーションとサービス提供システムのアプリケーションとを開発する場合、独自でプロトコルを策定するなどの知識が必要となり、アプリケーション開発を困難にしていた。

本発明の実施の形態は、上記の点に鑑みなされたものであり、連携する電子機器のアプリケーション及びサービス提供システムのアプリケーションの開発を容易化できるサービス提供システム及びサービス提供方法を提供することを目的とする。

上記目的を達成するために本願請求項１の情報処理装置は、電子機器に搭載されているアプリケーションと連携してサービスを提供するサービス提供システムであって、前記アプリケーションと連携して処理を行うアプリサービス提供手段と、前記アプリケーション及び前記アプリサービス提供手段からの要求を受け付ける要求受付手段と、前記アプリケーション及び前記アプリサービス提供手段が前記要求受付手段を介して共通に利用する記憶手段と、前記アプリサービス提供手段への通知対象として登録されている事象が前記記憶手段において発生したときに、前記要求受付手段を介して前記アプリサービス提供手段に通知を行う通知手段とを有することを特徴とする。

本発明の実施の形態によれば、連携する電子機器のアプリケーション及びサービス提供システムのアプリケーションの開発を容易化できる。

第１の実施形態に係る情報処理システムの一例の構成図である。 本実施形態に係るコンピュータの一例のハードウェア構成図である。 第１の実施形態に係るサービス提供システムの一例の処理ブロック図である。 デバイス装置のデバイスアプリ部とアプリサービス部とが直接通信する仕組みの一例について説明する図である。 デバイス装置のデバイスアプリ部とアプリサービス部とが直接通信する仕組みの他の例について説明する図である。 デバイス装置のデバイスアプリ部とアプリサービス部とが直接通信しない仕組みの一例について説明する図である。 本実施形態に係るサービス提供システムの処理手順を表した一例のシーケンス図である。 通知サービス部に通知登録される内容の一例について説明する図である。 通知サービス部の処理の一例について説明する図である。 通知サービス部の処理の他の例について説明する図である。

以下、本発明の実施形態について図面を参照しながら説明する。
［第１の実施形態］
＜システム構成＞
図１は第１の実施形態に係る情報処理システムの一例の構成図である。図１の情報処理システム１は、デバイス装置１１、端末装置１２、オンラインストレージ１３、サービス提供システム２０が、インターネット等のネットワークＮ１を介して接続されている構成である。

また、サービス提供システム２０はアクセス制御装置２１、ポータルサービス提供装置２２、アプリサービス提供装置２３、共通サービス提供装置２４、ストレージサービス提供装置２５が、ネットワークＮ２を介して接続されている構成である。ネットワークＮ２はＬＡＮ等のネットワークである。サービス提供システム２０は例えばクラウドサービスの形態であってもよい。

デバイス装置１１はサービス提供システム２０と連携して処理を行う複合機などの電子機器である。例えばデバイス装置１１は複合機、コピー機、スキャナ、プリンタ、レーザプリンタ、プロジェクタ、電子黒板などの画像形成に係る処理を行う電子機器である。

端末装置１２はユーザにより操作され、サービス提供システム２０のポータルサービス提供装置２２にアクセス（接続）してユーザから受け付けた後述の連携設定やプロファイル設定などの設定を要求する。なお、端末装置１２は、スマートフォンや携帯電話、タブレット端末、ＰＣなど、ユーザの操作によりサービス提供システム２０のポータルサービス提供装置２２にアクセスして要求を行うことができる装置であればよい。

オンラインストレージ１３はファイルを保存する装置である。オンラインストレージ１３は、ベンダーにより提供されるファイル保存用の装置であってもよい。なお、図１ではデバイス装置１１、端末装置１２及びオンラインストレージ１３がそれぞれ一つである例を示しているが複数であってもよい。

また、ネットワークＮ２はアクセス制御装置２１を介してネットワークＮ１に接続されている。ネットワークＮ２は、アクセス制御装置２１によってセキュリティが保護されている。

アクセス制御装置２１はデバイス装置１１や端末装置１２からのポータルサービス提供装置２２、共通サービス提供装置２４、ストレージサービス提供装置２５などへのアクセスを制御する。ネットワークＮ２にはアクセス制御装置２１の他、ポータルサービス提供装置２２、アプリサービス提供装置２３、共通サービス提供装置２４、ストレージサービス提供装置２５が接続されている。

ポータルサービス提供装置２２はアプリサービス提供装置２３を利用して端末装置１２にポータルサービスを提供する。アプリサービス提供装置２３は共通サービス提供装置２４及びストレージサービス提供装置２５を利用してアプリサービスを提供する。

共通サービス提供装置２４はアプリサービス提供装置２３、デバイス装置１１に搭載されたアプリケーションに共通サービスを提供する。また、ストレージサービス提供装置２５はアプリサービス提供装置２３、デバイス装置１１に搭載されたアプリケーションにストレージサービスを提供する。

なお、アクセス制御装置２１、ポータルサービス提供装置２２、アプリサービス提供装置２３、共通サービス提供装置２４、ストレージサービス提供装置２５は、一台以上の情報処理装置によって実現される。また、アクセス制御装置２１、ポータルサービス提供装置２２、アプリサービス提供装置２３、共通サービス提供装置２４、ストレージサービス提供装置２５は一台の情報処理装置に統合して実現してもよいし、複数の情報処理装置に分散して実現してもよい。ネットワークＮ２側のサービスの一部はネットワークＮ２以外にあってもよい。図１のサービス提供システム２０の構成は一例であって、他の構成で実現してもよい。

＜ハードウェア構成＞
図１の端末装置１２、オンラインストレージ１３、サービス提供システム２０は例えば図２に示すようなハードウェア構成のコンピュータ等により実現される。図２は、本実施形態に係るコンピュータの一例のハードウェア構成図である。

図２に示したコンピュータ５００は、入力装置５０１、表示装置５０２、外部Ｉ／Ｆ５０３、ＲＡＭ５０４、ＲＯＭ５０５、ＣＰＵ５０６、通信Ｉ／Ｆ５０７、及びＨＤＤ５０８などを備え、それぞれがバスＢで相互に接続されている。なお、入力装置５０１及び表示装置５０２は必要なときに接続して利用する形態であってもよい。

入力装置５０１はキーボードやマウスなどを含み、ユーザが各操作信号を入力するのに用いられる。表示装置５０２はディスプレイなどを含み、コンピュータ５００による処理結果を表示する。

通信Ｉ／Ｆ５０７は、コンピュータ５００をネットワークＮ１やＮ２に接続するインタフェースである。これにより、コンピュータ５００は通信Ｉ／Ｆ５０７を介してデータ通信を行うことができる。

ＨＤＤ５０８はプログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータは、例えばコンピュータ５００全体を制御する基本ソフトウェアであるＯＳや、ＯＳ上において各種機能を提供するアプリケーションなどである。

外部Ｉ／Ｆ５０３は、外部装置とのインタフェースである。外部装置には、記録媒体５０３ａなどがある。これにより、コンピュータ５００は外部Ｉ／Ｆ５０３を介して記録媒体５０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体５０３ａにはフレキシブルディスク、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリなどがある。

ＲＯＭ５０５は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ５０５には、コンピュータ５００の起動時に実行されるＢＩＯＳ、ＯＳ設定、及びネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ５０４は、プログラムやデータを一時保持する揮発性の半導体メモリである。

ＣＰＵ５０６は、ＲＯＭ５０５やＨＤＤ５０８などの記憶装置からプログラムやデータをＲＡＭ５０４上に読み出し、処理を実行することで、コンピュータ５００全体の制御や機能を実現する演算装置である。

本実施形態に係る端末装置１２、オンラインストレージ１３、サービス提供システム２０は、上記したコンピュータ５００のハードウェア構成により後述するような各種処理を実現できる。なお、図１に示したデバイス装置１１は例えば図２のハードウェア構成にデバイス特有の処理部を有する構成であればよいため、ハードウェア構成についての説明を省略する。

＜ソフトウェア構成＞
《サービス提供システム》
第１の実施形態に係るサービス提供システム２０は例えば図３に示す処理ブロックにより実現される。図３は第１の実施形態に係るサービス提供システムの一例の処理ブロック図である。

サービス提供システム２０はプログラムを実行することにより、ポータルサービス部５１、アプリサービス部５２、共通サービス部５３、ストレージサービス部５４、プラットフォームＡＰＩ（Application Programming Interface）５５を実現している。また、共通サービス部５３は通知サービス部６１、ジョブ実行部６２を有する。ストレージサービス部５４は、データストレージ部７１、ファイルストレージ部７２を有する。

ポータルサービス部５１は例えばポータルサービスを提供するアプリケーションにより実現される。ポータルサービス部５１は端末装置１２から後述の連携設定やプロファイル設定などのポータルサービスの要求を受け付ける。ポータルサービスの要求を受け付けたポータルサービス部５１はアプリサービス提供装置２３を利用して端末装置１２にポータルサービスを提供する。

アプリサービス部５２は例えばアプリサービスを提供するアプリケーションにより実現される。アプリサービス部５２はポータルサービス部５１から連携設定やプロファイル設定などの要求を受け付ける。また、アプリサービス部５２はプラットフォームＡＰＩ５５を介して共通サービス部５３又はストレージサービス部５４に後述の通知（ｃａｌｌｂａｃｋ）登録やジョブ実行、プロファイル情報保存、データ取得などの要求を行う。

また、アプリサービス部５２はプラットフォームＡＰＩ５５を介して共通サービス部５３から後述の通知（ｃａｌｌｂａｃｋ）を受け付ける。さらに、アプリサービス部５２はオンラインストレージ１３に対して認可要求やファイル転送なども行う。

共通サービス部５３及びストレージサービス部５４はプラットフォームＡＰＩ５５を介してサービスを提供する。共通サービス部５３は共通サービスを提供するプログラムにより実現される。また、ストレージサービス部５４はストレージサービスを提供するプログラムにより実現される。

例えばデバイス装置１１に搭載されたデバイスアプリ部３１はプラットフォームＡＰＩ５５を介してストレージサービス部５４にプロファイル情報の取得やファイル登録などの要求を行う。

このように、共通サービス部５３及びストレージサービス部５４はプラットフォームＡＰＩ５５を介してサービスの提供を行うＡＰＩ提供領域に存在する。通知サービス部６１は通知登録された内容に基づき、データなどの追加／変更／削除といったイベントに合わせて通知を行う。なお、通知サービス部６１は、デバイス装置１１のデバイスアプリ部３１とアプリサービス部５２とが直接通信しなくなったことにより即時性が失われることを後述のように防いでいる。

ジョブ実行部６２はジョブ実行の要求に基づき、ジョブを実行する。データストレージ部７１はデバイス装置１１のデバイスアプリ部３１とサービス提供システム２０のアプリサービス部５２との間でやり取りしたいデータを保存する。ファイルストレージ部７２はデバイス装置１１のデバイスアプリ部３１とサービス提供システム２０のアプリサービス部５２との間でやり取りしたいファイルを保存する。

本実施形態に係るサービス提供システム２０はＡＰＩ提供領域に共通サービス部５３及びストレージサービス部５４を有するプラットフォームが存在する。プラットフォームはデバイスアプリ部３１とアプリサービス部５２との間でデータ及びファイルを交換できるストレージサービス部５４を用意している。また、プラットフォームはストレージサービス部５４のデータ及びファイルの状態変化をアプリサービス部５２に通知する通知サービス部６１を用意している。

このように、本実施形態に係るサービス提供システム２０はデバイス装置１１のデバイスアプリ部３１とアプリサービス部５２とが直接アクセスしないようなプラットフォームを実装している。

本実施形態のサービス提供システム２０はデバイス装置１１のデバイスアプリ部３１とアプリサービス部５２とが直接通信しないような仕組みのプラットフォームを用意することでデバイスアプリ部３１とアプリサービス部５２との依存を疎にしている。

したがって、本実施形態のデバイスアプリ部３１とアプリサービス部５２との開発はプラットフォームＡＰＩ５５の知識があればよく、デバイスアプリ部３１とアプリサービス部５２との開発が容易となる。

また、本実施形態のサービス提供システム２０はストレージサービス部５４がデータストレージ部７１とファイルストレージ部７２とを分離しているため、容量（データ量）が少なく応答性能への要求が高いデータストレージ部７１のデータ交換性能に対応しやすくなる。

したがって、本実施形態のサービス提供システム２０はデバイスアプリ部３１とアプリサービス部５２とのデータ交換の応答性能の劣化を防止できる。

＜処理の詳細＞
まず、本実施形態のサービス提供システム２０の理解を容易とするため、デバイス装置１１のデバイスアプリ部３１とアプリサービス部５２とが直接通信する仕組みについて説明する。

図４はデバイス装置のデバイスアプリ部とアプリサービス部とが直接通信する仕組みの一例について説明する図である。なお、図４では説明に不要な部分についての図示を省略している。

図４ではデバイス装置１１のデバイスアプリ部３１がアプリサービス部５２に対してプロファイル情報の取得やファイル登録などの要求を行う。アプリサービス部５２は独自に管理するＤＢ５６にプロファイル情報を保存する。また、アプリサービス部５２は共通サービス部５３又はストレージサービス部５４にファイル保存／取得やジョブ実行などの要求を行う。

このように、図４ではデバイス装置１１のデバイスアプリ部３１とアプリサービス部５２とが直接通信する仕組みであるため、デバイスアプリ部３１とアプリサービス部５２とが密に依存する。例えばデバイスアプリ部３１とアプリサービス部５２とが直接通信する構成では独自のプロトコルが利用される場合もある。

デバイスアプリ部３１及びアプリサービス部５２をサードベンダなどの外部の開発者が開発した場合は、デバイスアプリ部３１とアプリサービス部５２との通信のプロトコルをサービス提供システム２０を運用する企業で制御できない場合があった。

また、図４のデバイスアプリ部３１とアプリサービス部５２とが２つになると、サービス提供システム２０は図５に示すようになる。図５はデバイス装置のデバイスアプリ部とアプリサービス部とが直接通信する仕組みの他の例について説明する図である。なお、図５では説明に不要な部分についての図示を省略している。

図５ではデバイス装置１１のデバイスアプリ部３１Ａがアプリサービス部５２Ａに対してプロファイル情報の取得やファイル登録などの要求を行う。また、図５ではデバイス装置１１のデバイスアプリ部３１Ｂがアプリサービス部５２Ｂに対してプロファイル情報の取得やファイル登録などの要求を行う。

このように、図５ではデバイス装置１１のデバイスアプリ部３１Ａとアプリサービス部５２Ａとが直接通信する仕組みであるため、デバイスアプリ部３１Ａとアプリサービス部５２Ａとが密に依存する。また、図５ではデバイス装置１１のデバイスアプリ部３１Ｂとアプリサービス部５２Ｂとが直接通信する仕組みであるため、デバイスアプリ部３１Ｂとアプリサービス部５２Ｂとが密に依存する。

例えばデバイスアプリ部３１Ａとアプリサービス部５２Ａとが直接通信に利用する独自のプロトコルと、デバイスアプリ部３１Ｂとアプリサービス部５２Ｂとが直接通信に利用する独自のプロトコルとは、異なる場合もある。

このように、デバイスアプリ部３１とアプリサービス部５２とが２つになると、デバイスアプリ部３１とアプリサービス部５２との依存関係はより複雑になる。

そこで、本実施形態のサービス提供システム２０はデバイス装置１１のデバイスアプリ部３１とアプリサービス部５２とが直接通信しない図６の仕組みのプラットフォームを用意して、デバイスアプリ部３１とアプリサービス部５２との依存を疎にしている。

図６はデバイス装置のデバイスアプリ部とアプリサービス部とが直接通信しない仕組みの一例について説明する図である。なお、図６では説明に不要な部分についての図示を省略している。

図６ではデバイス装置１１のデバイスアプリ部３１がプラットフォームＡＰＩ５５を介してプロファイル情報の取得やファイル登録などの要求を行う。つまり、デバイスアプリ部３１はアプリサービス部５２と直接通信を行わないため、アプリサービス部５２との依存関係が疎となる。

アプリサービス部５２はポータルサービス部５１から連携設定やプロファイル設定などの要求を受け付ける。アプリサービス部５２はプラットフォームＡＰＩ５５を介してプロファイル情報の保存をデータストレージ部７１に要求する。アプリサービス部５２はプラットフォームＡＰＩ５５を介してジョブデータやデータの取得をファイルストレージ部７２に要求する。

また、アプリサービス部５２はプラットフォームＡＰＩ５５を介して通知サービス部６１に後述の通知（ｃａｌｌｂａｃｋ）登録を要求する。アプリサービス部５２は通知登録に基づき、プラットフォームＡＰＩ５５を介して共通サービス部５３から後述の通知を受け付ける。通知を受け付けることにより、アプリサービス部５２はデバイスアプリ部３１がプラットフォームＡＰＩ５５を介して行うデータなどの追加／変更／削除といったイベントを監視できる。また、アプリサービス部５２はプラットフォームＡＰＩ５５を介してジョブ実行部６２にジョブ実行の要求を行う。

このように本実施形態のサービス提供システム２０は図６の仕組みのプラットフォームを用意することで、デバイスアプリ部３１とアプリサービス部５２とをプラットフォームＡＰＩ５５により分断している。サービス提供システム２０はデバイスアプリ部３１及びアプリサービス部５２のそれぞれに対して規定のＡＰＩ仕様を提供することで、デバイスアプリ部３１及びアプリサービス部５２との通信手段を標準化している。

《スキャン画像をオンラインストレージ１３に保存》
図７は、本実施形態に係るサービス提供システムの処理手順を表した一例のシーケンス図である。図７はサービス提供システム２０の処理手順の一例としてスキャン画像をオンラインストレージ１３に保存する処理手順を表している。

ステップＳ１において、アプリサービス部５２は通知サービス部６１に対して連携設定に基づく通知登録を行う。通知登録には、例えばアプリ名、対象イベント、通知先などの情報が含まれる。

ステップＳ２において、アプリサービス部５２はポータルサービス部５１からスキャン設定（プロファイル設定）の要求を受け付ける。ステップＳ３において、アプリサービス部５２はアプリ名と対応付けてスキャン設定をデータストレージ部７１に保存させる。

ステップＳ４において、デバイスアプリ部３１はデータストレージ部７１からアプリ名に対応付いたスキャン設定を取得する。ステップＳ５において、デバイスアプリ部３１は取得したスキャン設定に基づき、デバイス装置１１にスキャンを実行させる。

ステップＳ６において、デバイスアプリ部３１はアプリ名とファイル名とを指定してスキャン画像のファイルをファイルストレージ部７２に登録させる。ファイルが登録されたファイルストレージ部７２はステップＳ７において、アプリ名、イベントタイプ、ファイル名を指定したイベント発行を通知サービス部６１に通知する。

ステップＳ８において、通知サービス部６１はステップＳ１で通知登録された内容とステップＳ７で通知されたイベント発行の内容とに基づき、イベントチェックを行う。通知サービス部６１は、ステップＳ１で通知登録されたアプリ名、対象イベントの内容と、ステップＳ７で通知されたイベント発行のアプリ名、イベントタイプの内容とが合致するときに、ステップＳ１で通知登録された通知先にイベント発行を通知する。ステップＳ９のイベント発行の通知にはイベントタイプとファイル名とが含まれる。

イベント発行が通知されると、アプリサービス部５２はアプリ名とイベント発行の通知に含まれるファイル名とを指定してスキャン画像のファイルをファイルストレージ部７２から取得する。

また、ステップＳ１１において、アプリサービス部５２はアプリ名を指定してデータストレージ部７１からスキャン設定を取得する。ステップＳ１２において、アプリサービス部５２は取得したスキャン設定に基づき、スキャン画像のファイルを例えばオンラインストレージ１３に保存させるファイル送信処理を行う。

図７のシーケンス図に示したサービス提供システム２０の処理によれば、デバイスアプリ部３１とアプリサービス部５２とが直接通信しなくても、デバイスアプリ部３１とアプリサービス部５２とが連携して処理を行うことができる。

《通知サービス部に通知登録する内容》
図８は通知サービス部に通知登録される内容の一例について説明する図である。図８に示すように、通知サービス部６１には複数のトリガ（ｔｒｉｇｇｅｒｓ）を登録することができる。トリガはアプリサービス部５２への通知対象として登録される事象の情報の一例である。

各トリガはトリガＩＤ（Ｔｒｉｇｇｅｒ＿ｉｄ）が付与されると共に、対象（Ｔａｒｇｅｔ）と、発生イベント（Ｅｖｅｎｔ）と、行動（Ａｃｔｉｏｎ）とが関連付けられてパラメータにより定義される。対象は対象となるリソースのＩＤを定義する。発生イベントはファイル種別やイベント種別（生成／更新／削除）を定義する。発生イベントには拡張パラメータを定義するようにしてもよい。行動は対象に発生イベントが生じたときに行う処理を定義する。例えば行動が通知である場合には通知先やリトライ回数、リトライ間隔などが定義される。

通知サービス部６１は図８のようなパラメータにより定義されるトリガにより例えば以下のような通知を行うことができる。図９は通知サービス部の処理の一例について説明する図である。

ステップＳ２１において、アプリサービス部５２は例えば図９の右側に図示しているトリガ（Ｔｒｉｇｇｅｒ１）の通知登録を行う。トリガ（Ｔｒｉｇｇｅｒ１）は対象（Ｔａｒｇｅｔ）として記憶場所を表す
「ｆｏｌｄｅｒ＿ｉｄ：ｘｘｘ」
が定義されている。

また、発生イベント（Ｅｖｅｎｔ）として
「ｄａｔａ＿ｔｙｐｅ：Ｆｉｌｅ」
「ｅｖｅｎｔ＿ｔｙｐｅ：ｃｒｅａｔｅ」
「ｅｘ＿ｐａｒａｍ：ｆｉｌｅ＿ｔｙｐｅ：ｉｍａｇｅ／ｊｐｅｇ」
が定義されている。

また、行動（Ａｃｔｉｏｎ）として
「ｃａｌｌｂａｃｋ」
が定義されている。

ステップＳ２２において、デバイスアプリ部３１は「ｆｏｌｄｅｒ＿ｉｄ：ｘｘｘ」のフォルダへのファイルのアップロードをファイルストレージ部７２に要求し、ファイルをファイルストレージ部７２に登録させる。

ファイルストレージ部７２は、デバイスアプリ部３１のアプリ名、イベントタイプとしての「ｃｒｅａｔｅ」及びファイル名を指定したイベント発行を通知サービス部６１に通知する。

通知サービス部６１はステップＳ２１で通知登録されたトリガ（Ｔｒｉｇｇｅｒ１）の内容とファイルストレージ部７２から通知されたイベント発行の内容とに基づき、イベントチェックを行う。図９ではファイルストレージ部７２から通知されたイベント発行の内容がトリガ（Ｔｒｉｇｇｅｒ１）の内容と合致している。

したがって、通知サービス部６１はステップＳ２３において、ステップＳ２１で通知登録されたトリガ（Ｔｒｉｇｇｅｒ１）の行動（Ａｃｔｉｏｎ）に定義されたｃａｌｌｂａｃｋに基づき、アプリサービス部５２にイベント発行を通知できる。

図１０は通知サービス部の処理の他の例について説明する図である。ステップＳ３０において、アプリサービス部５２は例えば図１０の右側に図示しているトリガ（Ｔｒｉｇｇｅｒ１）の通知登録を行う。

トリガ（Ｔｒｉｇｇｅｒ１）は対象（Ｔａｒｇｅｔ）として
「ｆｏｌｄｅｒ＿ｉｄ：ｘｘｘ＿ｍｆｐ＿ｉｎｐｕｔ」
が定義されている。

また、発生イベント（Ｅｖｅｎｔ）として
「ｄａｔａ＿ｔｙｐｅ：Ｆｉｌｅ」
「ｅｖｅｎｔ＿ｔｙｐｅ：ｃｒｅａｔｅ」
「ｅｘ＿ｐａｒａｍ：ｆｉｌｅ＿ｔｙｐｅ：ｉｍａｇｅ／ｊｐｅｇ」
が定義されている。

また、行動（Ａｃｔｉｏｎ）として
「ｃａｌｌｂａｃｋ
ｃａｌｌｂａｃｋ＿ｕｒｌ：ｈｔｔｐ：／／ｘｘｘｘｘｘ／ｍｆｐｉｎｐｕｔ」
が定義されている。

ステップＳ３１において、アプリサービス部５２は例えば図１０の右側に図示しているトリガ（Ｔｒｉｇｇｅｒ２）の通知登録を行う。

トリガ（Ｔｒｉｇｇｅｒ２）は対象（Ｔａｒｇｅｔ）として
「ｆｏｌｄｅｒ＿ｉｄ：ｙｙｙ＿ｃｏｎｖ＿ｏｕｔｐｕｔ」
が定義されている。

また、発生イベント（Ｅｖｅｎｔ）として
「ｄａｔａ＿ｔｙｐｅ：Ｆｉｌｅ」
「ｅｖｅｎｔ＿ｔｙｐｅ：ｃｒｅａｔｅ」
「ｅｘ＿ｐａｒａｍ：ｆｉｌｅ＿ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｐｄｆ」
が定義されている。

また、行動（Ａｃｔｉｏｎ）として
「ｃａｌｌｂａｃｋ
ｃａｌｌｂａｃｋ＿ｕｒｌ：ｈｔｔｐ：／／ｘｘｘｘｘｘ／ｃｏｎｖｏｕｔｐｕｔ」
が定義されている。

ステップＳ３２において、デバイスアプリ部３１は「ｆｏｌｄｅｒ＿ｉｄ：ｘｘｘ＿ｍｆｐ＿ｉｎｐｕｔ」のフォルダへのファイルのアップロードをファイルストレージ部７２に要求し、ファイルをファイルストレージ部７２に登録させる。

ファイルストレージ部７２は、デバイスアプリ部３１のアプリ名、イベントタイプとしての「ｃｒｅａｔｅ」及びファイル名を指定したイベント発行を通知サービス部６１に通知する。

通知サービス部６１はステップＳ３０で通知登録されたトリガ（Ｔｒｉｇｇｅｒ１）の内容とファイルストレージ部７２から通知されたイベント発行の内容とに基づき、イベントチェックを行う。図１０ではファイルストレージ部７２から通知されたイベント発行の内容がトリガ（Ｔｒｉｇｇｅｒ１）の内容と合致している。

したがって、通知サービス部６１はステップＳ３３において、ステップＳ３０で通知登録されたトリガ（Ｔｒｉｇｇｅｒ１）の行動（Ａｃｔｉｏｎ）に定義されたｃａｌｌｂａｃｋに基づき、アプリサービス部５２にイベント発行を通知できる。

そして、ステップＳ３４において、アプリサービス部５２はステップＳ３３で通知されたイベント発行に基づき「ｈｔｔｐ：／／ｘｘｘｘｘｘ／ｍｆｐｉｎｐｕｔ」の処理を実行する。ステップＳ３５において、アプリサービス部５２は「ｆｏｌｄｅｒ＿ｉｄ：ｘｘｘ＿ｍｆｐ＿ｉｎｐｕｔ」のフォルダへ登録されたファイルを取得する。

ステップＳ３６において、アプリサービス部５２は取得したファイルを用いるジョブを生成してジョブ実行部６２にジョブ実行の要求を登録する。なお、ジョブにはジョブ実行の結果であるファイルの出力先として「ｆｏｌｄｅｒ＿ｉｄ：ｙｙｙ＿ｃｏｎｖ＿ｏｕｔｐｕｔ」を指定しておく。

ステップＳ３７において、ジョブ実行部６２はジョブ実行の要求に基づき、ファイルを用いるジョブ（例えばファイルのデータ変換処理など）を実行する。ステップＳ３８において、ジョブ実行部６２はジョブ実行の結果であるファイルを、指定された出力先であるフォルダ「ｆｏｌｄｅｒ＿ｉｄ：ｙｙｙ＿ｃｏｎｖ＿ｏｕｔｐｕｔ」に出力する。ファイルストレージ部７２は、アプリ名、イベントタイプとしての「ｃｒｅａｔｅ」及びファイル名を指定したイベント発行を通知サービス部６１に通知する。

通知サービス部６１はステップＳ３１で通知登録されたトリガ（Ｔｒｉｇｇｅｒ２）の内容とファイルストレージ部７２から通知されたイベント発行の内容とに基づき、イベントチェックを行う。図１０ではファイルストレージ部７２から通知されたイベント発行の内容がトリガ（Ｔｒｉｇｇｅｒ２）の内容と合致しているものとする。

通知サービス部６１はステップＳ３９において、ステップＳ３１で通知登録されたトリガ（Ｔｒｉｇｇｅｒ２）の行動（Ａｃｔｉｏｎ）に定義されたｃａｌｌｂａｃｋに基づいてアプリサービス部５２にイベント発行を通知できる。

そして、ステップＳ４０において、アプリサービス部５２はステップＳ３９で通知されたイベント発行に基づき「ｈｔｔｐ：／／ｘｘｘｘｘｘ／ｃｏｎｖｏｕｔｐｕｔ」の処理を実行する。

ステップＳ４１において、アプリサービス部５２は「ｆｏｌｄｅｒ＿ｉｄ：ｙｙｙ＿ｃｏｎｖ＿ｏｕｔｐｕｔ」のフォルダに出力されたジョブ実行の結果であるファイルを取得できる。

（まとめ）
第１の実施形態に係るサービス提供システム２０によれば、デバイスアプリ部３１とアプリサービス部５２とが直接通信しないような仕組みのプラットフォームを用意することでデバイスアプリ部３１とアプリサービス部５２との依存を疎にしている。

したがって、本実施形態のデバイスアプリ部３１とアプリサービス部５２との開発はプラットフォームＡＰＩ５５の知識があればよく、デバイスアプリ部３１とアプリサービス部５２との開発が容易となる。また、ＡＰＩ提供領域に存在する共通サービス部５３及びストレージサービス部５４を有するプラットフォームをデバイス装置１１のクラウド基盤などとして広く利用してもらうことが容易となる。

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

なお、プラットフォームＡＰＩ５５は要求受付手段の一例である。データストレージ部７１及びファイルストレージ部７２は記憶手段の一例である。通知サービス部６１は通知手段の一例である。イベントは事象の一例である。

１ 情報処理システム
１１ デバイス装置
１２ 端末装置
１３ オンラインストレージ
２０ サービス提供システム
２１ アクセス制御装置
２２ ポータルサービス提供装置
２３ アプリサービス提供装置
２４ 共通サービス提供装置
２５ ストレージサービス提供装置
３１ デバイスアプリ部
５１ ポータルサービス部
５２ プリントサービス部
５３ 共通サービス部
５４ ストレージサービス部
５５ プラットフォームＡＰＩ
５６ データベース（ＤＢ）
６１ 通知サービス部
６２ ジョブ実行部
７１ データストレージ部
７２ ファイルストレージ部
５００ コンピュータ
５０１ 入力装置
５０２ 表示装置
５０３ 外部Ｉ／Ｆ
５０３ａ 記録媒体
５０４ ＲＡＭ
５０５ ＲＯＭ
５０６ ＣＰＵ
５０７ 通信Ｉ／Ｆ
５０８ ＨＤＤ
Ｂ バス
Ｎ１〜Ｎ２ ネットワーク

特開２０１３−７７２７９号公報

Claims (8)

1. 電子機器に搭載されているアプリケーションと連携してサービスを提供するサービス提供システムであって、
   前記アプリケーションと連携して処理を行うアプリサービス提供手段と、
   前記アプリケーション及び前記アプリサービス提供手段からの要求を受け付ける要求受付手段と、
   前記アプリケーション及び前記アプリサービス提供手段が前記要求受付手段を介して共通に利用する記憶手段と、
   前記アプリサービス提供手段への通知対象として登録されている事象が前記記憶手段において発生したときに、前記要求受付手段を介して前記アプリサービス提供手段に通知を行う通知手段と
   を有することを特徴とするサービス提供システム。
2. 前記通知手段は、前記アプリサービス提供手段から前記要求受付手段を介して前記アプリサービス提供手段への通知対象とする事象の登録を受けること
   を特徴とする請求項１記載のサービス提供システム。
3. 前記通知手段は、前記アプリサービス提供手段への通知対象として、事象の発生を監視する前記記憶手段の記憶場所と、事象の種別と、通知を行う通知先とを関連付けて登録すること
   を特徴とする請求項１又は２記載のサービス提供システム。
4. 前記記憶手段は、前記アプリケーション及び前記アプリサービス提供手段が第１の情報をやり取りする第１の記憶手段と、
   前記アプリケーション及び前記アプリサービス提供手段が第１の情報よりもデータ量が大きい第２の情報をやり取りする第２の記憶手段と、を有すること
   を特徴とする請求項１乃至３何れか一項記載のサービス提供システム。
5. 前記通知手段は、前記アプリサービス提供手段への通知対象として登録されている前記アプリケーションから前記記憶手段への情報の登録が前記記憶手段において発生したときに、前記要求受付手段を介して前記アプリサービス提供手段に通知を行うこと
   を特徴とする請求項１乃至４何れか一項記載のサービス提供システム。
6. 前記記憶手段に登録されている情報を用いて処理を行う処理実行手段を更に有し、
   前記通知手段は前記アプリサービス提供手段への通知対象として登録されている前記処理実行手段から前記記憶手段への情報の登録が前記記憶手段において発生したとき、前記要求受付手段を介して前記アプリサービス提供手段に通知を行うこと
   を特徴とする請求項１乃至５何れか一項記載のサービス提供システム。
7. 前記要求受付手段は、ＡＰＩ（Application Programming Interface）であること
   を特徴とする請求項１乃至６何れか一項記載のサービス提供システム。
8. 電子機器に搭載されているアプリケーションと連携してサービスを提供するサービス提供システムにおいて実行されるサービス提供方法であって、
   前記アプリケーションと、前記アプリケーションと連携して処理を行うアプリサービス提供手段とが、前記アプリケーション及び前記アプリサービス提供手段からの要求を受け付ける要求受付手段を介して要求を行う要求ステップと、
   前記アプリケーション及び前記アプリサービス提供手段が前記要求受付手段を介して共通に利用する記憶手段において、前記アプリサービス提供手段への通知対象として登録されている事象が発生したときに、前記要求受付手段を介して前記アプリサービス提供手段に通知を行う通知ステップと
   を有することを特徴とするサービス提供方法。

Images