JP2006190008A - データ連携装置及びデータ連携方法 - Google Patents

Abstract

【課題】インターネット上に多数存在するＷｅｂアプリケーション等を有機的に連携させることで、様々なサービスを生み出す連携場を提供すること。
【解決手段】複数アプリケーション間におけるデータを連携するデータ連携装置において、連携対象のアプリケーションが送信もしくは受信可能なデータに付与された少なくとも１つのデータ形式の名称を、優先度順位順に保持する仕様管理手段３１ｃと、１つのアプリケーション上の１つ以上のデータを他のアプリケーションに連携させる際に、前記データに付与された前記データ形式の名称が、前記他のアプリケーションのデータ形式の名称と一致する項目に、データを転送する連携手段３３とを備えた。
【選択図】 図１

Description

本発明は、複数のアプリケーション間で、いわゆるデータのコピー＆ペーストを行うデータ連携の技術に関する。
具体的には、本発明は、サービスの利用者が、自ら様々なアプリケーションを連携し、所望のサービスをその場で合成するとともに、その合成結果を複数人で共有することにより、情報の組み合わせに関するノウハウを共有することを可能とした技術に関する。

従来、データを連携させる場合、連携対象となるデータに関するアプリケーションを事前に起動させておき、そのアプリケーションに対して、利用者自身がコピー部分、ペースト部分という連携対象を明示的に指定する必要があった。このため、連携対象のアプリケーションを利用者自身が予め知っている必要があった。しかし、このような方法は、Ｗｉｎｄｏｗｓ（登録商標）等のＯＳ内で少数のアプリケーションを連携させるには有効ではあるが、例えば、Ｗｅｂアプリケーションのようにインターネット上に大量に、分散して存在するアプリケーションを連携させる方法としては相応しくない。

また、現状では、Ｗｅｂ上で、アプリケーションを連携させる試みとしてＷｅｂ Ｓｅｒｖｉｃｅｓ等が知られている、しかし、これらの技術では、予め提供する機能・交換するデータ形式に関し、完全な合意（一致）が前提である。したがって、多数の人が存在するネット上で完全なデータの標準化が困難であるためか、その適用は本技術の提案元のべンダの技術先行によるものに留まっている。

以下、現在使用されているデータ連携方式について、いくつか説明する。まず、第１番目の技術として、ＧＵＩ系のＯＳにおけるデータ連携に関して論ずる。

Ｗｉｎｄｏｗｓ（登録商標）、Ｘ、Ｍａｃｉｎｔｏｓｈ等ＧＵＩ系のＯＳにおけるクリップボードは、データ連携すべきデータを複数のデータ形式によりデータバッファ上に登録することで、各アプリケーションのデータ形式を意識することなく、種々のアプリケーション間におけるデータ連携を可能とするものである（特許文献１参照：以下、「従来技術１」と称する）。この技術において、例えば、あるワードプロセッサのアプリケーションにおいて書式付のテキスト形式（リッチ・テキスト形式）を別の表計算アプリケーション上で利用する場合に、単なるテキスト形式で受け取りたいという場合などに利用される方式である。ここで、コピー操作が行われたアプリケーションは、提供可能なデータ形式の一覧をクリップボードと呼ばれる領域（バッファ）に登録し、ペースト（貼り付け）操作が行われたアプリケーションはその中から受信可能な形式で受信する。

上記のように、従来技術１は、従来、アプリケーション毎に固有の連携用バッファを持つ必要があるということの解決を試みるものであり、複数のコピー＆ペーストをバッファ内にスタック構造を持たせ、複数の情報を登録できるようにしたものである。しかし、この方式には、以下のような問題があった。

（１）コピー操作により指定された単一のデータがデータ連携の対象であり、本方式では複数のデータをまとめて連携させることができない。従来技術１では、バッファ領域内に複数の領域を備え、スタック形式で情報の蓄積をすることで、複数回のコピー・ペーストという操作を、複数回のコピー操作、複数回のペースト操作という操作に分解することができるが、それにしても連携対象が複数箇所存在する場合は、コピー対象、ペースト対象を逐次的に指定する必要がある。
例えば、Ｗｅｂアプリケーションで商品発注に先立ち、見積を取得した場合を考えると、一般に見積には「商品名」、「数量」、「見積金額」等多数のデータ項目が表示されているが、それらを単にまとめた１つの文字列としてではなく別のアプリケーション（例えば社内の発注処理アプリケーション）の特定の入力フィールドと連携させる場合には、複数回のコピー、ペースト操作が要求される。

（２）コピー側のアプリケーションが、提供可能なデータ形式をバッファ内に複数登録する仕組みを有するので、異なるフォーマットで表現されたデータの連携は可能であるが、アプリケーション間において、複数のフォーマットで連携可能な場合に、最適なものを選択することが出来ない。利用者は連携させるアプリケーションを予め起動しておき、コピー操作、ペースト操作により、連携部分を指定する必要がある。限定された用途においては有用であるが、連携可能なアプリケーションを検索する仕組みは有さない。

第２番目の技術として、ＷＳＤＬ等のインタプェース定義言語に係る技術が知られている（非特許文献１参照：以下、「従来技術２」と称する）。
インターフェース定義言語は、Ｗｅｂ ＳｅｒｖｉｃｅｓのＷＳＤＬや、Ｊａｖａ（登録商標）のＩｎｔｅｒｆａｃｅに代表されるアプリケーションの仕様記述言語である。仕様定義には、アプリケーションが提供する機能ならびに、各機能が入出力するデータの形式が定義される。Ｗｅｂ Ｓｅｒｖｉｃｅｓにおいては、仕様を実装したネットワーク上に分散して存在するアプリケーションの所在をＵＤＤＩと呼ばれるリポジトリを用いて検索する仕組みを有する。しかし、本技術方式も以下のような問題を有している。

