JP6845477B2 - 情報処理装置およびコンピュータプログラム - Google Patents

Description

本発明は複数のアプリケーションプログラムないしアプリケーションサービス（以下、ＡＰと称する）を連携させる情報処理装置に関する。

複数のＡＰを連携させるアプリ連携サービスが知られている。例えば、特許文献１には、ユーザ毎に実行可能な複数のＡＰを連携させる業務統合装置が開示されている。特許文献１に開示された業務統合装置は、ユーザにより選択されたＡＰに連携するＡＰの実行を要求すると、所定の連携キー（プロセス番号）を用いて、その連携するＡＰを実行し、実行結果を表示する。このような業務統合装置では、あるＡＰの起動時に入力したデータが他のＡＰでも利用できるため、無駄や入力ミスのないサービスを提供することができる。また、最近は、ユーザのスケジュールを管理するスケジュールＡＰ、経路探索ＡＰ、旅費精算ＡＰなどのように、業務に密接に関連するＡＰ同士を連携させ、スケジュールＡＰにデータが入力されたときは、そのデータを他のＡＰでも活用することも行われている。

特開２００４−１５７６７６公報

従来のアプリ連携サービスは、システム側が予め用意したＡＰを連携させるものであり、ユーザが通常使用しているＡＰを任意に連携させるものではない。ユーザによっては、システム側が用意したＡＰではなく、自分が使い慣れたＡＰ同士を連携させることがこの種の技術の普及につながると考えられる。
また、従来のアプリ連携システムでは、例えばＡ，Ｂ，Ｃ，Ｄの４つのＡＰを相互に連携させようとすると、Ａ−Ｂ，Ａ−Ｃ，Ａ−Ｄ，Ｂ−Ｃ，Ｂ−Ｄ，Ｃ−Ｄのように６回の連携を可能にするためのシステム開発作業が必要となる。連携させるＡＰをさらに増やす度に、それ以前に存在するＡＰとの連携のための開発作業がさらに必要となり、アプリ連携を実現する際の作業が飛躍的に増大する。さらに、用意された全てのＡＰにおいてデータを共用できない場合、あるいは共用の必要がない場合、当該データを有効に活用することができないという課題が残る。

本発明の課題は、ユーザの使用感を高め、かつ、ユーザが使用するＡＰが増えても連携のための開発作業を要しないアプリ連携方法およびこの方法の実施に適した情報処理装置を提供することにある。

本発明は、ユーザが操作するユーザ端末と、連携の対象として前記ユーザにより任意に選択されそれぞれ入力されたデータに基づいて所定の情報処理を実行する複数のＡＰの実行手段とが接続される装置であって、前記複数のＡＰ、各ＡＰの実行手段へのアクセスを可能にするユーザ情報、および、連携させるデータを特定するための特定記号とを登録する登録手段と、前記ユーザ端末から、登録された前記複数のＡＰのうち第１ＡＰに入力される第１データを取得する取得手段と、取得した前記第１データを所定基準に従って解析することにより前記第１データに前記特定記号が含まれているかどうかを判別する解析手段と、前記第１データに前記特定記号が含まれている場合、前記ユーザ端末からの指示を待つことなく、前記ユーザ情報を用いて前記第１ＡＰと異なる第２ＡＰの実行手段にアクセスして前記特定記号により特定される第２データを前記第２ＡＰの実行手段へ入力するとともに前記第２ＡＰの実行結果である第３データを取得し、さらに、前記ユーザ情報を用いて前記第１ＡＰおよび前記第２ＡＰと異なる第３ＡＰの実行手段へアクセスして前記第３データを前記第３ＡＰへ入力するとともに前記第３ＡＰの実行結果である第４データを取得する制御手段と、を備えたことを特徴とする情報処理装置である。

本発明によれば、ユーザが任意に選択した複数のＡＰおよびそれらの実行条件を登録し、ユーザ端末と各ＡＰの実行手段とを情報処理装置に中継させる。つまり、ＡＰ同士をダイレクトに連携させる必要がない。そのため、ユーザが使用するＡＰが増えても連携のための開発作業が不要となり、ユーザの使用感を高めたアプリ連携を容易に実現することができる。

本発明の実施形態に係るアプリ連携システムの全体構成図。 本実施形態におけるシステム連携態様を示す説明図。 本実施形態の中継サーバのハードウェア構成図。 本実施形態の中継サーバの機能構成図。 （ａ）はユーザテーブル、（ｂ）および（ｃ）はユーザ補助テーブルの例示図。 本実施形態におけるユーザ登録の手順説明図。 本実施形態におけるアプリ連携の手順説明図。 （ａ）〜（ｄ）はアプリ連携の具体例を示す説明図。 （ａ）〜（ｃ）はアプリ連携の他の具体例を示す説明図。 （ａ），（ｂ）はアプリ連携の他の具体例を示す説明図。 （ａ），（ｂ）はアプリ連携の他の具体例を示す説明図。 （ａ），（ｂ）はアプリ連携の他の具体例を示す説明図。 アプリ連携の他の具体例を示す説明図。 （ａ）〜（ｃ）はアプリ連携の他の具体例を示す説明図。 アプリ連携の他の具体例を示す説明図。

図１は、本発明の一実施形態に係るアプリ連携システムの全体構成図である。このアプリ連携システム１は、公衆通信回線を使用したネットワークＮＷ、例えばインターネットなどに接続される中継サーバ１０を含んで構成される。中継サーバ１０は、本発明の情報処理装置の一例となる装置であり、ユーザＤＢ（ＤＢはデータベースシステムの略、以下同じ）１１を備えている。中継サーバ１０の構成およびユーザＤＢ１１の内容については、後述する。

ネットワークＮＷには、基地局２０が接続されている。基地局２０は、ユーザ端末３０であるスマートフォンやパーソナルコンピュータ（ＰＣ）との間で通信を行う。なお、ユーザ端末３０は、有線通信によってダイレクトにネットワークＮＷに接続することもできる。ネットワークＮＷには、メールサーバ４１，ソーシャルネットワーク（ＳＮＳ）サーバ４２，予約サーバ４３，カレンダーＡＰサイト５１，経路案内ＡＰサイト５２，旅費精算ＡＰサイト５３，勤怠管理ＡＰサイト５４も接続されている。これらのサーバ４１〜４３，ＡＰサイト５１〜５４に存在するＡＰの実行条件として、ユーザ端末３０を操作するユーザの権限情報、アカウント情報その他のユーザ固有の設定情報が設定されている。

メールサーバ４１は、電子メールの送受信を行うメールＡＰの実行手段を許容する環境（実行環境）を提供する。ＳＮＳサーバ４２は、ユーザが所属する組織、本例では、ユーザの会社の社員が閲覧可能な掲示板ＡＰの実行環境を提供する。予約サーバ４３は、新幹線、航空機，フェリーなどのチケット、あるいは宿泊施設を予約する予約ＡＰの実行環境を提供する。本例では、チケット予約サイトや宿泊予約サイトへのアクセスを可能にする。カレンダーＡＰサイト５１は、ユーザごとのスケジュールの予定入力機能や予定管理機能などを有するカレンダーＡＰの実行環境を提供する。経路案内ＡＰサイト５２は、公共交通機関の時刻表や運賃の情報、経路探索機能、地図情報などを有する経路案内ＡＰの実行環境を提供する。この経路案内ＡＰは、出発地と目的地並びに出発時刻ないし到着時刻を指定する必要があるが、出発時刻ないし到着時刻の指定がない場合は、入力時点が出発時刻となる。旅費精算ＡＰサイト５３は、ユーザごとの経費登録機能、経費申請機能、経費承認機能、会計記録出力機能などの旅費精算ＡＰの実行環境を提供する。この旅費精算ＡＰは、１日又は１出張当たりの旅費精算申請書を自動的に生成し、印刷出力することができる。勤怠管理ＡＰサイト５４は、ユーザごとの出勤、欠勤、残業時間などを計算する機能を有する勤怠管理ＡＰの実行環境を提供する。この勤怠管理ＡＰは、１日又は１ヶ月単位の出勤簿を印刷出力することができる。これらのＡＰの中には同種機能を有する多くの種類のものが存在するが、ここでは、ユーザが通常使用しているＡＰの例を挙げる。

本実施形態のアプリ連携システム１は、図２に示されるように、中継サーバ１０が、ユーザ端末３０を含む全ての他のサーバ４１〜４３ないしＡＰサイト５１〜５４の中継を行う。すなわち、中継サーバ１０を中心として１：Ｎの関係で接続される。各ＡＰはそれぞれ中継サーバ１０と連携することで、結果的に中継サーバ１０を介して相互に連携して動作する。ＡＰ同士はダイレクトには連携しない。この場合、中継サーバ１０は、単なるポータルサイトとして、データの受け渡しをするのではなく、互いのＡＰの実行を操作するとともに、各ＡＰの実行結果を取得し、取得した実行結果を他の全てのＡＰが実行する処理に反映させるという能動的な動作を行う。

このように動作する中継サーバ１０のハードウエア構成図を図３に示す。中継サーバ１０は、制御バスＢ１を介して接続されたＣＰＵ１１０、ＲＡＭ１１１、ＲＯＭ１１２を主要部品として含む制御コンピュータを備えている。
ＣＰＵ（Central Processing Unit）１１０は、本発明のコンピュータプログラムを実行することにより、中継サーバとして動作する上で、必要な機能を構築する。ＲＡＭ（Random Access Memory）１１１は、ＣＰＵ１１０の主メモリ、ワークエリア等の一時記憶領域として用いられる書換可能なメモリである。ＲＯＭ（Read Only Memory）１１２は、各種デバイスドライバおよびパラメータデータなどが格納されている読出専用メモリである。

制御バスＢ１には、メモリＩ／Ｆ（Ｉ／Ｆはインタフェースの略、以下同じ）１１４、入出力Ｉ／Ｆ１１６、通信Ｉ／Ｆ１１８も接続されている。メモリＩ／Ｆ１１４はユーザＤＢ１１およびハードディスクなどの外部記憶装置ＳＴへの各種情報の格納および格納された各種情報の読み出しを行うためのインタフェースである。外部記憶装置ＳＴには、本発明のコンピュータプログラムなどが格納されている。入出力Ｉ／Ｆ１１６は、ディスプレイＤＰへの情報表示並びにキーボードＫＢなどの入力デバイスからのデータ入力を行うためのインタフェースである。通信Ｉ／Ｆ１１８は、ネットワークＮＷとの通信を可能にするインタフェースである。