（１）ＷＳＤＬは、アプリケーションの入出力仕様を記述する言語であり、複数の機能（関数）、並びに機能毎に入出力されるデータの構造が定義されている。一般にＷＳＤＬに基づくアプリケーションは、クライアントサーバ型アプリケーションであり、連携対象のアプリケーションは常に同一のＷＳＤＬに基づき開発されることが前提になる。このため、連携対象のアプリケーションは提供する機能、並びに入出力のデータの形式・名称は完全に一致する必要がある。そのため、例えば、ＡというアプリケーションのＸという機能と、ＢというアプリケーションのＹという機能を接続するという使い方はそもそもできず、同一名称のＸという機能同士を接続することのみが可能である。そのため、このようなインターフェース仕様に基づき連携するアプリケーションは事前にその仕様に関し、完全に合意してから開発を行う必要があり、完成したアプリケーション同士を接続し連携させるという用途には向かない。
そのため、例えば「見積」という仕様に基づくアプリケーションから得たデータを、「発注」という仕様に基づくアプリケーションと連携させる場合には、その連携方法を個別にプログラムする必要がある。

（２）本方式では、仕様記述が完全に一致するアプリケーションのみが連携可能であるため、データ構造が異なると、連携が出来ない。なお、仕様が完全に一致するアプリケーションの実装の所在地を検索することは可能ではあるが、仕様中の、機能Ａと連携するアプリケーションの検索という検索の方法は実現できず、提供する機能の組が完全に一致しているもののみ検索可能である。

（３）本技術は、他の従来技術と異なり、画面を持たないアプリケーション、つまりＡＰＩ型の提供形態であり、通常、利用するには、クライアントプログラムを作成する必要がある。そのため、アプリケーション利用者自身が組み合わせるというよりは、むしろプログラムの設計者が事前に連携対象のプログラムを決めている。

第３番目の従来技術として、イベント・リスナ方式が知られており、このイベント・リスナ方式は、アプリケーションが出カするデータ形式と、入力されるデータ形式を予めイベントと呼ばれるデータ構造を用いて宣言しておき、複数アプリケーション間の入力・出力をプログラムによりつなぐプログラムの設計方式である（非特許文献２から非特許文献５参照：以下、「従来技術３」と称する）。例えば、Ｊａｖａ（登録商標）におけるＳｗｉｎｇ、ＪＳＦ（Ｊａｖａ（登録商標） Ｓｅｒｖｅｒ Ｆａｃｅｓ）等が本方式を採用している。
しかし、本従来技術は、以下の問題を有している。

（１）イベント出力を行う１つのアプリケーションに対して、複数のリスナを登録することが可能であるが、イベントとリスナの関係は事前に登録しておく必要があるため、連携可能なアプリケーションの組み合わせが開発時に決定したものに限定される。

（２）イベントとリスナがやりとりするデータの形式は一致している必要がある。すなわち、イベントとリスナの関係は事前に登録しておく必要があるため、連携可能なアプリケーションの組み合わせは開発時に決定したものに限定される。

第４番目の従来技術として、Ｍｙ Ｐｏｒｔａｌ技術が知られており、このＭｙ Ｐｏｒｔａｌ技術は、ポータルサイト等で提供され、株価、ニュース等利用者の興味のあるコンテンツを選択し、１つのＷｅｂページとして配置できる技術である（非特許文献６及び非特許文献７参照：以下、「従来技術４」と称する）。本技術では、複数のＷｅｂアプリケーションを１つのページ内に配置し、情報の一覧性を高める技術である。しかし、本技術は、以下の問題を有している。

（１）利用可能な部品の制限
予め用意された範囲内の部品を利用者の好みの配置に並べることができるが、通常ポータルサイト内で準備している部品のみが利用可能である。

（２）画面を並べることは可能であるが、基本的にデータの連携はできない。
データの連携ができないため、並べるアプリケーションは単に（ＨＴＭＬ）のフレームを用いて表示することで実現できる機能と大差がない。本技術の中には連携可能なものも存在するが、それはポータルサイトの提供者が予め連携するプログラムを組み込んでいるからであり、その連携の対象を利用者自身が選択することはできない。

（３）組み合わせたアプリケーションは通常、自分専用のものであり、他人が利用することはできない。
そのため、本技術は、アプリケーションを有機的に組み合わせて所望のサービスを利用者自身が構築するという用途には利用できず、単に情報の閲覧の一覧性を高めるということに留まっている。

第５番目の従来技術として、Ｉｎｔｅｌｌｉｇｅｎｔ Ｐａｄ方式が知られており、このＩｎｔｅｌｌｉｇｅｎｔ Ｐａｄは、ネットワーク上に分散配置されたアプリケーションを利用者の端末上で合成し、利用者が明示的に連携対象のデータ同士を接続することにより、データの連携を可能とする技術である（非特許文献８参照：以下、「従来技術５」と称する）。しかし、本技術は、以下の問題を有する。

（１）利用者は、ネットワーク上に分散配置されたアプリケーションを利用者の端末上で合成し、明示的に連携対象のデータ同士を接続することにより、データの連携が可能である。連携可能なアプリケーションは、利用者が予め把握していることが前提であり、連携可能なアプリケーションを検索する仕組みは持たない。そのため、連携可能な部品の存在を知る手段がない。また、見つけたとしても、アプリケーションの接続可能な部分を利用者自身が判定し、接続箇所を個別に指定する必要がある。
特開平６−１３１１５３号公報 http://www.w3c.org/TR/wsdl http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSFIntro6.html#wp115516 http://java.sun.com/developer/onlineTraining/Beans/beans02/page3.html http://java.sun.com/products/javabeans/docs/getListeners.html http://my.yahoo.co.jp/?myHome http://my.livedoor.com/ http://www.pads.or.jp/_taiken/00.html