次に、本発明のコンピュータプログラムにより中継サーバ１０に形成される各種機能ブロックについて説明する。図４は、中継サーバ１０の機能構成図である。中継サーバ１０は、ユーザが任意に選択した複数のＡＰの実行を中継する。そのために、主制御部１２０、通信制御部１２１、登録受付部１２２、ユーザ管理部１２３、解析部１２４、ＡＰ管理部１２５の機能ブロックを有する。通信制御部１２１は、ネットワークＮＷとの間の通信を制御することにより、図２に示した１：Ｎの双方向通信を可能にする。

登録受付部１２２は、中継する各ＡＰおよびそれらの実行条件、ユーザが予め登録した企業の名称、所在、最寄駅などを特定するための企業情報（ランドマーク）などをユーザ管理部１２３を介してユーザＤＢ１１に登録する登録手段として機能する。
ユーザ管理部１２３は、登録された複数のＡＰへのアクセス先、各ＡＰの権限情報、ユーザのアカウント情報を含むユーザプロファイル、ＡＰ同士を連携させる意図を表す情報、ランドマーク、および、各ＡＰの実行結果などをユーザ毎に分類し、分類結果をユーザＤＢ１１へ蓄積する。アクセス先は、本実施形態では当該ＡＰのＵＲＬ（Uniform Resource Locator）とする。各ＡＰの権限情報は、ＩＤ、パスワードなどである。ユーザのアカウント情報は、ユーザネーム、住所、勤務先およびその住所などである。ＡＰ同士を連携させる意図を表す情報は、あるＡＰを通じて入力されたデータに付加された特定記号ないしその組み合わせ、例えばアスタリスク記号や文字列をくくる鉤括弧などである。この情報は、ユーザが任意に設定可能なものである。

解析部１２４は、登録されたＡＰのうちユーザが最初にアクセスした任意のＡＰ（便宜上、第１ＡＰと称する）を通じて入力されたデータを所定基準に基づいて解析することにより、当該データに第１ＡＰと異なる他のＡＰと連携させる意図を表す情報が含まれているかどうかを判別する。所定基準は、例えばデータに含まれる文字列（数字、記号を含む）の形態素解析により品詞を分類する基準である。本例では、上記の「意図を表す情報」の有無およびその記述内容を判別する。例えば、データに含まれる文字列に名詞が含まれている場合、その名詞の前に「意図を表す情報」が付されているか否かなどを判別する。以後の説明では、「意図を表す情報」が鉤括弧のような特定記号であるものとして説明する。

ＡＰ管理部１２５は、ユーザＤＢ１１においてユーザが登録した複数のＡＰおよびその実行条件などをＡＰ毎に管理する。例えばユーザが第１ＡＰと、それに連携可能な他のＡＰ（第１ＡＰと区別するため、「第２ＡＰ」、「第３ＡＰ」、「第４ＡＰ」・・・などと称する場合がある）とを特定可能にする。

主制御部１２０は、解析部１２４およびＡＰ管理部１２５と協働して、ユーザ端末３０からの明示のアクセスないし実行の指示を待つことなく、また、複数のＡＰ同士をダイレクトに連携させることなく、中継サーバ１０を介して連携させる制御手段として機能する。各ＡＰへのアクセスは通信制御部１２１を通じて行う。例えば、解析部１２４による解析の結果、第１ＡＰを通じて入力されたデータに上記特定記号が含まれているときに当該データを入力データとする第２ＡＰをＡＰ管理部１２５を通じて特定する。そして、特定された第２ＡＰに対して当該ＡＰの実行条件を基に所用の情報処理を実行させるとともに、該第２ＡＰによる実行結果を受領し、受領した実行結果を他のＡＰが実行する処理に反映させる。

主制御部１２０は、また、第２ＡＰによる実行結果を第１ＡＰが実行する処理に反映させた後、第１ＡＰに新たに入力されたデータに基づく第１ＡＰの実行結果とそれまでの実行結果とを比較する。そして、両立するかどうかを当該新たに入力されたデータに基づく第２ＡＰの実行結果に基づいて判定する。両立できない場合は、新たに入力されたデータに基づいて第１ＡＰを再実行させる。例えば、それまでの実行結果では、移動中であるべき時間帯にどこかの場所を訪問するスケジュールでは、両立できないので、第１ＡＰおよび第２ＡＰを再実行させることになる。

主制御部１２０は、また、取得した第２ＡＰの実行結果に基づき、当該実行結果を入力データとして第２ＡＰと異なる情報処理を実行する第３ＡＰを特定し、特定した第３ＡＰに対して当該情報処理を実行させる。あるいは、取得した第２ＡＰの実行結果に基づき、当該実行結果を入力データとして第２ＡＰおよび第３ＡＰと異なる情報処理を実行する第４ＡＰを特定し、特定した第４ＡＰに対して当該情報処理を実行させる。さらに、第１ＡＰないし第４ＡＰのいずれかのＡＰに入力されるデータが修正されたときは、該修正後のデータに基づいて各ＡＰを再実行し、これにより、既存の実行結果を更新する。

次に、ユーザＤＢ１１への格納情報について説明する。ユーザＤＢ１１は、登録受付部１２２でユーザ端末３０からの登録を受け付け、ユーザ管理部１２３を通じて分類された情報を、ユーザテーブルおよび補助テーブルの形式で格納する。
ユーザテーブルには、このアプリ連携システム１におけるユーザ認証に用いる権限情報と、ユーザが任意に選択した使用ＡＰの名称、そのアカウント情報、補助テーブル名などが格納される。補助テーブルには、ＡＰ毎の実行条件などが格納される。図５（ａ）はユーザテーブルの例示図、同（ｂ），（ｃ）はユーザの識別情報（ＭＴ００１）により関連付けられた補助テーブルの例示図である。図５（ｂ）は、経路案内ＡＰの実行条件が格納されている補助テーブルの例であり、ＭＴ００１１のテーブル番号により、図５（ａ）のユーザテーブルと関連付けられている。図示の例では、経路探索を平均モードで行い、飛行機、新幹線、有料特急は利用するが、バスや船は利用しないという条件が格納されている。図５（ｃ）は予約ＡＰの実行条件が格納されている補助テーブルの例である。すなわち、チケット予約の場合は乗車券のみ（指定席や特急券は不要）であり、宿泊予約の場合は、上限１万円という条件である。その他、禁煙ルームを希望するという希望情報や、宿泊予約に関しては仮予約にとどめ、正式予約は手動で確定するといった実行範囲を定める情報を含めてもよい。

＜運用形態例＞
次に、アプリ連携システム１の運用形態例について説明する。ユーザは、アプリ連携システム１に、まずユーザ登録を行う。このときの中継サーバ１０の登録受付部１２２が行う処理の手順を示したのが図６である。図６を参照すると、登録受付部１２２は、前述のユーザプロファイルの入力を待つ（Ｓ１０１：Ｎ）。通信制御部１２１を通じてユーザプロファイルが入力されると（Ｓ１０１：Ｙ）、登録受付部１２２は、そのユーザのユーザテーブルを作成し、ユーザＤＢ１１へ格納する。その後、ユーザが使用するＡＰ、アカウント情報などの入力を待つ（Ｓ１０３：Ｎ）。これらの情報が入力されると（Ｓ１０３：Ｙ）、登録受付部１２２はユーザテーブルへ登録する（Ｓ１０４）。このとき、ＡＰ毎の実行条件があるかどうかをユーザ端末３０へ問い合わせる（Ｓ１０５：Ｎ）。条件入力がある場合（Ｓ１０５：Ｙ）、登録受付部１２２は、そのユーザの補助テーブルを作成し、入力された実行条件を登録した後、ユーザテーブルと関連付けてユーザＤＢ１１へ格納する（Ｓ１０６）。その後、全てのＡＰについての登録が終了したかどうかをユーザ端末３０へ問い合わせる（Ｓ１０７）。

なお、Ｓ１０５において条件入力がない場合は、ただちにＳ１０７の処理に移る（Ｓ１０５：Ｎ）。ユーザが使用するＡＰが他に存在する場合（Ｓ１０７：Ｎ）、登録受付部１２２は、Ｓ１０２以降の処理を繰り返す。全てのＡＰについての登録が済んだ場合（Ｓ１０７：Ｙ）、登録受付部１２２は、ユーザ登録の処理を終了させる。

ユーザ登録後、第１ＡＰと第２ＡＰとのアプリ連携を中継する場合の中継サーバ１０の処理の手順例を図７に示す。図７の処理は、中継サーバ１０の主制御部１２０が実行する。ユーザがユーザ端末３０を操作し、中継サーバ１０にアクセスすると、主制御部１２０は、ユーザ認証を行う（Ｓ２０１）。ユーザ認証は、図５に示したユーザテーブルの権限情報に基づいて行う。ユーザ認証を終えると、主制御部１２０は、ユーザ端末３０による第１ＡＰの起動を待つ（Ｓ２０２：Ｎ）。つまり、最初のＡＰはユーザ端末３０によりアクセスされ、起動される。第１ＡＰが起動されると、主制御部１２０は、第１ＡＰへのデータ入力を待つ（Ｓ２０３：Ｎ）。データ入力があると（Ｓ２０３：Ｙ）、主制御部１２０は、解析部１２４にデータ解析を行わせ、その結果を待つ（Ｓ２０４）。データ解析の結果、入力データに特定記号が付加されていると判定された場合（Ｓ２０５：Ｙ）、主制御部１２０は、ＡＰ管理部１２５に、当該特定記号が付加されたデータを入力データとする第２ＡＰを特定させる。そして特定された第２ＡＰについてのアカウント情報をもとに第２ＡＰにアクセスし、所用の情報処理を実行させ（Ｓ２０６）、実行結果を待つ（Ｓ２０７：Ｎ）。実行結果を受領した場合（Ｓ２０７：Ｙ）、主制御部１２０は、その実行結果を第１ＡＰが実行する処理に反映させる（Ｓ２０８）。