本発明は、上記の課題を解決するためになされたものであって、インターネット上に多数存在するＷｅｂアプリケーション等を有機的に連携させることで、様々なサービスを生み出す連携場を提供することを目的とする。

本発明は、具体的には、下記の課題を解決することを目的とする。

（１）連携するアプリケーションを利用者自身が選択できること。
（２）連携方法に関して、利用者は個別の連携の指定を最小限に抑え、複数のデータをまとめて連携可能であること。また、１つのデータを複数のアプリケーションに連携することが可能であること。
（３）Ｗｅｂアプリケーション等が様々な人によって作られており、データの形式が不統一である事情を鑑み、異なるフォーマットで表現されたデータを、連携できること。
（４）連携対象のアプリケーションを検索可能であること。
（５）組み合わせたアプリケーションを、自身の所属する特定のコミュニティや、不特定多数の第三者間で共有できること。

本発明では、アプリケーションにおける予め送信または受信可能なデータ形式を仕様管理手段に登録する。利用者は、最初に或るアプリケーションを利用して、連携をさせたい場合に、そのアプリケーションと連携可能なデータ形式を有するアプリケーションを検索手段により検索する。検索手段は、仕様管理手段を調べ、利用者が使用しているアプリケーションが送信するデータ形式を、受信可能なデータ形式として持つアプリケーションを検索し、さらに利用者が使用しているアプリケーションが受信可能なデータ形式を、送信可能なデータ形式として持つアプリケーションを検索する。

利用者は、連携可能な複数のアプリケーションの中から所望のものを１つ選択する。これにより、選択された該アプリケーションは、アプリケーション管理手段に加えられて、連携対象となる。次に、利用者の明示的な連携要求、もしくは、上記アプリケーション管理手段に加えられた段階で、連携手段が起動され、アプリケーション間で、仕様管理手段で定義されているアプリケーションの送受信可能なデータ形式の一致するものを選択し、その間でデータを連携させる。

なお、利用者は組み合わせたアプリケーションが第三者にとっても有用なものであると判断した場合等に、登録処理を行う。この登録処理により、アプリケーション管理手段内に保持している連携対象のアプリケーション群が共有領域に移される。

上記より、まず、従来技術１では、１つのアプリケーション内に複数のデータが提示され、それらを別のアプリケーションと連携させたいとき、複数回のコピー、ペースト操作を行う必要があるが、本発明では一回の操作でそれが可能である。また、連携対象のアプリケーションを利用者自身が知っていなくても、連携可能なアプリケーションを検索することが可能である。

次に、従来技術２は、連携アプリケーション間の仕様が完全に一致している必要があるため、データ形式が異なると、連携できない。また、仕様記述されている複数機能の内、ある機能のみを連携させるという使い方ができない。また、従来技術３は、連携アプリケーション間の仕様が完全に一致している必要がある。また、従来技術３は設計法であり、予め連携するアプリケーションを開発時に決定し、その間の連携方法を定義する必要があり、利用者が連携するアプリケーションを選ぶという使い方ができない。
一方、本発明では、予め登録されたアプリケーションの送受信可能なデータ形式をキーとして、利用者自身が連携対象のアプリケーションを検索・選択できる検索手段や、アプリケーション管理手段を備えており、連携するアプリケーションを事前に固定しておく必要がない。アプリケーションが連携データに対して複数の形式を登録されており、連携対象のアプリケーション間で、それらの間で一致するデータ形式に関して自動的に連携するため、従来技術３のようにイベントとリスナの対応を事前に個別にプログラムする必要はない。
また、本発明では、利用しているアプリケーションが送信、または受信可能なデータ形式をキーとして、連携可能なアプリケーションを検索する手段を備えているため、利用者自身が連携対象を予め知っている必要はない。

従来技術４では、画面を単に並べているだけだが、本発明ではデータの授受が可能である。また、従来技術４では、複数のアプリケーションを単に画面上、利用者の膚好に従った配置にすることは可能であるが、アプリケーション間のデータの連携はできない。一方、本発明は、単に画面を有するアプリケーションを並べるだけに留まらず、アプリケーションが送受信可能なデータを容易に受け渡すことが可能である。同時に連携対象を検索する仕組みを有する。

従来技術５は利用者が容易にアプリケーションを組み合わせることができ、かつ、連携可能なデータを明示的に指定することで、連携することができるが、連携可能なデータを検索することができず、また、連携結果を不特定多数の間で共有することができない。
一方、本発明では利用しているアプリケーションが送信、または受信可能なデータ形式をキーとして、連携可能なアプリケーションを検索する手段を備えているため、利用者自身が連携対象を予め知っている必要はない。また、検索により発見したアプリケーションは、連携対象となるアプリケーション管理手段に加えられ、その連携対象となっているアプリケーション間では連携可能なデータが個別に連携対象を指定せずとも、連携可能であるため、個別に連携方法を指定する必要がない。

本発明によれば、以下のような効果が得られる。

（１）アプリケーションは、送信、または、受信可能なデータ形式を希望の順に複数の形式で登録可能であり、アプリケーション間を連携する際に、その形式が１つでも一致すれば連携可能である。これにより、様々なフォーマットで表現された、データ形式を持つアプリケーションを連携することが可能となる。

（２）連携対象上にあるアプリケーション間で連携可能なデータを利用者の明示的な操作なく、自動的に連携可能である。もちろん、連携を明示的に指定することも、連携対象を個別に指定することも可能である。これにより、利用者にとっての、連携の手間を大幅に軽減している。