なお、Ｓ２０５において特定記号が付加されていないと判定された場合（Ｓ２０５：Ｎ）、主制御部１２０は、アプリ連携の必要がないと判断し、ただちにそのデータを第１ＡＰの処理に反映させる。その後、修正の必要がないかどうかをユーザ端末３０へ問い合わせる。ユーザ端末３０から修正データが入力された場合（Ｓ２０９：Ｙ）、主制御部１２０は、Ｓ２０４以降の処理を繰り返す。修正データの入力がない（修正の必要がない）場合（Ｓ２０９：Ｎ）、主制御部１２０は、第１ＡＰと第２ＡＰとのアプリ連携の中継処理を終了する。

第２ＡＰの実行結果に基づいて第３ＡＰ、第４ＡＰを連鎖的に実行する場合、主制御部１２０は、Ｓ２０８の処理後、第３ＡＰ，第４ＡＰおよびそのアカウント情報並びに実行条件などをＡＰ管理部１２５に特定させ、それらのＡＰの実行環境を提供するサーバないしサイトへアクセスし、それぞれの実行結果を受領することになる。そして、必要に応じて実行結果を他のＡＰが実行する処理に反映させる。あるいは、実行結果を第２ＡＰの処理に反映させる。なお、第１ＡＰ以外の他のＡＰは、ユーザ端末３０からの明示の実行指示を待たずに実行する。

＜具体例１＞
次に、図２に示された連携関係に基づいて、ユーザが実際にアプリ連携システム１を利用する場合の具体例を説明する。
図８は、カレンダーＡＰサイト５１のカレンダーＡＰ、経路案内ＡＰサイト５２の経路案内ＡＰ、旅費精算ＡＰサイト５３の旅費精算ＡＰを連携させ、ユーザが、顧客先への訪問スケジュールをカレンダーＡＰに入力する場合の例を示す。前提として、ユーザＤＢ１１のユーザプロファイルは、自宅および勤務先の住所が東京２３区内で、勤務時間が午前８時から午後６時のように設定されているものとする。なお、各ＡＰの実行状況は、ユーザ端末３０が備える表示部の画面で随時確認することができる。

図８（ａ）は、ユーザが中継サーバ１０にユーザ登録を行った後、カレンダーＡＰにアクセスし、スケジュールデータの入力を行った場合の例を示す。すなわち、カレンダーＡＰが第１ＡＰとなる。図８（ａ）の例では、各データの入力は未だ無い。
いま、１１月７日の９時に自宅から港区田町（田町駅）にあるＡ社（ランドマーク登録有り）を１時間ほど訪問するスケジュールデータをカレンダーＡＰに入力したとする。ユーザは、アプリ連携の意思があることを表す特定記号として、鉤括弧でＡ社をくくるように入力する。そうすると、中継サーバ１０は、第２ＡＰの例となる経路案内ＡＰに、Ａ社を目的地とする経路探索を自動的に行わせ、その実行結果をカレンダーＡＰおよび第３ＡＰとなる旅費精算ＡＰが実行する処理に反映させる。図８（ｂ）は、反映された各ＡＰの実行結果例を示す。つまり、９時の約１時間前に自宅からＡ社までの移動経路と、１０時にＡ社を出たときの勤務先への帰社経路とがカレンダーＡＰのスケジュール内容に自動転記される。また、旅費精算ＡＰの所定のシートに旅費精算の内訳（日付、経路、運賃）を自動転記させる。

その後、Ａ社への訪問により、突然、１１時に新宿のＢ社（ランドマーク登録有り）へ１時間訪問することになったとする。この場合、ユーザは、カレンダーＡＰの１１時のスケジュールにＢ社と鉤括弧でくくって入力する。中継サーバ１０は、カレンダーＡＰへの修正データが入力されたことを認識し、経路案内ＡＰにＡ社からＢ社への移動経路を再探索させる。その結果、カレンダーＡＰのスケジュール内容は、１１時の時点で、図８（ｃ）のように帰社経路が移動経路へ変更され、Ｂ社から出た後に帰社経路が自動転記される。また、旅費精算ＡＰによるシートが自宅〜田町〜新宿〜会社のように修正される。

他方、Ｂ社から訪問時間を１３時に変更してほしい旨の連絡を受けたユーザは、カレンダーＡＰの１１時のＢ社訪問のスケジュール内容を１３時に修正したとする。中継サーバ１０は、カレンダーＡＰへの再修正データが入力されたことを認識し、経路案内ＡＰにＡ社から１３時にＢ社への移動経路を再探索させる。このとき、中継サーバ１０は、１３時に新宿では、一旦勤務先に戻るのが最適経路と判定し、Ａ社からは勤務先への帰社経路、Ｂ社へは勤務先からの往復の経路をカレンダーＡＰのスケジュール内容に自動転記する。同様に、旅費精算ＡＰのシートを、自宅〜田町〜会社、会社〜新宿（往復）の内容に変更させる。

＜具体例２＞
図９は、図８に示した例の変形として、旅費精算ＡＰのシートに先に旅費の実績データを入力したことによって移動のスケジュールを自動転記する場合の例を示す。この場合の第１ＡＰは旅費精算ＡＰ、第２ＡＰは経路案内ＡＰ、第３ＡＰはカレンダーＡＰとなる。図９（ａ）は、未だ実績データの入力がない状態を示す。図９（ｂ）は、８時に自宅を出発してＡ社への旅費の実績データを入力した場合の例である。このとき、カレンダーＡＰの８時からのスケジュール内容にＡ社までの移動経路が自動転記される。また、Ａ社から勤務先に戻ったときの実績データを入力すると、カレンダーＡＰのスケジュール内容には、１０時から移動経路が自動転記される。なお、この後にカレンダーＡＰの９時のスケジュールに鉤括弧でくくったＡ社を入力しても、旅費精算ＡＰの実行結果は反映済であるため、カレンダーＡＰのスケジュール内容への移動経路の自動転記は行われない。

＜具体例３＞
東京の自宅から札幌への出張の場合の例を図１０に示す。連携させるＡＰは、カレンダーＡＰ、経路案内ＡＰ、旅費精算ＡＰ、予約サーバ４３を通じてアクセス可能なチケット予約ＡＰと宿泊予約ＡＰである。この例では、第１ＡＰがカレンダーＡＰ、第２ＡＰが経路案内ＡＰ、第３ＡＰが旅費精算ＡＰ、第４ＡＰがチケット予約ＡＰおよび宿泊予約ＡＰとなる。図１０（ａ）はデータの入力がない状態の各ＡＰの実行状態を示す。カレンダーＡＰの１１月７日、札幌のＣ社（ランドマーク登録有り）へ９時から１時間だけ訪問するスケジュールデータを入力したとする。この場合、経路案内ＡＰの探索によれば、Ｃ社へ９時前に到着する航空機がない。そのため、中継サーバ１０は前泊が最適のスケジュールと判断する。そして、図１０（ｂ）に示されるように、旅費精算ＡＰのシートに前日移動分と当日移動分の明細行を自動転記させる。また、チケット予約ＡＰに航空券を仮予約させ、宿泊予約ＡＰに宿泊先を仮予約させる（仮予約の実行条件が登録されている場合）。すなわち、カレンダーＡＰの１１月７日のスケジュールには、９時前の移動経路と１０時以降の帰社経路とが自動転記される。また、宿泊予約ＡＰによる前日（１１月６日）の仮予約の状況も表示される。

＜具体例４＞
旅費精算ＡＰで１１月７日に、沖縄のＤ社へ１７時に訪問した後、Ｃホテルへ宿泊し、翌日東京に戻るときのアプリ連携の例を図１１に示す。連携させるＡＰは、カレンダーＡＰ、経路案内ＡＰ、旅費精算ＡＰ、チケット予約ＡＰ、宿泊予約ＡＰである。この例では、第１ＡＰが旅費精算ＡＰ、第２ＡＰが経路案内ＡＰ、第３ＡＰがカレンダーＡＰ、第４ＡＰがチケット予約ＡＰおよび宿泊予約ＡＰとなる。

図１１（ａ）は、旅費精算ＡＰにおいて、鉤括弧でくくった旅費精算の実績データが入力されている。すなわち、宿泊するホテルがＣホテルで、宿泊費が１００００円で、１７時前にはＤ社に到着しなければならないことが事前に判明しているので、その内容を表すデータがユーザ端末３０から旅費精算ＡＰへ入力されている。東京の自宅から１７時前に沖縄のＤ社を訪問し、Ｃホテルへ宿泊した後、翌日、東京の勤務先又は自宅に戻るためには、連携する経路案内ＡＰを起動することになる。経路案内ＡＰの実行結果は、自宅〜羽田空港〜沖縄までの空路〜Ｄ社〜Ｃホテル〜那覇空港〜羽田空港の経路が探索される。

また、Ｃホテルへの宿泊が確定した時点で、勤務先へ請求する日当を請求することができるという実行条件が旅費精算ＡＰには付加されている。そのため、旅費精算ＡＰの実行結果として、日当を含む、図１１（ｂ）の網掛け部分が旅費精算ＡＰの実行結果として自動追記される。また、カレンダーＡＰに、自宅からの１１月７日のスケジュールが自動転記される。宿泊予約ＡＰについてもＣホテルが自動転記される。ユーザ端末３０の表示部を通じて表示されたこれらの実行結果について了承した場合、ユーザの１１月７日のＤ社訪問に関わる各ＡＰの実行結果が確定する。

＜具体例５＞
具体例４により沖縄のＤ社訪問に関わる各ＡＰの実行結果が確定した後、同じく沖縄のＥ社に１４時に訪問するスケジュールをカレンダーＡＰへ追加入力した場合の例を説明する。この場合、カレンダーＡＰが第１ＡＰ、旅費精算ＡＰが第３ＡＰとなる。それ以外は、具体例４と同じである。本例では、修正データが入力された場合の各ＡＰの連携処理の例となる。図１２（ａ）はＥ社訪問の直前までに確定してい各ＡＰの実行結果であり、図１１（ｂ）と同じである。しかし、Ｅ社への訪問時間の予定は、直前に確定したスケジュールによれば、Ｅ社へ訪問する時間帯は飛行機で移動している。そのため、新たに入力されたデータに基づくカレンダーＡＰの実行結果は図１２（ｂ）のようになり、中継サーバ１０は、これらの一連のスケジュールは、変更前後で両立できないと判断する。