（３）サービス利用者は、アプリケーションが送信可能なデータ形式（受信可能なデータ形式）を基にして、該データ形式を受信可能な（送信可能な）アプリケーションを検索する検索手段を有し、検索結果の中から所望のアプリケーションを選択することにより、該アプリケーション間でデータ連携をさせることができる。さらにアプリケーションが連携可能な複数のデータ形式に優先順位が付いているため、より適切に連携できるアプリケーションを優先的に検索可能である。したがって、従来のように、連携対象のアプリケーションを事前に利用者が完全に知っている必要はなくなる。

（４）ある利用者が検索・選択・連携させたアプリケーションの組み合わせを、第三者にも利用可能であるよう、登録する手段を備えていることにより、その利用者の（選択・組み合わせの）ノウハウを別の利用者が利用することができる。さらにそれらが場（連携場）として提供されるため、ノウハウを蓄積していくことが可能である。

（５）本連携装置をポータルサイト運営者等の事業者が運営し、アプリケーションを該運営者のパートナ企業が運営する形態で運用することで、利用者にとっては容易に目的のアプリケーションを作成できたり、他人の作った組み合わせノウハウが得られるというメリットがあると共に、アプリケーションを作成するパートナ企業では、今まで様々な機能を１社で作りこむ必要があったのが、自社のコアコンピタンスである事業領域に関するアプリケーションのみを作るだけでよく開発費が抑えられると共に、他社のアプリケーションと組み合わせられること自発的な宣伝効果も得られる。ポータルサイト運営者は、パートナ企業から参加料・連携料等を微収すること、また場合によっては利用者からも会費を微収することで、３者両得のビジネスモデルも構築可能である。
この登録機構により、例えば、ゴルフ場の予約アプリケーションで予約を行った者は、その住所を地図アプリケーションと連携させるといった、ノウハウに関する組み合わせが連携場に蓄積することが可能となる。

図面を参照して本発明の実施の形態を説明する。図１は、本発明の一実施形態に係るデータ連携装置の概略構成と該データ連携装置が適用されるシステムの構成例を示す図である。

図１に示すように、本発明の実施形態に係るデータ連携装置３０は、アプリケーション管理手段３１と、検索手段３２と、連携手段３３と、共有手段３４とを備えている。また、データ連携装置３０は、例えばネットワークを介して、利用者端末１０と通信可能に接続されている。なお、以下の説明においては、利用者端末１０では、ブラウザによりデータ連携装置３０のコンテンツをダウンロードし、そのコンテンツにより検索を行うものとするが、本発明は、これに限らず、利用者端末１０で所定のアプリケーションを起動して、当該アプリケーションによる検索に対する所定の項目におけるデータ連携を行うようにしても良い。

アプリケーション管理手段３１は、図２に示すように、実装されたアプリケーション４０のアプリケーションＩＤとアプリケーション名とを関連付けて登録するアプリケーション管理テーブル３１ａと、プロセス管理テーブル３１ｂと、仕様管理テーブル３１ｃ（本明細書において、「仕様管理手段」と称する場合もある）とを備えている。アプリケーション管理テーブル３１ａは、例えば、図２に示す例では、アプリケーションＩＤ「０００１」に対するアプリケーション名「ゴルフ予約アプリケーション」や、アプリケーションＩＤ「０００２」に対するアプリケーション名「地図アプリケーション」及びアプリケーションＩＤ「０００３」に対するアプリケーション名「スケジュール管理アプリケーション」のように、１対１でアプリケーションＩＤとアプリケーション名が関連付けられている。本テーブルは、Ｗｉｎｄｏｗｓ（登録商標）で言うと、レジストリに相当する部分であり、本システムに登録されているアプリケーションの一覧、並びに所在を確認するテーブルである。

また、プロセス管理テーブル３１ｂは、アプリケーションの実行状態を管理するテーブルであり、アプリケーション起動時に利用者に関連付けられて、作業領域が確保される。プロセス管理テーブル３１ｂへのデータの登録例を図３に示す。プロセス管理テーブル３１ｂには、「プロセスＩＤ」、「アプリケーションＩＤ」、「プロセス群ＩＤ」、「利用者ＩＤ」及び「プロセス管理情報」などが登録される。具体的な参照等については、後述する。なお、アプリケーション４０は、所定の動作を行うプログラムであり、アプリケーションは利用者からの入力の受け付けや結果を提示するユーザインターフェースを有している。各アプリケーションは通常複数の画面を有し、各画面では利用者からの要求を受け付ける入力フォームや処理結果等を提示するラベル、テキストボックス等の出力フォーム等を有する。また、アプリケーションは開発時に各画面毎に入力されるデータの形式をメタ情報（アプリケーションの画面毎の入出力仕様）として与えられ、アプリケーションのインストール時に仕様管理テーブル３１ｃに登録（或いは、保持）される。

アプリケーションは、データ連携装置３０を同じ端末上にインストールされても良いし、ＷＳＲＰ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｒｅｍｏｔｅ Ｐｏｒｔａｌ）のように、遠隔手続きを介して、遠隔に存在してもよく、データ連携装置３０から利用可能であれば、どのような部分に実装されていても良い。

また、プロセス管理テーブル３１ｂから参照される連携情報テーブルの例を図４に示す。

図４に示す例では、プロセス群ＩＤ「１」に対して、連携ＩＤが、例えば、シーケンシャルに保持されており、送信プロセスＩＤ「０００１」と、受信アプリケーションＩＤ「０００１」が連携されていることを示し、送信及び受信アプリケーション画面名が「Ａ」であることを示す。

検索手段３２は、詳細は後述するように、利用者端末１０からの検索要求によって、所定のデータを検索するための手段である。