そこで、中継サーバ１０は、各ＡＰへのそれまでの実行結果を破棄させる。そして、カレンダーＡＰに、１４時のＥ社訪問を追加入力した場合について、まず、経路案内ＡＰに経路探索を実行させる。その結果、Ｅ社（ランドマーク登録有り）を１４時に訪問する場合、東京からは、８時代の飛行機に乗らなければならず、そのためには、自宅を６時４５分に出て羽田空港に向かい、那覇空港行の１０３便、すなわち８時の時間帯の飛行機に乗らなければならない。そのため、中継サーバ１０は、図１３に示すように、カレンダーＡＰのスケジュールを、新たな経路案内ＡＰの実行結果に基づいて再編成させるようにした。旅費精算ＡＰおよび宿泊予約ＡＰの実行結果については変更がない。この内容について承認した場合、修正データの入力に基づくユーザのスケジュールが確定する。

＜具体例６＞
具体例５の各ＡＰの実行結果に基づき、ユーザが、具体例５のスケジュールを破棄し、沖縄のＥ社だけを訪問するスケジュールを新たに入力する例について説明する。Ｃホテルの予約は、既に決まっており、それ故に、宿泊予約ＡＰにＣホテルを予約することについて、ユーザが鉤括弧でくくって連携の意図を表したとする。つまり、本例ではＣホテルへの宿泊予約を先行させる。連携するＡＰは、具体例５と同じであるが、本例の場合、宿泊予約ＡＰが第１ＡＰ、経路案内ＡＰが第２ＡＰ、カレンダーＡＰと旅費精算ＡＰの一方が第３ＡＰ、他方が第４ＡＰとなる。

図１４（ａ）はどのＡＰもデータが入力されていない状態である。同（ｂ）は宿泊予約ＡＰにＣホテルへの宿泊予定だけを入力している。この時点では、経路案内ＡＰは、入力時点を出発時刻とするため、東京にいるユーザのカレンダーＡＰのスケジュールは、終日出張と自動転記される。その後、カレンダーＡＰに、１１時に沖縄のＥ社への訪問を入力した場合、これにより経路案内ＡＰが実行され、その実行結果が反映されたカレンダーＡＰおよび旅費精算ＡＰの実行結果が図１４（ｃ）のようにユーザ端末３０の表示部に表示される。すなわち、カレンダーＡＰの画面には、６時４５分に自宅から羽田空港に向かう移動経路、羽田空港から那覇空港に向かう空路、那覇空港からＥ社に向かう移動経路が自動転記される。また、旅費精算ＡＰの画面には、日当をはじめとする沖縄のＥ社と東京との間の交通費が自動転記される。

＜具体例７＞
次に、ユーザＤＢ１１に登録されているＡＰに入力されるデータが、名詞のほかに動詞ないし形容詞を含む文字列で、登録されているＡＰのいくつかが、ユーザ以外の他者に向けて情報を発信する発信型ＡＰであり、解析部１２４は、メールＡＰを通じて入力された文字列の意味合いを解釈するとともに、当該文字列を発信型ＡＰに向けた文字列に編集するように構成される場合の例を説明する。発信型ＡＰとなるのは、メールＡＰ、ＳＮＳ ＡＰである。

図１５は、このような場合のアプリ連携の具体例を示すものである。例えば、メールサーバを通じてユーザが通常使用しているメールＡＰから、「急用のため、明日欠勤します」、「なお、面会予定有」というメールが中継サーバ１０に入力されたとする。つまり、メールＡＰが第１ＡＰとなる。実際、そのユーザのスケジュールには、大阪の顧客との商談が予定されており、それ故に、新幹線および宿泊の予約が決まっているものとする。

中継サーバ１０は、メールＡＰを通じて入力された文字列の意味合いを解釈するとともに、当該文字列をそれぞれ図１５に例示されるメールＡＰ、ＳＮＳ ＡＰ発信型ＡＰに向けた文字列に編集する。そして、メールサーバ４１に連絡し、明日面会予定の取引先にキャンセルの旨の電子メールを自動送信させるとともに、送信した電子メールをユーザ端末３０へもｃ．ｃ．で送信させる。また、ＳＮＳサーバ４２へ連絡し、第２ＡＰとなるＳＮＳ ＡＰを通じて、上司に、明日欠勤の旨の自動メッセージを送信させる。また、送信したメッセージをユーザ端末３０へｃ．ｃ．で送信させる。さらに、第３ＡＰとなるそのユーザのカレンダーＡＰに、明日の商談予定を削除する内容のデータを送信する。さらに、予約サーバ４３へ連絡し、第４ＡＰとなるチケット予約ＡＰおよび宿泊予約ＡＰを通じて新幹線、宿泊の予約をキャンセルさせる。上記一連の連携の処理は、最初に電子メールで連絡を受けたとき以外は、ユーザからの実行指示を待つことなく実行される。

以上のとおり、本実施形態のアプリ連携システム１では、中継サーバ１０が、ユーザが任意に選択し、登録した複数のＡＰの実行を中継する。すなわち、いずれかの第１ＡＰを通じて入力されたデータに特定記号が含まれているときは、当該データを入力データとする第２ＡＰに所用の情報処理を実行させるとともに、該第２ＡＰによる実行結果を受領し、受領した実行結果を第２ＡＰ以外の他の登録されたＡＰが実行する処理に反映させる。そのため、ＡＰ同士をダイレクトに連携させる必要がないので、ＡＰの増減に柔軟に対応することができる。
ユーザにとっては、通常使用している任意のＡＰ同士を連携させることができるので、使用感を高めることが期待される。システム運用者側も、連携させるＡＰに増減が生じても、ユーザＤＢ１１の登録内容を変更するだけで足りる。そのため、ユーザが使用するＡＰが増えても連携のための開発作業が不要となり、ユーザの使用感を高めたアプリ連携を容易に実現することができる。

Claims (8)

1. ユーザが操作するユーザ端末と、連携の対象として前記ユーザにより任意に選択されそれぞれ入力されたデータに基づいて所定の情報処理を実行する複数のＡＰの実行手段とが接続される装置であって、
   前記複数のＡＰ、各ＡＰの実行手段へのアクセスを可能にするユーザ情報、および、連携させるデータを特定するための特定記号とを登録する登録手段と、
   前記ユーザ端末から、登録された前記複数のＡＰのうち第１ＡＰに入力される第１データを取得する取得手段と、
   取得した前記第１データを所定基準に従って解析することにより前記第１データに前記特定記号が含まれているかどうかを判別する解析手段と、
   前記第１データに前記特定記号が含まれている場合、前記ユーザ端末からの指示を待つことなく、前記ユーザ情報を用いて前記第１ＡＰと異なる第２ＡＰの実行手段にアクセスして前記特定記号により特定される第２データを前記第２ＡＰの実行手段へ入力するとともに前記第２ＡＰの実行結果である第３データを取得し、さらに、前記ユーザ情報を用いて前記第１ＡＰおよび前記第２ＡＰと異なる第３ＡＰの実行手段へアクセスして前記第３データを前記第３ＡＰへ入力するとともに前記第３ＡＰの実行結果である第４データを取得する制御手段と、を備えたことを特徴とする情報処理装置。
2. 前記制御手段は、前記ユーザ端末からの指示を待つことなく、前記ユーザ情報を用いて前記第１から第３ＡＰと異なる第４ＡＰの実行手段へアクセスして前記第４データを前記第４ＡＰの実行手段へ入力するとともに前記第４ＡＰの実行結果である第５データを取得することを特徴とする、請求項１に記載の情報処理装置。
3. 前記第１ＡＰから前記第３ＡＰは、それぞれ前記ユーザが移動する日時および場所に関するデータに関する情報処理を行うことを特徴とする、
   請求項１又は２に記載の情報処理装置。
4. 前記第１ＡＰは前記ユーザが移動した際の旅費の実績データを記録する旅費精算ＡＰであり、
   前記第２ＡＰは前記実績データに基づく移動経路を案内する経路案内ＡＰであり、
   前記第３ＡＰは前記移動経路に基づく前記ユーザのスケジュールデータを自動的に記録するカレンダーＡＰであることを特徴とする、
   請求項１又は２に記載の情報処理装置。
5. 前記第１ＡＰは前記ユーザが使用している電子メールを受信するメールＡＰであり、
   前記第２ＡＰは前記電子メールの内容を発信させるＳＮＳ ＡＰであり、
   前記第３ＡＰは前記ユーザのスケジュールデータを記録するカレンダーＡＰであることを特徴とする、
   請求項１又は２に記載の情報処理装置。
6. 前記第１ＡＰは前記ユーザのスケジュールデータを記録するカレンダーＡＰであり、
   前記第２ＡＰは前記スケジュールデータに基づいて前記ユーザが移動する経路を案内する経路案内ＡＰであり、
   前記第３ＡＰは前記経路を移動した際の旅費を精算する旅費精算ＡＰであり、
   前記第４ＡＰは前記経路において前記ユーザが利用する宿泊施設または交通機関の予約を行う予約ＡＰであることを特徴とする、
   請求項２に記載の情報処理装置。
7. 前記第１ＡＰは前記ユーザが宿泊する予定の宿泊施設の予約を行う予約ＡＰであり、
   前記第２ＡＰは前記ユーザが前記宿泊施設まで移動する経路を案内する経路案内ＡＰであり、
   前記第３ＡＰと前記第４ＡＰの一方は前記経路を移動した際の旅費を精算する旅費精算ＡＰ、前記第３ＡＰと前記第４ＡＰの他方は前記ユーザのスケジュールデータを記録するカレンダーＡＰであることを特徴とする、
   請求項２に記載の情報処理装置。
8. コンピュータを請求項１から７のいずれか一項の情報処理装置として動作させるためのコンピュータプログラム。