連携手段３３は、詳細は後述するように、１つのデータにより複数のデータを連携させるようにしている。

仕様管理テーブル３１ｃは、各アプリケーションの属性を管理するためのテーブルであって、各アプリケーションは自身の名前、また、アプリケーションが持つ画面の名前、送信または受信可能なデータ形式を、複数の型（形式）で、処理の容易な順に、登録する。通常、１つのアプリケーションは複数の画面を有し、各画面は入出力可能なデータ形式を複数有する。仕様管理テーブル３１ｃに登録されるデータ例を図５に示す。図５は、アプリケーションの各データ項目の仕様管理テーブル３１ｃへの登録例を示す図である。

図５には、ゴルフ場の予約アプリケーションと地図アプリケーションのデータの登録例が示されている。ゴルフ場の予約アプリケーションの場合には、予約結果確認画面には、予約日や、予約したゴルフ場の名前、その所在地などが登録される。具体的には、各項目に対して送受信の向き、型名（型式名）及び型定義が登録される。なお、型定義はアプリケーションが送信、または、受信するデータの形式（スキーマ）を表現するものであり、この登録は必ずしも必要はない。

また、図５において、項目名「予約日」に対して、「予約日」、「年月日」、「年」、「月」、「日」、「文字列」の５つの型名（型式名）が定義されているが、表の上部に定義された型名のほうが優先順位が高いことを示している。また、例えば、項目名「所在地」については、型名「所在地」、「住所」、「市町村」、「文字列」の順に優先順位が低くなる。なお、後述する検索の場合には、優先順位が高いほうから検索が実行される。

このように優先順位を考慮する理由を説明する。例えば、図５において、ゴルフ検索アプリケーションは、予約したゴルフ場の名前を表す項目（ゴルフ場名）を出力する。一方、この出力されたデータを利用する側のアプリケーションが、予めゴルフ場検索アプリケーションとの連携を想定したアプリケーションであれば、ＸＭＬで表現された「<ゴルフ場名>ゴルフ場<／ゴルフ場名>」という形式のデータを所望するかもしれないが、例えば、家計簿アプリケーションのような単にお金の支出された場所を必要とする場合、ゴルフ場名というよりは店舗名としての情報を必要すると言える。アプリケーションにとって望ましいデータ形式の順とは、一般にデータの情報量が多い順に登録する。この順序の登録は、先に述べたアプリケーションの入出力仕様としてアプリケーションの開発時に、アプリケーション開発者によって与えられる。

以上のように、連携対象のアプリケーションがある画面において、入出力する複数のデータ形式の全てが完全に一致するというのは、予め授受するデータの形式に関し合意して連携することを前提に作成したアプリケーション同士に事実上限定されるが、本発明によれば、入出力される複数のデータの形式が全て一致する必要はなく、データの一部のみの形式が一致することで、データの授受ができ、さらにその形式が異なっていてもデータに対し適切な型名（メタ情報）が付与されていれば、データの授受を行うことができる。

上記のように構成されたデータ連携装置３０の動作について説明する。

利用者は、利用者端末１０を介して、アプリケーション管理手段３１に登録された複数のアプリケーション４０の中から１つのアプリケーションを起動する。この場合において、該アプリケーション４０は、例えばＵＲＬや他のサイトからのリンクにより起動するものとする。

アプリケーション４０が起動されると、利用者に対応して、アプリケーション管理手段３１の実行領域が作成され、アプリケーション管理手段３１にそのアプリケーション４０がＩＤと共に登録される。

利用者が、利用者端末１０の画面に表示されるアプリケーションの詳細は後述する画面上のデータ項目の横に表示される「検索アイコン」をクリックすると、仕様管理テーブル３１ｃから、指定されたデータ項目名の送受信の向きが逆であり（指定されたデータ項目名の送受信の向きが送信の場合は受信が検索対象、受信の場合は送信が検索対象）、かつ、型名が一致するものを検索する。この際、データ項目の型名の優先順位の高いものから順に検索が行われる。例えば、「ゴルフ場検索アプリケーション」の「所在地」から、「地図」アプリケーションを検索する場合を考える。

ゴルフ場検索アプリケーションにおいて、データ項目名「所在地」に対して、図５に示すように、型名が４つあり、以下の優先順位で仕様管理テーブル３１ｃに登録されているものとする。
「所在地」、「住所」、「市町村」、「文字列」
はじめに、優先順位の最も高い「所在地」をキーに、仕様管理テーブル３１ｃを検索する（仕様管理テーブル３１ｃには全アプリケーションの情報が登録されているものとする）。この段階で所在地にマッチングするものがあれば検索結果として表示される。ここで、図５に示す例では、この段階で地図アプリケーションは検索結果に含まれない。なぜなら、地図アプリケーションの入力に「所在地」という型名が定義されていないからである。

次に、２番目の優先順位を持つ「住所」をキーに検索を行う。この段階で地図アプリケーションが検索結果に含まれる。以下、同様に、４つの型に対して検索を行う。

利用者は提示された検索結果一覧の中から、該地図アプリケーションを選択したものとする。この段階で該アプリケーションの起動処理として、プロセス管理テーブル３１ｂに、利用者用の作業領域が作成される。

この例においては、利用者用の作業領域として、プロセス管理テーブル３１ｂに１行追加される。ここに、プロセスＩＤはシステム内で一意な識別子であり、アプリケーションの実行状態を一意に特定する。アプリケーションＩＤは、起動しているアプリケーションの種類を表す識別子であり、図２への外部参照である。利用者ＩＤは、本アプリケーションを起動した利用者を示す識別子である。最後に、プロセス管理テーブル３１ｂは、該アプリケーションの実行に必要な変数領域等を保持する任意目的のデータ領域である。プロセス群ＩＤは、連携対象のプロセスを束ねるための識別子であり、連携可能な複数のプロセスは、同一のプロセス群に属する。プロセス群ＩＤは、例えば、利用者のログイン時に自動的に発行したり、利用者が明示的に連携対象の束を指定するために生成したりすることにより作成されるＩＤである。例えば、Ｗｃｈシステムの場合、プロセス群ＩＤとしてＨＴＴＰセッションを用いることで、ブラウザ起動から閉じるまでに生成したプロセスが同一のプロセス群に属する実装も考えられる。また、利用者が、明示的に連携対象のプロセス群を束ねる操作を行うといった実装も考えられる。また、アプリケーション起動時に、あるプロセスの子プロセスとして起動することを利用者が明示的に与え、連携対象のプロセスの範囲を利用者に意識させる実装も考えられる。

次に利用者が、「ゴルフ場検索アプリケーション」の後述する検索結果画面に表示される「所在地」の横の「共鳴アイコン」をクリックした場合には、連携手段３３が起動し、アプリケーション管理手段３１内に登録されているアプリケーション内で、該データ項目と連携可能なものを仕様管理テーブル３１ｃから検索する。この段階でアプリケーション管理手段３１内に本利用者に対応付けられて登録されているアプリケーションは、「ゴルフ場検索アプリケーション（予約結果画面）」、「地図アプリケーション（入力画面）」であり、「所在地」の共鳴アイコンが押された場合、先の検索処理と同様、連携元の各型名「所在地」、「住所」、「市町村」、「文字列」に対して順に、「送受信の向きが逆、かつ、現在表示している画面名と一致し、型名が一致するデータ項目名」を検索する。

この場合、「地図アプリケーション］の「住所」という項目が最初にマッチする。
ここで、送信元アプリケーションは、連携対象のデータ値である、例えば「東京都武蔵野市○○△−□−×」を、指定された形式（この場合は「住所］型）に、必要に応じて変換し連携手段３３に通知する。通知を受けた連携手段３３は、それをもう一方のアプリケーションに、型名（住所）と共にデータ値を通知する。

通知を受けた受信側アプリケーション（この場合は地図アプリケーション）は、データ値を必要に応じて解釈し、必要に応じて更新処理や、再描画処理等を行う。

連携手段３３はこの段階で、この連携の組み合わせをシステムに登録するか、利用者に尋ねる。利用者が「登録する」というのを選んだ場合、本組み合わせがアプリケーション管理手段３１のプロセス管理テーブル３１ｂから参照される連係情報テーブルに連携の組み合わせとして、送信元のアプリケーションＩＤ、送信元のアプリケーション画面名、データ名、型名、受信元のアプリケーションＩＤ、受信アプリケーション画面名、データ名、型名が登録される。

連携手段は、アプリケーション画面の変化を検知すると、該アプリケーションのＩＤ、アプリケーションの変化後の画面名をキーとして、本連携情報テーブルを検索する。該エントリが見つかった場合、受信アプリケーションがすでに起動されていれば、該受信アプリケーションにデータを通知し、受信アプリケーションが起動されていなければ、起動し、が受信アプリケーションにデータを通知する。本処理により、一旦登録した連携方法は、次回は明示的に指定せずとも有効となり、送信側アプリケーションの画面変化により、連携データが自動的に受信アプリケーションに反映するようになる。

以下、同様の手順でスケジュール管理アプリケーションの検索処理、選択処理、連携処理が行われる。
利用者が、詳細は後述する「共有」ボタンを押した時の処理を説明する。
「共有」ボタンが押されると、現在、利用者と対応付けられてアプリケーション管理手段３１内に管理されているプロセス群、並びに、その連携情報等が、一式、共有手段３４の中に移動される。より具体的には、プロセス管理テーブル３１ｂから、現在利用者が操作しているプロセス群ＩＤに属するプロセスの情報一式、並びにそこから参照される連係情報テーブルの内容をそのまま、共有手段内の同様の構造を有するテーブル内にコピーする。その際、共有手段３４内に登録された該連携アプリケーション（プロセス群）に対しＩＤが付与され、それにアクセスするためのアドレス（ＵＲＬ等）が割り振られ、利用者に「登録完了」の旨の通知と共に、該アドレスが提示される。

次に、利用者（これは、共有処理を行った利用者でなくてもよい）が該アドレスにアクセスすることで、該連携アプリケーションを利用することができる。具体的には、利用者がアドレスにアクセスすると、共有手段３４では、該アドレスに該当するＩＤを検索し、該当するＩＤがあった場合には、共有手段３４内に保持されているプロセス群、並びに連携情報テーブルの内容を一式を、今度はこの利用要求を行った利用者と関連付けてプロセス管理テーブル３１ｂにコピーする。

つまり、この共有処理は、ある利用者の行っていた作業状態（起動しているプロセスやその連携方法）を、実行時状態を保持するプロセス管理テーブル３１ｂから抽出し、共有手段３４内に永続化を行う処理であり、反対に、別の利用者（同一の利用者でもよい）がアドレスを指定し、共有手段３４を起動する処理は、共有手段３４内に永続化されている他者の作業状態を、要求を行った利用者の作業状態として、復元する処理といえる。

このように、ある利用者の利用しているプロセスや連携方法を、第三者に提供することで、利用しているアプリケーションの選択や、組み合わせ方に関するノウハウを本装置内に蓄積し、他社と共有することが可能となる。

以下、ゴルフ場を検索する場合の、利用者の具体的な利用例について説明する。本利用例では、サービス利用者が、ＰＣや、携帯などの情報端末からブラウザを操作して、ゴルフ場を予約し、次に、そこまでの地図を検索し、その予定をスケジュール帳に登録する例を説明する。本利用例では、３つのアプリケーション：「ゴルフ場予約アプリケーション」、「地図アプリケーション」、「スケジュール管理アプリケーション」を用いてゴルフ場検索を行う例を説明する。

図６において、利用者はブラウザからＵＲＬを指定してゴルフ場検索アプリケーションを開き、所望のゴルフ場を検索する。図６は予約が完了した画面を表している。

図６の予約結果の画面上で、「所在地」が表示され、その横に「アイコン」が表示されている。このアイコンは、本データが他のコンポーネントと連携可能であることを示している。１つ目のアイコンは、「検索ボタン」（虫眼鏡の図）を表し、２つ目のアイコンは「共有ボタン」（音叉の図）を表す。検索ボタンを押すと、「住所」データを利用可能な他のコンポーネントの一覧が表示される（図７）。共有ボタンを押すと、同一のＷｅｂページ内で「住所」を利用なコンポーネントにデータが転送される。

ここでは、利用者は「所在地」の横に表示されている「検索アイコン」を押すと、図８が表示される。ここで、検索結果の一番上の地図アプリケーションを選んだものとする。すると、図９のような画面が表示される。

ここでゴルフ検索アプリケーション画面上の「所在地」の横に表示されている「共鳴アイコン］を利用者がクリックすると、「所在地」に記載されている値「東京都武蔵野市○○−△−□−×」が、地図アプリケーション上の住所入力フォームに転送される。

ここで、「この連携をシステムに登録しますか〜」という確認が表示される。利用者は次回以降もこの組み合わせを利用しようと思えば「登録する」ボタンを押し、この組み合わせが単に一時的な組み合わせであれば、「登録しない」ボタンを押す。登録するボタンを押すと、次回以降、このゴルフ場検索アプリケーションで予約結果を表示した時に、自動的に地図のフォームに住所が転送されるようになる。

次に利用者は、このゴルフの予約を自分のスケジュール帳に登録したいと考え、「日程」部分の検索アイコンをクリックし、上記検索の手順と同様、「スケジュール管理アプリケーション」を選んだものとする（図１０）
今度は日程のデータを転送したいので、日程部分の共鳴アイコンをクリックする。すると同様に、スケジュール管理アプリケーションにそのデータが転送される。

また、今の例は逐次的に連携を行ったが、利用者は始めに所望のアプリケーションを検索し、配置した上で、ゴルフ場検索アプリケーションの上部タイトルバー部分に表示されている共有ボタンをクリックすることで、個別に連携させたいデータを選択しなくても、同一画面上に配置されている連携可能なデータをまとめて転送させることができる。

タイトルバーに表示されている検索・共有アイコンをクリックしたときの動作は、データ項目横に提示されている各々のアイコンをクリックした時の動作をまとめて起動することを表す。例えば、ゴルフ場アプリケーションの画面には、「ゴルフ場名」、「人数」、「日程」等多数のデータ項目が表示されているが、タイトルバー上のアイコンをクリックした場合、各データ項目のアイコンを逐次的に全てクリックした時と同様の動作が行われる。

検索も同様に、「所在地」、「日程」と個別に検索を行わずとも、ゴルフ場検索アプリケーションの上部タイトルバー部分に表示されている検索ボタンを押すことで、利用者は、ゴルフ場検索アプリケーションと連携可能なアプリケーションの一覧をまとめて検索することが可能である。

上記の説明では、ＰＣ端末上のブラウザにおける操作の例として、いわゆるポータルサイトのようにアプリケーションをタイル上に並べている例を示しているが、必ずしもこの形式で表示する必要はない。例えば、携帯端末のような場合、小さい画面の場合、一度に表示するアプリケーションは１つだけとすることもできる。通常のＧＵＩ系のＯＳでは、全アプリケーションを画面上に配置する必要はなく、例えばタスクバー等の手段を提供し、ＯＳ上で動作するアプリケーションを切り替えることで、画面の有効活用を図っている。携帯端末でもこれと同様の手段を利用することで、小さい画面を有効活用できる。また、共有ボタンをクリックした際に、連携対象のアプリケーションへ自動的に画面を切り替えることも可能である。

最後に利用者はタイトルバーに表示されるアプリケーションの共有ボタンを押す。共有ボタンが押されると、このアプリケーションの組み合わせが共有手段３４に登録され、第三者に利用させることが可能となる。

これにより、利用者は他社が連携したアプリケーションに対して更に、付加価値を高めるようなアプリケーションを追加したり、連携を追加したりすることを、元の連携アプリケーションに影響を与えずにでき、かつ、それを再度登録することが可能である。

本発明の実施形態により、前述した課題が、それぞれ以下の理由で解決される。
課題（１）、（４）に対して、利用者は連携対象のアプリケーションが送信可能なデータ形式、もしくは受信可能なデータ形式を基に、検索手段を用いて該アプリケーションと連携可能なアプリケーションを検索・選択できる。さらに、アプリケーション管理手段３１により、それを連携対象とすることができる。

課題（２）について、本発明の実施形態では、アプリケーションが送信（受信）可能なデータ形式を複数登録でき、かつ、それに優先順位がついている。また、連携対象となっている複数アプリケーションの送受信するデータ形式のマッチング処理を行い、データの連携を行うため、利用者は個別に連携部分を逐次指定しなくても、連携可能である。このように、各アプリケーションが送受信可能なデータ形式を複数の形式で、希望する形式から順にシステムに登録できる仕様管理テーブルを備えており、連携する際に連携対象アプリケーション間で連携可能なデータをマッチングして、データを連携させるため、様々なフォーマットのデータ形式に対応可能である。

課題（５）について、利用者が検索・選択、そして、連携させたアプリケーションの組み合わせは、アプリケーション管理手段３１で管理されており、利用者が共有処理を、その組み合わせ（アプリケーション群）が、共有領域で管理する共有手段を有するため、組み合わせたアプリケーションを、自身の所属する特定のコミュニティや、不特定多数の第三者間で共有できる。

本発明は、上記各実施の形態に限ることなく、その他、実施段階ではその要旨を逸脱しない範囲で種々の変形を実施し得ることが可能である。
例えば、上記の実施形態では、連携手段は、連携可能な部分を全て連携させるような記述としたが、これに限らず、利用者が明示的に操作したり、指定したりした一部分のみを連携させてもよいし、一旦連携情報を保存しておき、同一の情報が再度提示されたときに自動的に連携させるようにしてもよい。また、連携可能なデータについては、アイコンに限らず、強調表示などにより明示してもよい。
さらに、上記各実施形態には、種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組合せにより種々の発明が抽出され得る。

また、例えば各実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。

本発明の一実施形態に係るデータ連携装置の概略構成と該データ連携装置が適用されるシステムの構成例を示す図。 アプリケーション管理テーブルへのデータの登録例を示す図。 プロセス管理テーブルへのデータの登録例を示す図。 アプリケーション管理手段が保持するデータ例を示す図。 仕様管理手段で管理されるデータ例を示す図。 ゴルフ場を検索する場合の、利用者の具体的な利用例（画面例）を示す図。 ゴルフ場を検索する場合の、利用者の具体的な利用例（画面例）を示す図。 ゴルフ場を検索する場合の、利用者の具体的な利用例（画面例）を示す図。 ゴルフ場を検索する場合の、利用者の具体的な利用例（画面例）を示す図。 ゴルフ場を検索する場合の、利用者の具体的な利用例（画面例）を示す図。

符号の説明

１０…利用者端末
３０…データ連携装置
３１…アプリケーション管理手段
３２…検索手段
３３…連携手段
３４…共有手段
４０…アプリケーション

Claims (11)

1. 複数アプリケーション間におけるデータを連携するデータ連携装置において、
   連携対象のアプリケーションが送信もしくは受信可能なデータに付与された少なくとも１つのデータ形式の名称を保持する仕様管理手段と、
   １つのアプリケーション上の１つ以上のデータを他のアプリケーションに連携させる際に、前記データに付与された前記データ形式の名称が、前記他のアプリケーションのデータ形式の名称と一致する項目に、データを転送する連携手段とを具備することを特徴とするデータ連携装置。
2. 複数アプリケーション間におけるデータを連携するデータ連携装置において、
   連携対象のアプリケーションが送信もしくは受信可能なデータに付与された少なくとも１つのデータ形式の名称を、優先度順位順に保持する仕様管理手段と、
   １つのアプリケーション上の１つ以上のデータを他のアプリケーションに連携させる際に、前記データに付与された前記データ形式の名称が、前記他のアプリケーションのデータ形式の名称と一致する項目に、データを転送する連携手段とを具備することを特徴とするデータ連携装置。
3. 請求項１又は２に記載のデータ連携装置において、前記１つのアプリケーション上の１つ以上のデータに付与されたデータ形式の名称に対して、前記他のアプリケーションのデータ形式の名称と一致するものが複数存在する場合に、前記連携手段は、利用者に連携対象の選択を促す画面を表示すると共に、前記利用者によって選択された項目に対してデータを転送することを特徴とするデータ連携装置。
4. 請求項１乃至請求項３のいずれか１項に記載のデータ連携装置において、アプリケーション利用者がアプリケーション上の送信又は受信可能なデータ形式を送信又は受信した際に、該アプリケーションと連携可能なデータ項目を有するアプリケーションを検索する検索手段を更に具備することを特徴とするデータ連携装置。
5. 請求項４に記載のデータ連携装置において、前記検索手段で検索されたアプリケーションを連携対象として管理するアプリケーション管理手段を更に具備することを特徴とするデータ連携装置。
6. 請求項１乃至請求項５のいずれか１項に記載のデータ連携装置において、前記連携手段は、利用者が明示的に連携操作を行ったときに、前記連携可能な部分を連携させることを特徴とするデータ連携装置。
7. 請求項１乃至請求項５のいずれか１項に記載のデータ連携装置において、前記連携手段は、前記連携可能な部分のうち、利用者が明示的に指定した個別のデータのみを連携させることを特徴とするデータ連携装置。
8. 請求項１乃至請求項５のいずれか１項に記載のデータ連携装置において、前記連携手段は、一旦連携した連携の組み合わせを保存し、次回同一の情報が提示された時に、自動的に連携することを特徴とするデータ連携装置。
9. 請求項１乃至請求項８のいずれか１項に記載のデータ連携装置において、連携した連携の組み合わせを、第三者に利用できるように登録する共有手段を備えたことを特徴とするデータ連携装置。
10. 請求項１乃至請求項８のいずれか１項に記載のデータ連携装置において、連携対象のアプリケーション内に、連携可能なデータが存在する場合に、該データをアイコン・強調表示等で他の情報と区別して表示することを特徴とするデータ連携装置。
11. 複数アプリケーション間におけるデータを連携するデータ連携方法において、
    連携対象のアプリケーションが送信もしくは受信可能なデータに付与された少なくとも１つのデータ形式の名称を優先度順位順に保持する工程と、
    １つのアプリケーション上の１つ以上のデータを他のアプリケーションに連携させる際に、前記データに付与された前記データ形式の名称が、前記他のアプリケーションのデータ形式の名称と一致する項目に、データを転送する工程とを具備することを特徴とするデータ連携方法。

Images