JP5224475B2 - 情報処理装置、情報処理方法、及びコンピュータプログラム - Google Patents

Description

本発明は、あるウェブ電子スケジュールサービスに登録する情報を、当該ウェブ電子スケジュールサービスと関連付けられた他のウェブ電子スケジュールサービスにも登録する通信制御方法に関するものである。

ネットワーク技術の発展によって、情報の共有が非常に簡便に、かつ効率的に行うことが可能になっている。企業などの組織では、会議予定や出張予定の情報などの管理、共有をするために、グループウェアやイントラネットシステムを使用したスケジュール管理が広く行われている。これらを用いることで、スケジュールの管理、共有を容易に行えるようにはなっているが、情報漏えい等に対するセキュリティ対策として、企業などの組織内のコンピュータネットワークに設定されているグループウェアやイントラネットシステムには、ファイアウォール等で外部インターネットから直接接続できないようにしているのが一般的である。

当然、出張先や外出先からインターネットを経由してスケジュールを確認したいという要望もある。そのような要望にこたえるには、組織内のコンピュータネットワークに接続されているウェブ電子スケジュールサービスを提供するサーバを外部に公開する必要があり、そのためには、例えば、リバースプロキシ装置等の装置が必要となる。そのため、その運用に係るコスト面、管理面での負荷が高くなってしまうともに、サーバを外部に公開するので、情報漏えいの危険性が増してしまう虞がある。

一方、インターネット上に公開されているウェブ電子スケジュールサービスが多数存在する。有料、無料のサービスがあるが、いずれのサービスもインターネットに接続できる環境からであれば、ウェブブラウザアプリケーションを用いて容易に利用できる。すなわち、企業などの組織内のコンピュータネットワークからでも、出張や外出中などでもコンピュータをインターネットに接続していれば利用できるので利便性は高い。しかし、企業内でデータが管理されている電子スケジュールサービスと異なり、予定を外部のサーバに登録しなくてはならないので、情報漏えいの危険性に繋がるという問題が発生してしまう。また、企業内で組織的に運用されている電子スケジュールサービスと異なり企業固有の組織情報などは管理されないため、インターネット上に公開されているウェブ電子スケジュールサービスだけでは、企業内のグループ間の情報共有などの目的には利用しづらい。

特許文献１には、異なるスケジュール登録装置で管理されているユーザのスケジュールデータを、電子メールを用いて同期処理を行う発明が開示されている。この発明では、管理体系が異なる２つのスケジュール登録装置間で統一的なルールに基づいて作成された電子メールで情報をやりとりすることで、一方のスケジュール登録装置で登録されたスケジュールデータを他方のスケジュール登録装置に登録することが可能となっている。

特開２００３―２５６６２３号公報

しかしながら、電子スケジュールサービスを行っている多くのサービスプロバイダはスケジュールデータの追加、削除、変更といったデータ操作を、各々のサービスプロバイダ独自の規約に従って行っており、複数のサービスプロバイダで統一的なルールに基づいて行っているわけではない。よって、社内で使用しているスケジュール管理システムで管理されているスケジュールデータと、現在広く行われているウェブ電子スケジュールサービスでのスケジュールデータとを特許文献１に開示されているような手法で同期処理を行うのは現実的ではない。

さらには、特許文献１に開示されている発明は、スケジュールデータを共有することにとどまっており、スケジュールサービスを提供する外部サーバに登録するスケジュールデータによる情報漏えいについては何ら考慮されていない。

そこで、本願発明は、例えば、社内スケジュール管理システムで使用しているサーバ装置とスケジュールサービスを提供する外部サーバといった、共通のデータ操作方法を有さないスケジュールサーバ間であっても、それらで登録されているスケジュールデータの同期処理を可能とすることを第１の目的とする。

また、本願発明は、第１の目的に加えて更に、スケジュールデータの同期処理のために社内のスケジュールサーバで登録されている情報をウェブ電子スケジュールサービスを提供する外部サーバに登録する際に、情報漏えいの危険性を低減させることを可能とすることを第２の目的とする。

上記の第１の目的を達成するために、本願発明の情報処理装置は以下の構成を備える。即ち、スケジュール管理サービスを提供するサーバ装置と通信可能な情報処理装置であって、スケジュール管理サービスを提供する第１のサーバ装置に対して送信されるスケジュール管理に係る送信データである第１の送信データの構造を定義した第１の定義情報、及び、前記第１のサーバ装置とは異なる、スケジュール管理サービスを提供する第２のサーバ装置に対して送信されるスケジュール管理に係る送信データである第２の送信データの構造を定義した第２の定義情報を記憶する第１の記憶手段と、ブラウザアプリケーションで生成された送信データが前記第１のサーバ装置に対する前記第１の送信データであるかを判定する第１の判定手段と、前記第１の判定手段で、前記第１のサーバ装置に対する前記第１の送信データであると判定した後に、前記第１の定義情報で定義された前記第１の送信データの構造に従って、前記第１のサーバ装置に送信される前記第１の送信データからデータ内容を取得する第１の取得手段と、前記第１の取得手段で取得したデータ内容と、前記第２の定義情報とに従って、前記第２のサーバ装置に対して送信する前記第２の送信データを生成する生成手段と、前記生成手段で生成した前記第２の送信データを前記第２のサーバ装置に対して送信する送信手段と、を備えることを特徴とする。

上記の第２の目的を達成するために、本願発明の情報処理装置はさらに以下の構成を備える。前記第１のサーバ装置に送信される前記第１の送信データに含まれる文字列情報のうち、前記生成手段により前記第２の装置サーバに送信される前記第２の送信データを作成する際に、文字列変換を行う文字列である変換前文字列とその変換後の文字列である変換後文字列とを対応付けて記憶する第２の記憶手段をさらに備え、前記第１の取得手段で取得した前記第１のサーバ装置に送信する前記第１の送信データのデータ内容に前記第２の記憶手段に記憶されている変換前文字列に合致する文字列が含まれている場合に、前記生成手段は、前記変換前文字列と対応付けられている変換後文字列を用いて前記第２のサーバに送信する前記第２の送信データを生成することを特徴とする。

上記の第１の目的を達成するために、本願発明の情報処理方法は以下の構成を備える。即ち、スケジュール管理サービスを提供する第１のサーバ装置に対して送信されるスケジュール管理に係る送信データである第１の送信データの構造を定義した第１の定義情報、及び、前記第１のサーバ装置とは異なる、スケジュール管理サービスを提供する第２のサーバ装置に対して送信されるスケジュール管理に係る送信データである第２の送信データの構造を定義した第２の定義情報を記憶する記憶装置を備える情報処理装置によって行われる情報処理方法であって、ブラウザアプリケーションで生成された送信データが前記第１のサーバ装置に対する前記第１の送信データであるかを判定する第１の判定工程と、前記第１の判定工程で、前記第１のサーバ装置に対する前記第１の送信データであると判定した後に、前記第１の定義情報で定義された前記第１の送信データの構造に従って、前記第１のサーバ装置に送信される前記第１の送信データからデータ内容を取得する第１の取得工程と、前記第１の取得工程で取得したデータ内容と、前記第２の定義情報とに従って、前記第２のサーバ装置に対して送信する前記第２の送信データを生成する生成工程と、前記生成工程で生成した前記第２の送信データを前記第２のサーバ装置に対して送信する送信工程と、を備えることを特徴とする。

上記の第２の目的を達成するために、本願発明の情報処理方法はさらに以下の構成を備える。即ち、前記記憶装置にはさらに、前記第１のサーバ装置に送信される前記第１の送信データに含まれる文字列情報のうち、前記生成工程により前記第２の装置サーバに送信される前記第２の送信データを作成する際に、文字列変換を行う文字列である変換前文字列とその変換後の文字列である変換後文字列とが対応付けて記憶されており、
前記第１の取得工程で取得した前記第１のサーバ装置に送信する前記第１の送信データのデータ内容に前記記憶装置に記憶されている変換前文字列に合致する文字列が含まれている場合に、前記生成工程は、前記変換前文字列と対応付けられている変換後文字列を用いて前記第２のサーバに送信する前記第２の送信データを生成することを特徴とする。

本発明によれば、企業など組織内のコンピュータネットワークに設置されている電子スケジュールサービスに対するリクエスト情報から、外部のインターネット上で公開・提供されているウェブ電子スケジュールサービスへデータに対するリクエスト情報に必要となる情報を取得し、取得した情報に従って外部ウェブ電子スケジュールサービス用のデータを生成し、外部ウェブ電子スケジュールサービスの情報の更新を行うので、容易に内部電子スケジュールサービスと外部ウェブ電子スケジュールサービスとの情報の同期処理を行うことが可能となる。

また、さらには、データの書き換えを行う際に特定のキーワードが出現した場合に、あらかじめ設定されているルールに従ってデータの置換えが行われるので、スケジュールデータの同期処理を起因とする情報の漏洩を低減することが可能となる。

本願発明の情報処理システム構成の一例を示す構成図である。 図１のクライアント装置１０１のハードウェア構成の一例を示すブロック図である。 図１のクライアント装置１０１の機能構成の一例を示す模式図である。 クライアント装置１０１にインストールされている拡張機能１１２の起動時の処理を示すフローチャートである。 ウェブブラウザ１１１、拡張機能１１２、内部ＨＴＴＰサーバ１０２、及び外部ＨＴＴＰサーバ１０５間の通信と処理の順序の一例を示すシーケンス図である。 ウェブブラウザ１１１の画面の一例を示す模式図である。 ウェブブラウザ１１１の画面の一例を示す模式図である。 外部スケジュールサービス連携処理の手順の一例の一例を示すフローチャートである。 図８のステップＳ８０６のイベント記録処理の詳細を示すフローチャートである。 図８のステップＳ８０９のスケジュール追加・変更処理の詳細を示すフローチャートである。 図８のステップＳ８１１のスケジュール削除処理の詳細を示すフローチャートである。 図１０のステップＳ１００８の外部イベント検索処理の詳細を示すフローチャートである。 図１２のステップＳ１２０７のイベントＬＩＳＴ取得処理の詳細を示すフローチャートである。 外部サービス同期処理の一例を示すフローチャートである。 スケジュールサービス定義情報の入力画面の構成の一例を示す図である。 リクエスト定義情報の入力画面の構成の一例を示す図である。 書換えルールの入力画面の構成の一例を示す図である。 スケジュールサービス定義情報テーブルの構成の一例を示す図である。 リクエスト定義情報テーブル（内部スケジュールサービス）の構成の一例を示す図である。 リクエスト定義情報テーブル（外部スケジュールサービス）の構成の一例を示す図である。 書換えルールテーブルの構成の一例を示す図である。 スケジュールイベントテーブルの構成の一例を示す図である。

以下、図面を参照して、本願発明の実施形態を詳細に説明する。図１は、本発明の実施形態に係る、システム構成の一例を示す図である。尚、図１に示す各種端末の構成は一例であり、目的や用途に応じて様々な構成例があることは言うまでもない。

図１に示すように、本実施形態にかかる情報処理システムのイントラネット１００には、クライアント装置１０１−１乃至１０１−３（以下、まとめてクライアント装置１０１とする）、内部ＨＴＴＰサーバ１０２が設置されており、それら端末は、ローカルエリアネットワーク（ＬＡＮ）１０３を介して相互に通信可能に接続されている。

また、クライアント装置１０１は広域ネットワーク１０４を介して、外部ＨＴＴＰサーバ１０５−１乃至１０５−３（以下まとめて外部ＨＴＴＰサーバ１０５とする）と相互に通信可能に接続されている。また、ＬＡＮ１０３と広域ネットワーク１０４の間には不図示のファイアウォール装置が設置されており、あらかじめ決められた規則に従った通信制御処理が行われている。

それぞれのクライアント装置１０１には、図１に示す通りウェブブラウザアプリケーション１１１（以下ウェブブラウザ１１１とする）と、当該ウェブブラウザ１１１に機能拡張をするためのアプリケーションである拡張機能アプリケーション１１２（以下、機能拡張１１２とする）がインストールされている。クライアント装置１０１は、このウェブブラウザ１１１の機能により内部ＨＴＴＰサーバ１０２や外部ＨＴＴＰサーバ１０５等に接続する。また、拡張機能１１２は、ウェブブラウザ１１１によるデータの入出力を監視し、内部ＨＴＴＰサーバとの間の通信内容を特定し、その通信内容に応じて後述する各種の処理を行うことになる。

内部ＨＴＴＰサーバ１０２は、クライアント装置１０１を利用するユーザに対してウェブ電子スケジュールサービス（以下、内部スケジュールサービスという）を提供するためのサーバ装置であり、当該クライアント装置１０１からの要求に応じて会議等の予定の登録、修正、削除、閲覧処理などを行う。

また、外部ＨＴＴＰサーバ１０５は、一般のサービスプロバイダに設けられているウェブサーバであり、内部ＨＴＴＰサーバと同様、広域ネットワーク１０４を経由してアクセスしてきたクライアント装置１０１からの要求に応じて会議等の予定の登録、修正、削除、閲覧処理などを行うスケジュールサービス（以下、外部スケジュールサービスという）を提供する。その際にクライアント装置１０１から外部ＨＴＴＰサーバ１０５には、それぞれの外部ＨＴＴＰサーバ１０５で規定されたＨＴＴＰリクエストデータのデータ構成に従ったＨＴＴＰリクエストデータが送信されることになる。インターネット上で提供されている電子スケジュールサービスとして、例えば、米国Ｇｏｏｇｌｅ社のＧｏｏｇｌｅＣａｌｅｎｄａｒがある。

図２は、図１に示すクライアント装置１０１のハードウェア構成の一例を示すブロック図である。

図２において、ＣＰＵ２０１は、システムバス２０４に接続される各種のデバイスやコントローラを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳとする）や、クライアント装置１０１が各種の処理を実行するための各種プログラムが記憶されている。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要となるプログラムやデータをＲＡＭ２０２にロードし、プログラムを実行することで後述する各種の動作を実現する。

また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。ビデオコントローラ（ＶＣ）２０６は、ディスプレイ装置２１０等の表示装置への表示を制御する。ディスプレイ装置２１０は、例えば、ＣＲＴや液晶ディスプレイ等で構成されている。これらは必要に応じて管理者が使用するためのものである。また、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ装置２１０への表示を可能としている。

メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ＯＳ、各種アプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフロッピーディスク（登録商標 ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュメモリ等の外部メモリ２１１へのアクセスを制御する。本発明を実現するためのウェブブラウザ１１１や機能拡張１１２は外部メモリ２１１に記憶されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行される。本発明に係わるウェブブラウザ１１１や拡張機能１１２が用いる定義情報及び各種情報テーブルは外部メモリ２１１に記憶されている。これらについての詳細な説明は後述する。

通信Ｉ／Ｆ（インターフェース）コントローラ（通信Ｉ／ＦＣ）２０８は、ＬＡＮ１０３や広域ネットワーク１０４等のネットワークを介して外部機器と接続・通信するためのものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。

図３は、クライアント装置１０１の機能構成を示す模式図である。図３に示すように、クライアント装置１０１は、スケジュールサービス定義情報設定手段３１１、リクエスト定義情報設定手段３１２、書き換えルール設定手段３１３を含む定義情報管理部３１０と、スケジュールサービスリクエスト取得手段３２１、リクエスト解析手段３２２、外部リクエスト生成・送信手段３２３を含む外部スケジュールサービス連携部３２０と、同期状態確認手段３３１、内部・外部スケジュール取得手段３３２、スケジュール差分解析手段３３３、外部リクエスト生成・送信手段３３４を含む外部スケジュールサービス同期部３３０を備えている。

スケジュールサービス定義情報設定手段３１１は、ウェブ電子スケジュールサービスのアクセス先と認証情報（詳細は後述する図１５、図１８）等のスケジュールサービス定義情報の入力を受け付け、スケジュールサービス定義情報テーブル３４１に設定（登録、修正、削除等）する。

スケジュールサービス定義情報設定手段３１１は、スケジュールサービス定義情報の入力を受け付けるため、例えば、図１５に示すようなスケジュールサービス定義情報の入力画面１５００をクライアント装置１０１のディスプレイ装置２１０に表示する。

図１５は、クライアント装置１０１のディスプレイ装置２１０に表示されるスケジュールサービス定義情報の入力画面の一例を示す図である。

図１５に示す入力画面１５００では、スケジュールサービス定義情報として、アクセス先のスケジュールサービスを示す名称及びＵＲＬ、当該スケジュールサービスを提供するＨＴＴＰサーバがイントラネット１００に設置されているか（内部ＨＴＴＰサーバ１０２であるか）、それともインターネット等の広域ネットワーク１０４に設置されているか（外部ＨＴＴＰサーバ１０５であるか）を示す、「内部」または「外部」のロケーションの区分情報、当該スケジュールサービスを利用する際の認証情報であるアカウント名とパスワードなどの項目の入力を受け付けるためのコントロールが用意されており、クライアント装置１０１は、この入力画面１５００を介して入力された各種のデータをスケジュールサービス定義情報として受け付ける。

図中、１５０１は、スケジュールサービス選択欄であって、既に登録済みのスケジュールサービスが選択可能に設定されており、ユーザは既に登録済みのスケジュールサービス定義情報の修正、削除を行う際に、修正、削除の対象となるスケジュールサービスをこの選択欄で選択する。１５０２は、スケジュールサービスの名称を入力・表示するためのコントロールである。また、１５０３は、スケジュールサービスを提供するＨＴＴＰサーバのアクセス先を示すＵＲＬを入力・表示するためのコントロールである。

１５０４は、スケジュールサービスを提供するＨＴＴＰサーバのロケーションの区分情報（「内部」または「外部」）を設定するためのラジオボタンである。また、認証情報１５０５には、スケジュールサービスを利用する際に用いられるアカウント名入力欄１５０５−１、及びパスワード入力欄１５０５−２が設定されている。また、追加ボタン１５０６は新規にスケジュールサービスを追加する際に、編集ボタン１５０７は既に登録済みのスケジュールサービスの内容を修正する際に、削除ボタン１５０８は登録済みのスケジュールサービスを削除する際に用いられるボタンである。

この入力画面１５００を介してユーザより入力を受け付けたスケジュールサービス定義情報は、図１８に示すスケジュールサービス定義情報テーブル３４１に登録されることになる。

図１８は、本願発明で用いられるスケジュールサービス定義情報テーブル３４１の一例を示す図である。図１８に示すように、スケジュールサービス定義情報テーブル３４１は、スケジュールサービスを一意に識別するためのＩＤ１８０１、及び、そのＩＤで特定されるスケジュールサービスに対応する、サービス名１８０２、ＵＲＬ１８０３、内部若しくは外部の区分情報を示すロケーション１８０４、当該スケジュールサービスを利用する際に認証情報として用いるアカウント名１８０５、パスワード１８０６のセットが記録されている。

例えば、ＩＤ１８０１が１のスケジュールサービスは、サービス名１８０２に「Office Schedule」、ＵＲＬ１８０３に「http://o-schedule.cgn.aaa.co.jp/s.cgi」、ロケーション１８０４に「内部」、アカウント名１８０５に「username」、パスワード１８０６に「password」が設定されていることが理解できよう。

図３の説明に戻る。図３に示すリクエスト定義情報設定手段３１２は、スケジュールサービス毎に当該スケジュールサービスで管理されるスケジュールデータを操作（追加・修正・削除等）するためのＨＴＴＰリクエストデータの構造と、データ内容を示すパラメータ情報（詳細は後述する図１６、図１９）の入力を受け付け、受け付けたそれら情報をリクエスト定義情報テーブル３４２に設定する。リクエスト定義情報設定手段３１２は、リクエスト定義情報を受け付けるため、たとえば図１６に示すようなリクエスト定義情報の入力画面１６００をクライアント装置１０１のディスプレイ装置２１０に表示する。

図１６は、クライアント装置１０１のディスプレイ装置２１０に表示されるリクエスト定義情報の入力画面の一例を示す図である。

図１６に示す入力画面１６００には、リクエスト定義情報として、前記スケジュールサービス定義情報設定手段で定義されたサービスを示すサービス名、ＵＲＬ、操作種別を表すアクション、アクションを特定するための条件、リクエストパラメータやレスポンスデータとイベント項目の対応、同期対象のサービス名、同期時にイベントの内容を書換えるかなどの項目の入力を受け付けるためのコントロールが設定されている。そして、この入力画面１６００を介して入力されたリクエスト定義情報は、図１９に示すリクエスト定義情報テーブル３４２に登録されることになる。

図中１６０１は、リクエスト定義情報を設定するスケジュールサービスを選択するためのコントロールである。１６０２は、コントロール１６０１で選択されたスケジュールサービスを提供するＨＴＴＰサーバのロケーションを表示する表示欄であり、内部ＨＴＴPサーバ１０２の場合には「内部」、外部ＨＴＴＰサーバ１０５の場合には「外部」と表示することになる。

追加ボタン１６０３は新規にリクエスト定義情報を追加する際に、編集ボタン１６０４は登録済みのリクエスト定義情報の内容を修正する際に、削除ボタン１６０５は既に登録済みのリクエスト定義情報を削除する際に用いられるボタンである。

１６０６はＵＲＬ表示欄であって、コントロール１６０１で選択されたスケジュールサービスを提供するＨＴＴＰサーバのＵＲＬ表示する表示欄である。

１６０７はアクション指定欄であって、当該スケジュールサービスに対するデータ操作を指定するためのコントロールである。１６０８は、１６０７で指定されたアクションに対応するＨＴＴＰリクエストのデータ通信を特定するための条件を入力・表示するためのコントロールである。１６０９は、各種イベント項目に対応する値が設定されるイベントパラメータを入力・表示するためのコントロールである。イベント項目としては、例えば、開始年、開始月、開始日、開始時、開始分、終了年、終了月、終了日、終了時、終了分、予定件名、詳細内容等があり、それらイベント項目に対応する値がＨＴＴＰリクエスト中のどのパラメータに設定されるかの情報を入力するためのコントロールである。

１６１０は、コントロール１６０１で内部スケジュールサービスが選択された場合に、当該スケジュールサービスと同期処理を行う外部スケジュールサービスを指定するためのコントロールである。１６１１は、外部ＨＴＴＰサーバ１０５へのデータ同期処理の際に、後述する書き換えルールに従ったデータ変換を行うかを指定するためのチェックボックスである。また、１６１２は、当該アクションに係るＨＴＴＰリクエストをＨＴＴＰサーバに送信したのちにＨＴＴＰサーバより受信するレスポンスデータ定義情報を入力するための不図示の入力画面をディスプレイ装置２１０に表示させるために用いられるボタンである。

図１９−１、図１９−２は、本発明で用いるリクエスト定義情報テーブルの一例を示す図である。図１９−１、図１９−２のように、リクエスト定義情報テーブル３４２は、それぞれのＩＤ１９０１に対応するスケジュールサービスＩＤ１９０２、アクション１９０３、リクエスト条件１９０４、リクエストパラメータ定義１９０５、レスポンスデータ定義１９０６、処理定義１９０７が設定されている。

リクエストＩＤ１９０１には、リクエスト定義情報を一意に識別するための識別情報が設定される。サービスＩＤ１９０２には、対応するスケジュールサービスを一意に識別するためのサービスＩＤが設定される。アクション１９０３には、スケジュールサービスに対して要求する操作が設定される。例えば、新規のスケジュールデータの追加操作であるADD、登録済みのスケジュールの削除を要求するDELETE等が設定されることになる。

リクエストパラメータ定義には、開始年、開始日、終了年、終了日、内容等のイベント項目が、ＨＴＴＰサーバに対して送信されるＨＴＴＰリクエストのどのパラメータ変数に定義されているかが設定される。例えば、図１９−１のリクエストＩＤが１のデータの場合には、開始年がstartyearに、開始月がstartmonthに、・・・内容がDetailに、その他がOtherに設定されることを意味している。

レスポンスデータ１９０６には、ＨＴＴＰサーバに対してＨＴＴＰリクエストの送信した結果、ＨＴＴＰサーバから送信されるレスポンスデータのデータ構成が設定されることになる。処理定義１９０７には、内部スケジュールサービスで管理するスケジュール情報に変更が加えられた際に同期をとる外部スケジュールサービスのサービスＩＤ、実行アクション、内容の書き換えを行うか否かの情報が設定される。

図１９−１は内部スケジュールサービスのリクエスト定義情報を示すもので、例えば、リクエストＩＤ１９０１が１のデータは、対応するスケジュールサービスＩＤ１９０２が１（図１８に示すOffice Scheduleである）、リクエスト条件１９０３にＵＲＬがhttp://o-schedule.cgn.aaa.co.jpに一致し、パラメータ値にpage==scheduleaddかつ_Submit==’add’を持つという設定が、リクエストパラメータ定義１９０４に開始年=startyear、開始月=startmanth、・・・・内容=Detail、その他=Otherが、レスポンスデータ定義１９０６に「なし」が、処理定義１９０７には同期サービスが２、実行アクションとしてＡＤＤアクション、同期処理を行う際に書き換えルールに従って文字列変換を行うことが設定されている。

また、図１９−２は、外部スケジュールサービスのリクエスト定義情報を示すもので、内部スケジュールサービスの場合と同様のデータが設定される。図１９−１、図１９−２に係るリクエスト定義情報３４２は、外部スケジュールサービス連携部３２０、外部スケジュールサービス同期処理部３３０の処理の際に用いられる。

図３の説明に戻る。書換えルール設定手段３１３は、後述するリクエスト解析手段３２２で特定したスケジュールデータを他の外部スケジュールサービスに対して設定（登録・修正等）する際に用いられる、文字列の書換えルールの入力を受け付け、書換えルールテーブル３４３に設定する。

書換えルール設定手段３１３は、書換えルールの入力を受け付けるために、例えば、図１７に示すような書換えルールの入力画面１７００をクライアント装置１０１のディスプレイ装置２１０に表示する。

図１７は、クライアント装置１０１のディスプレイ装置２１０に表示される書換えルールの入力画面の一例を示す図である。

図１７に示す入力画面１７００には、書換えルールとして書換えルールを一意に示すＩＤ、書換え対象とするキーワード条件、キーワードの包含条件、条件に合致した場合の書換え文字列、設定したルールに一致しない場合のデフォルト処理指定、及び、デフォルト処理で書換えが指定された場合の書換え文字列の入力を行うための各種コントロールが設定されている。そして、この入力画面１７００を介して入力された書換えルールは、図２０に示す書換えルールテーブル３４３に登録されることになる。

図中１７０１は、書換えルールを一意に識別するルールＩＤが表示されるコントロールである。１７０２はキーワード条件入力欄、１７０３はキーワード包含条件入力欄であって、スケジュールの内容にどのようなキーワード（キーワード条件）どのような形で含まれている場合に当該書換えルールに従った文字列変換を行うかの条件（キーワード包含条件）入力を行うためのコントロールである。１７０４は、キーワード条件、及びキーワード包含条件に合致したスケジュールの内容を外部ＨＴＴＰサーバ１０５が提供するスケジュールサービスに設定する際に用いる文字列情報の入力を行うためのコントロールである。

図２０は、本発明で用いる書換えルールテーブルの一例を示す図である。図２０に示すように、書換えルールテーブル３４３には、それぞれのルールＩＤ２００１に対応するキーワード（キーワード条件）２００２、条件（キーワード包含条件）２００３、書換え文字列２００４のセットが記録されている。例えば、ルールＩＤ＝１には、キーワードに“社外秘”が、条件に“を含む”が、書換え文字列に“＊＊＊”がセットで関連付けられている。

図３の説明に戻る。図３に示すスケジュールサービスリクエスト取得手段３２１は、スケジュールサービス定義情報設定手段３１１で設定され、スケジュールサービス定義情報テーブル３４１に登録された定義情報に従って、ウェブブラウザ１１１から内部スケジュールサービス利用に該当する通信内容を特定する。ここでは、ＨＴＴＰリクエストデータに含まれるリクエストＵＲＬがリクエスト条件に設定されているＵＲＬに合致するか、また、そのＨＴＴＰリクエストデータ中にリクエスト条件に設定されているパラメータ値が設定されているかを判定することで、どのスケジュールサービス定義情報に該当するかを特定することになる。

リクエスト解析手段３２２は、スケジュールサービスリクエスト取得手段３２１で特定した内部スケジュールサービスの利用のための通信に含まれる、スケジュールイベント情報の管理ＩＤ、開始年、開始月、開始時間・・・・終了分、内容等の情報をリクエスト定義情報テーブル３４２に設定されている当該内部スケジュールサービスに対応するリクエスト定義情報に従って取得し、取得したそれらスケジュールイベント情報をスケジュールイベントテーブル３４４に設定する。スケジュールイベントテーブルについては、図２１を参照して説明する。

図２１は、本発明で用いるスケジュールイベントテーブルの一例を示す図である。図２１のように、スケジュールイベントテーブルは、それぞれのイベントＩＤに対応する、内部/外部、サービスＩＤ、管理ＩＤ、開始年、開始月、開始日、開始時、開始分、終了年、終了月、終了日、終了時、終了分、内容、内外対応がセットで関連付けられている。

外部リクエスト生成・送信手段３２３は、スケジュールサービスリクエスト取得手段３２１が取得したＨＴＴＰリクエストデータが合致したリクエスト定義情報の処理定義１９０７が設定されている場合に、ウェブブラウザ１１１から外部ＨＴＴＰサーバに送信される同期処理の対象となる外部スケジュールサービスに対するスケジュールデータ操作のためのＨＴＴＰリクエストデータを前記リクエスト解析手段３２２で取得し、スケジュールイベントテーブル３４４に設定されたスケジュールデータと、対応する外部スケジュールサービスの同一アクションのリクエスト定義情報とに従って、外部ＨＴＴＰサーバ１０５に対するＨＴＴＰリクエストデータを生成し、送信する。その際に、イベント内容書換え設定がなされている場合には、書換えルールテーブルに設定されている書換えルールに従った文字列変換を行ったうえで、外部ＨＴＴＰサーバ１０５に送信するＨＴＴＰリクエストデータを生成することになる。

同期状態確認手段３３１は、クライアント装置１０１を操作するユーザから、内部ＨＴＴＰサーバ１０４が提供するスケジュールサービスに登録されている当該ユーザのスケジュール情報と、同期処理の対象となる外部スケジュールサービスに登録されているデータとの同期処理の実行指示の入力を受け付ける。

内部・外部スケジュール取得手段３３２は、スケジュールサービス定義情報テーブル３４１とリクエスト定義情報テーブル３４２に登録された情報に従い、内部スケジュールサービスと外部スケジュールサービスにイベント取得リクエスト（リクエスト定義情報テーブルに設定されているアクションがＬＩＳＴのリクエスト定義情報に対応するリクエスト）を送信し、取得したイベントをスケジュールイベントテーブル３４４に登録する。

スケジュール差分解析手段３３３は、スケジュールイベントテーブル３４４に登録されている内部ケジュールサービスに設定されているスケジュール情報と、同期対象となる外部スケジュールサービスに設定されているスケジュール情報との差異を抽出する。

内部・外部リクエスト生成・送信手段は、スケジュール差分解析手段３３３で抽出した差異を解消するために、内部スケジュールサービスにのみ登録され、外部スケジュールサービスには登録されていないイベント（差分イベント）を当該外部スケジュールサービスに登録するために、ＨＴＴＰリクエストデータを生成し、外部ＨＴＴＰサーバ１０５に送信する。具体的には外部リクエスト生成送信手段３２３と同様の手法でＨＴＴＰリクエストデータを生成し、該当する外部ＨＴＴＰサーバ１０５に対して送信することになる。

また、差分イベントを削除することで同期処理を行う場合には、内部スケジュールサービスに登録されている差分イベントを削除を要求するためのＨＴＴＰリクエストデータを生成し、内部ＨＴＴＰサーバ１０２に対して送信することになる。内部ＨＴＴＰサーバ１０２に対するＨＴＴＰリクエストデータの作成は、内部スケジュールサービスのリクエスト定義情報を参照するほかは外部スケジュールサービスに対するＨＴＴＰリクエストデータを生成する場合と同様の処理を行うことになる。

次に図４を参照して、クライアント装置１０１にインストールされた拡張機能１１２が起動時に行う、ウェブブラウザ１１１の機能を拡張する処理について説明する。この処理は、クライアント装置１０１のＣＰＵ２０１によって行われる処理である。

まず、クライアント装置１０１の外部メモリ２１１にインストールされているウェブブラウザ１１１をユーザの指示等に応じて起動するとともに、拡張機能１１２も合わせて起動させ、拡張機能１１２の初期化処理を行う（ステップＳ４０１）。その後、ウェブブラウザ１１１の通信内容を監視するためにウェブブラウザ１１１の通信処理を補足するイベントリスナー登録を行う（ステップＳ４０２）。そして、このイベントリスナーを通じて、ウェブブラウザ１１１と内部ＨＴＴＰサーバ１０２との間で送受信される通信内容を拡張機能１１２が取得できるようになる。このような拡張機能を付加できるウェブブラウザとしては、例えば、ＦｉｒｅＦｏｘがある。

図５は、ウェブブラウザ１１１、拡張機能１１２、内部ＨＴＴＰサーバ１０２、及び外部ＨＴＴＰサーバ１０５間の通信と処理の順序の一例を示すシーケンス図である。

クライアント装置１０１でウェブブラウザ１１１が起動されると、それに応じて拡張機能１１２も起動され初期化処理が行われる（ステップＳ５０１）。この処理は図４のステップＳ４０１の処理に相当する。その後、ウェブブラウザの通信内容を補足するためのイベントリスナーの登録処理が行われる（ステップＳ５０２）。この処理は、図４のステップＳ４０２の処理に相当する。

その後、内部スケジュールサービスの利用を開始するために、内部ＨＴＴＰサーバ１０２に対して利用者を特定するための認証情報が送信される（ログイン：ステップＳ５０３）。通常は、利用者アカウント名と、パスワードが用いられる。そして、内部ＨＴＴＰサーバ１０２による（他の認証装置が行う場合もある）認証処理により利用者が特定できた場合には、図６に示すような画面をクライアント装置１０１のディスプレイ装置２１０に表示させるべく、内部ＨＴＴＰサーバ１０２はクライアント装置１０１に対して当該利用者のスケジュール情報を含む画面情報を送信する（ステップＳ５０４）。画面情報を取得したクライアント装置１０１は、当該画面情報に基づき図６のような画面表示を行う。

図６は、内部ＨＴＴＰサーバ１０２での認証処理後にクライアント装置１０１のディスプレイ装置２１０に表示されるウェブブラウザ１１１の画面の一例を示す模式図である。図に示すようなカレンダー形式で、既に登録されているスケジュール情報を確認可能な画面になっている。そして、スケジュール情報へのリンク（図中６０１）をクリックすることにより、イベント取得のためのＨＴＴＰリクエストデータが内部ＨＴＴＰサーバ１０２に対して送信される（ステップＳ５０５）。そして、拡張機能１１２はこのＨＴＴＰリクエストデータを補足して、ＨＴＴＰリクエストデータを解析する（ステップＳ５０６）。そして、その後、ＨＴＴＰリクエストデータに対する内部ＨＴＴＰサーバ１０２からのレスポンスデータが内部ＨＴＴＰサーバ１０２に対して（より具体的には、内部ＨＴＴＰサーバ１０２のウェブブラウザ１１１）送信される（ステップＳ５０７）拡張機能１１２はこのレスポンスデータ補足し（ステップＳ５０８）、イベント情報を解析し、スケジュールイベントテーブルに情報を記録する。

このレスポンスデータを受信したウェブブラウザ１１１は、図７で示されるように、そのイベントの詳細情報である開始年月日時分、終了年月日時分、予定内容、場所などの詳細情報をウェブブラウザ１１１の表示領域に表示する。尚、図６の６０２（予定が登録されていないリンク）をクリック指示した場合には、図７には初期データとして開始年月日、終了年月日のみが表示される。

ウェブブラウザ１１１が実行されているクライアント装置１０１で、ユーザの操作に基づきスケジュール情報の追加、スケジュール情報の変更、スケジュール情報の削除等のスケジュール情報の操作要求を受け付けた場合、その要求に応じて、ウェブブラウザ１１１は操作内容（追加、変更、削除等）にＨＴＴＰリクエストデータを生成し、内部ＨＴＴＰサーバ１０２に対して送信する（ステップＳ５０９）。拡張機能１１２は、このＨＴＴＰリクエストデータの取得・解析を行い、解析結果をスケジュールイベントテーブル３４４に登録する（ステップＳ５１０）。

そして、ステップＳ５０９の処理で内部ＨＴＴＰサーバ１０２に対して送信されたＨＴＴＰリクエストデータに対するレスポンスデータを、受け付ける（ステップＳ５１１）。このリクエストデータが、処理成功を示すレスポンスデータであった場合には、拡張機能１１２は、スケジュール情報の追加、変更、削除等の操作指示を行った内部スケジュールサービスと同期をとる外部スケジュールサービスが設定されている場合（当該内部スケジュールサービス、操作内容に該当するアクションに対応するリクエスト定義情報の処理定義１９０７に同期サービスが設定されている場合）に対応する外部スケジュールサービスのスケジュールサービス定義情報のアカウント１８０５、パスワード１８０６に設定されている情報を用いて外部スケジュールサービスへのログイン処理の要求を行う（ステップＳ５１２）。そして、そのログイン処理要求の結果、ログインに成功したというレスポンスデータを取得すると（ステップＳ５１３）、拡張機能１１２は、スケジュールイベントテーブル３４２に登録した内部スケジュールサービスに対する操作内容に従った外部スケジュールサービスに対するスケジュール情報の操作を行うために、外部スケジュールサービスに対するＨＴＴＰリクエストデータを生成し（ステップＳ５１４）、そのＨＴＴＰリクエストデータを外部ＨＴＴＰサーバ１０５に対して送信する（ステップＳ５１５）。尚、ステップＳ５１４では、拡張機能１１２は、外部スケジュールサービスに対するＨＴＴＰリクエストデータを作成する際には、当該外部スケジュールサービスのリクエスト定義情報に従ってＨＴＴＰリクエストデータを作成することになる。

次に、図８を参照して、クライアント装置１０１のＣＰＵ２０１によって行われる外部スケジュールサービス連携処理の手順の一例について説明する。この処理は、外部スケジュールサービス連携部３２０によって行われる。この機能は拡張機能１１２により提供されるものである。図８に従った処理を開始する時点では、クライアント装置１０１は内部スケジュールサービスが提供するウェブページに既にアクセスしており、イベントの取得、追加、修正、削除などの指示が可能な状態にある。

まず、ＣＰＵ２０１は、ウェブブラウザ１１１が生成し、内部ＨＴＴＰサーバ１０２に対して送信するＨＴＴＰリクエストデータの補足を行う（ステップＳ８０１）。ステップＳ８０１でＨＴＴＰリクエストデータを補足した場合には、スケジュールサービス定義情報テーブル３４１を検索し、ＨＴＴＰリクエストデータに設定されているリクエストＵＲＬが何れかのスケジュールサービス定義情報のＵＲＬ１８０３に合致するかを判定することにより、スケジュールサービス向けのＨＴＴＰ通信であるかを判定する（ステップＳ８０３）。

ＣＰＵ２０１が、スケジュールサービス向けのＨＴＴＰ通信であると判定した場合には（ステップＳ８０３でＹＥＳ）、処理をステップＳ８０４に、スケジュールサービス向けではないと判定した場合には（ステップＳ８０３でＮＯ）、処理をステップＳ８０１に移行させる。

ステップＳ８０３の判定処理でＹＥＳと判定された場合には、ＣＰＵ２０１は、取得したＨＴＴＰリクエストデータの解析処理を行う（ステップＳ８０４）。その際には、上記のステップＳ８０１で取得したＨＴＴＰリクエストデータをさらに構成要素（以降の処理で参照する各要素）に分解する。すなわち、例えば、リクエストパラメータ値については、アンパサンド記号を区切り文字としてトークンに分解し、さらに各トークンについては、＝を区切り文字とする名前−値のペアに分解する。また、外部送信データがある場合は、Content-TypeヘッダやContent-LengthまたはTransfer-Encodingヘッダの内容に基づき、リクエストボディの内容も解析し、構成要素に分解する。

その後、ステップＳ８０４で解析されたＨＴＴＰリクエストデータの構成要素に基づき、当該ＨＴＴＰリクエストデータが、リクエスト定義情報テーブル３４２に設定されているステップＳ８０２で特定した内部スケジュールサービスのＧＥＴアクション条件に一致するものであるかを判定する（ステップＳ８０５）。ステップＳ８０５でＣＰＵ２０１がＹＥＳと判定した場合には、ステップＳ８０６に処理を進め、イベント記録処理（詳細は図９に示す）を行う。一方ＧＥＴアクション条件に一致しないと判定した場合には（ステップＳ８０５でＮＯ）、次のステップＳ８０７に処理を進める。

ステップＳ８０７では、ＣＰＵ２０１は、当該ＨＴＴＰリクエストデータが、内部スケジュールサービスのＡＤＤアクション条件に一致するものであるかを判定する。ステップＳ８０７でＣＰＵ２０１がＹＥＳと判定した場合には、ステップＳ８０９に処理を進め、スケジュール追加・変更処理（詳細は図１０に示す）を行う。一方、ＡＤＤアクション条件に一致しないと判定した場合には（ステップＳ８０７でＮＯ）、次のステップＳ８０８に処理を進める。

ステップＳ８０８では、ＣＰＵ２０１は、当該ＨＴＴＰリクエストデータが、内部スケジュールサービスのＥＤＩＴアクション条件に一致するものであるかを判定する。ステップＳ８０８でＣＰＵ２０１がＹＥＳと判定した場合には、ステップＳ８０９に処理を進め、スケジュール追加・変更処理（詳細は図１０に示す）を行う。一方、ＥＤＩＴアクション条件に一致しないと判定した場合には（ステップＳ８０８でＮＯ）、次のステップＳ８１０に処理を進める。

ステップＳ８１０では、ＣＰＵ２０１は、当該ＨＴＴＰリクエストデータが、内部スケジュールサービスのＤＥＬＥＴＥアクション条件に一致するものであるかを判定する。ステップＳ８１０でＣＰＵ２０１がＹＥＳと判定した場合には、ステップＳ８１１に処理を進め、スケジュール削除処理（詳細は図１１に示す）を行う。一方、ＥＤＩＴアクション条件に一致しないと判定した場合には（ステップＳ８１０でＮＯ）、次のステップＳ８１２に処理を進める。

以上の処理を、ウェブブラウザ１１１が終了された（ステップＳ８１２でＹＥＳ）と判断するまで繰り返すことになる。以上が、クライアント装置１０１のＣＰＵ２０１によって行われる外部スケジュールサービス連携処理の手順の一例である。

次に、図９を参照して、図８のステップＳ８０６のイベント記録処理の詳細について説明する。

図９は、クライアント装置１０１のＣＰＵ２０１によって行われるイベント記録処理の一例を示すフローチャートである。まず、ＣＰＵ２０１は、ステップＳ９０１で、図８のステップＳ８０４のＨＴＴＰリクエストデータ解析処理の結果得られたＨＴＴＰリクエストデータの構成要素のうち、管理ＩＤ（例えば、ｓｉｄ＝Ｅ１１１）を取り出したうえで、処理をステップＳ９０２に移行する。

その後、ＨＴＴＰリクエストデータに対するレスポンスデータを受信した（ステップＳ９０３でＹＥＳ）と判定するまでレスポンスデータの待ち状態を継続する（ステップＳ９０２）。

内部ＨＴＴＰサーバ１０２よりレスポンスデータを受け付けると（ステップＳ９０３でＹＥＳ）、内部スケジュールサービスのＧＥＴアクションに対応するリクエスト定義情報を取得する（ステップＳ９０４）。

その後、ＣＰＵ２０１は、ステップＳ９０３で取得したと判定したイベント内容を示すレスポンスデータをＨＴＭＬのＤＯＭ要素に分解し、ステップＳ９０４で取得したリクエスト定義情報に従ってスケジュールイベントの開始年月日時分、終了年月日分、スケジュール内容など、スケジュールイベント項目に対応するデータを取得する。例えば、ＨＴＭＬのテキスト表示エリア“id＝startyear”に当該スケジュールイベントの開始年が設定されている場合には、そのＤＯＭ要素の値をスケジュールイベント項目の開始年に対応付ける。また、スケジュールサービスによっては、ひとつのＤＯＭ要素に“ＹＹＹＹ／ＭＭ／ＤＤ”のように、開始年が部分文字列として設定されている場合もあるが、このような場合は、該当ＤＯＭ要素の部分列（例えば、１桁目から２文字）を開始年として取得できるようレスポンスデータ定義情報のレスポンスデータ定義を設定しておけばよい。

次に、ステップＳ９０６でスケジュールイベントテーブル３４４（図２１に示す）に同一内容のスケジュールイベントデータがあるかを検索する（ステップＳ９０６）。検索の結果、同一のスケジュールイベントデータがない、つまりは新規のスケジュールイベントであると判定した場合には、処理をステップＳ９０８に進め、スケジュールイベントテーブル３４４に当該スケジュールイベントデータを追加し、本処理を終了する。ステップＳ９０７でＮＯ（新規のスケジュールイベントではない）と判定した場合には、ステップＳ９０８のスケジュールイベントの追加処理を行うことなく、本処理を終了する。以上が、図８のステップＳ８０６のイベント記録処理の詳細説明である。

次に、図１０を参照して、図８のステップＳ８０９のスケジュール追加・変更処理の詳細について説明する。

図１０は、クライアント装置１０１のＣＰＵ２０１によって行われるスケジュール追加・変更処理の詳細を示すフローチャートである。まず、ＣＰＵ２０１は、ステップＳ１００１で、図８のステップＳ８０４のＨＴＴＰリクエストデータ解析処理の結果得られたＨＴＴＰリクエストデータの構成要素のうち、管理ＩＤ（例えば、ｓｉｄ＝Ｅ１１１）を取り出したうえで、処理をステップＳ１００２に移行する。

その後、ＨＴＴＰリクエストデータに対するレスポンスデータを受信した（ステップＳ１００３でＹＥＳ）と判定するまでレスポンスデータの待ち状態を継続する（ステップＳ１００２）。

内部ＨＴＴＰサーバ１０２より、スケジュール操作正常終了を示すレスポンスデータを受け付けると（ステップＳ１００３でＹＥＳ）、内部スケジュールサービスの該当するアクション（ＡＤＤ、若しくはＥＤＩＴ）に対応するリクエスト定義情報を取得し、リクエスト定義情報のリクエストパラメータ定義１９０５に従って、図８のステップＳ８０４で解析されたＨＴＴＰリクエストデータの構成要素から、スケジュールイベントデータの開始年月日時分、終了年月日時分、スケジュール内容等のスケジュールイベント項目に対応するデータを取得する（ステップＳ１００４）。スケジュールサービスによっては、ひとつのリクエストパラメータ値に“ＹＹＹＹ／ＭＭ／ＤＤ”の様に、開始年が部分文字列として指定されている場合もある。このような場合は、該当パラメータ値の部分列（例えば、１桁目から２文字）を開始年として取得できるようリクエストパラメータ定義の条件を設定しておけばよい。

そしてその後、ステップＳ１００４で生成したスケジュールイベントデータが既にスケジュールイベントテーブルに登録されているかを検索する（ステップＳ１００５）。検索の結果、同一のスケジュールイベントテーブルが登録されていない、即ち新規のスケジュールイベントデータであると判定した場合には（ステップＳ１００６でＹＥＳ）、処理をステップＳ１００７に進め、当該スケジュールイベントデータをスケジュールイベントテーブル３４４に登録する。

ステップＳ１００７の処理終了後、若しくはステップＳ１００６でＮＯと判定されたのち、ＣＰＵ２０１は処理をステップＳ１００８に進め、対応外部イベント検索処理を行うことになる。この処理の詳細については図１２を参照して後述することにする。

ステップＳ１００８の対応外部イベント検索処理終了後、ＣＰＵ２０１は、外部スケジュールサービスに当該スケジュールイベントデータに対応するスケジュールイベントデータが登録されているか（対応イベントがあるか）を判定する（ステップＳ１００９）。ステップＳ１００８の判定処理で対応イベントありと判断した場合（ステップＳ１００９でＹＥＳ）、処理をステップＳ１０１０に進め、同期対象となる外部スケジュールサービスのリクエスト定義情報のうち、ＥＤＩTアクションのリクエスト定義情報を取得する。一方、ステップＳ１００９の判定処理でＮＯと判定した場合（対応イベントなし）、処理をステップＳ１０１１に進め、同期対象となる外部スケジュールサービスのリクエスト定義情報のうち、ＡＤＤアクションのリクエスト定義情報を取得する。

その後、スケジュール内容の書換えを行うと設定されている場合には、書換えルールに従った文字列の変換処理を行う（ステップＳ１０１２）。書換えルールに従った書換え処理を行わない設定がされている場合には、本処理は行わない。

ステップＳ１０１２の処理が終了後、ステップＳ１０１０若しくはＳ１０１１で取得したリクエスト定義情報のリクエスト条件に従って外部スケジュールサービスのスケジュール情報の操作のために用いる外部ＨＴＴＰリクエストデータを生成し（ステップＳ１０１３）、当該外部スケジュールサービスを提供する外部ＨＴＴＰサーバに対して送信する（ステップＳ１０１４）。

そしてその後、外部ＨＴＴＰサーバ１０５より処理成功を示すレスポンスデータを取得すると（ステップＳ１０１５でＹＥＳ：成功）、処理をステップＳ１０１６に進め、ステップＳ１０１４でＨＴＴＰリクエストデータを外部スケジュールサービスに送信したことでと外部スケジュールサービスに登録されたスケジュールイベントをイベントテーブルに追加・若しくは更新する（該当エントリ更新）。以上が、図８のステップＳ８０９のスケジュール追加・変更処理の詳細である。

次に、図１１を参照して、図８のステップＳ８１１のスケジュール削除処理の詳細について説明する。

図１１は、クライアント装置１０１のＣＰＵ２０１によって行われる、スケジュール削除処理の一例を示すフローチャートである。まず、ＣＰＵ２０１は、ステップＳ１１０１で図８のステップＳ８０４のＨＴＴＰリクエストデータ解析処理の結果得られたＨＴＴＰリクエストデータの構成要素のうち、管理ＩＤ（例えば、ｓｉｄ＝Ｅ１１１）を取り出したうえで、処理をステップＳ１１０２に移行する。

その後、ＨＴＴＰリクエストデータに対するレスポンスデータを受信した（ステップＳ１１０３でＹＥＳ）と判定するまでレスポンスデータの待ち状態を継続する。

内部ＨＴＴＰサーバ１０２より、スケジュール操作正常終了を示すレスポンスデータを受け付けると（ステップＳ１１０３でＹＥＳ）、ステップＳ１１０１で取得した管理ＩＤを用いてスケジュールイベントテーブル３４２を検索する（ステップＳ１１０４）。そして当該スケジュールイベントデータが新規イベントであるかを判定し（ステップＳ１１０５）、新規イベントである（ステップＳ１１０５でＹＥＳ）場合には本処理を終了する。

ステップＳ１１０５で新規イベントではないと判定した場合には、処理をステップＳ１１０６へ進め、対応外部イベント検索処理を行う。この処理の詳細については、図１２を参照して後述する。

ステップＳ１１０６の処理終了後、対応外部イベントがあるとＣＰＵ２０１が判定した場合には（ステップＳ１１０７でＹＥＳ）、リクエスト定義情報テーブル３４２から対応外部スケジュールサービスのＤＥＬＥＴＥアクションのリクエスト定義情報を取得する（ステップＳ１１０８）。そして、取得したリクエスト定義情報のリクエスト条件１９０４に従って当該外部スケジュールサービスで管理されているスケジュール情報を削除するためのＨＴＴＰリクエストデータを生成し（ステップＳ１１０９）、生成したＨＴＴＰデータを外部ＨＴＴＰサーバ１０５に対して送信する（ステップＳ１１１０）。

そして、その後削除処理が終了した旨のレスポンスデータを取得すると（ステップＳ１１１１でＹＥＳ）、処理をステップＳ１１１２に移行させ、外部スケジュールサービスから削除したスケジュールイベントをスケジュールイベントテーブルから削除する（ステップＳ１１１２）。以上が、以上が、図８のステップＳ８１１のスケジュール削除処理の詳細説明である。

次に、図１２を参照して図１０のステップＳ１００８及び図１１のステップＳ１１０６の対応外部イベント検索処理の詳細について説明する。

図１２は、クライアント装置１０１のＣＰＵ２０１によって行われる対応外部イベント検索処理の一例を示すフローチャートである。まず、ＣＰＵ２０１は、既に外部イベントを取得済みであるかを判定する（ステップＳ１２０１）。既に取得済みであると判定した場合には、後述する処理を行うことなく本処理を終了する。

一方、ステップＳ１２０１で外部イベントを取得済みでない（即ち外部イベントを取得していない：ＮＯ）と判定した場合は、処理をステップＳ１２０２に進め、既に外部スケジュールサービスにログインしているかを判定する。外部スケジュールサービスにログイン済みであると判定した場合には（ステップＳ１２０２でＹＥＳ）、処理をステップＳ１２０７に移行させる。一方、まだログインしていないと判定した場合には（ステップＳ１２０２でＮＯ）、処理をステップＳ１２０３に進め、スケジュールサービス定義情報テーブル３４１から当該外部スケジュールサービスの定義情報の認証情報（アカウント名１８０５、パスワード１８０６）を取得する。その後、取得した認証情報を用いてユーザ認証を行うために用いるＨＴＴＰリクエストデータ（認証情報）を生成し、生成した認証情報を外部ＨＴＴＰサーバ１０５に対して送信する（ステップＳ１２０４）。

その後、ログインに成功したか否かを判定し（ステップＳ１２０５）、ログインに失敗した場合には（ステップＳ１２０５でＮＯ）、処理をステップＳ１２０６に進め、エラー情報をディスプレイ装置２１０に出力し、本処理を終了する。一方、ログインに成功した場合には（ステップＳ１２０５でＹＥＳ）、処理をステップＳ１２０７に進め、イベントＬＩＳＴ取得処理を行う。本処理の詳細については図１３を参照して後述する。

ステップＳ１２０７のイベントＬＩＳＴ取得処理終了後、ステップＳ１２０７のＬＩＳＴ取得処理でスケジュールイベントテーブルに登録した外部スケジュールイベントデータに対して、ステップＳ１２０８からＳ１２１２の処理を行う。まず、ステップＳ１２０９において、外部スケジュールイベント情報を１件取得する。そして、ステップＳ１２０９で取得した外部スケジュールイベントデータの開始年月日時分、及び終了年月日時分と一致する内部スケジュールイベントデータがあるかを判定する（ステップＳ１２１０）。内部スケジュールイベントデータがあると判定した場合には、ステップＳ１２０９で取得した外部スケジュールイベントデータ及び当該外部スケジュールイベントデータと開始・終了年月日時分を同じである内部スケジュールイベントデータの対応付けを行うために、それぞれのレコードの対応イベント項目に対応するスケジュールイベントのイベントＩＤをセットする（ステップＳ１２１１）。そして、この処理をすべての外部スケジュールイベントデータに対して行う。以上が、対応外部イベント検索処理の詳細である。この処理を行うことで、図２１に示すスケジュールイベントテーブルに登録されている内部スケジュールイベントデータと外部スケジュールイベントデータとの対応付けを行うことが可能となる。

次に、図１３を参照して、図１２のステップＳ１２０７のイベントＬＩＳＴ取得処理の詳細について説明する。

図１３は、クライアント装置１０１のＣＰＵ２０１によって行われるイベントリスト処理の一例を示すフローチャートである。まず、ＣＰＵ２０１はステップＳ１３０１において、リクエスト定義情報テーブル３４２から、外部スケジュールサービスに対するＬＩＳＴアクションに対応するリクエスト定義情報を取得する。そして、ＬＩＳＴ取得の当月から予め設定したＮカ月分のイベントの取得リクエストを送信し、ステップＳ１３０３に処理を進め、レスポンスデータを待つ。

ステップＳ１３０３では、例えば図６の様に、１カ月分のイベント情報が表形式で表示されるＨＴＭＬレスポンスデータが得られる。１ページに１カ月分のデータの表示しかできない場合は、Ｎカ月分のデータを得るために、これをＮ回繰り返すよう処理を構成してもよい。また、指定期間のイベントデータがＣＳＶなど一覧リスト形式で取得できるページがある場合は、そのページへのリクエストデータを送信するようなリクエスト定義情報を設定してもよい。

次にステップＳ１３０４で、ＣＰＵ２０１がレスポンスデータの取得に成功したと判定した場合には（ステップＳ１３０４でＹＥＳ）、ステップＳ１３０５に処理を進める。一方ステップＳ１３０４で成功しなかった（即ち失敗した：ＮＯ）と判定した場合には、後述する処理を行うことなく、本処理を終了する。

その後、ＣＰＵ２０１は取得したレスポンスデータの各イベント情報１件毎に以下Ｓ１３０５〜Ｓ１３１４の処理を繰り返す。取得したレスポンスデータが、例えば図６のようなＨＴＭＬ形式の場合は、各スケジュールイベントの詳細情報に対するリンクが含まれる。そのリンクをクリックすると、例えば図７のように詳細情報が表示される。取得したレスポンスデータがＣＳＶ形式の場合は１行ごとにイベントの詳細情報が含まれる。

ステップＳ１３０６では、各イベントの詳細情報を取得するためにＨＴＭＬ上の各イベントのリンクをクリックするのと同様の要求をＨＴＴＰサーバ（内部ＨＴＴＰサーバ１０２若しくは外部ＨＴＴＰサーバ１０５）に対して送信するため、処理対象となるスケジュールサービスのＧＥＴアクションに対応するリクエスト定義情報をリクエスト定義情報テーブル３４２から取得する。リンク情報に含まれるリクエストパラメータから管理ＩＤ（例えば、ｓｉｄ＝Ｅ１１１）を取り出した上で、ステップＳ１３０７に処理を進め、ＧＥＴアクションを行うためのＨＴＴＰリクエスト生成し、をＨＴＴＰサーバに送信する。

ステップＳ１３０７でリクエストデータを送信したら、ステップＳ１３０８に処理を進めＨＴＴＰサーバからのレスポンスデータを待つ。レスポンスデータは、例えば図７のようなＨＴＭＬとして得られる。

ステップＳ１３０９でＣＰＵ２０１はレスポンスデータの取得に成功したかを判定する。正常にレスポンスデータが得られた場合、つまりステップＳ１３０９で「ＹＥＳ」の場合は次のステップＳ１３１０に処理を進める、一方、例えばＨＴＴＰサーバからエラー応答や、一定時間応答が無いタイムアウトが発生した場合、つまり、ステップＳ１３１０で「ＮＯ」の場合は本処理を終了する。

ステップＳ１３１０では、Ｓ１３０８で解析されたリクエスト構成要素から、イベント情報の開始年月日時分、終了年月日時分、イベント内容などイベント項目に対応するデータを取得する。例えば、リクエストパラメータのｓｔａｒｔｙｅａｒ値に開始年が対応付けられている場合は、その値をイベント項目の開始年に対応付ける。またＷｅｂ電子スケジュールサービスによっては、ひとつのリクエストパラメータ値に“ＹＹＹＹ／ＭＭ／ＤＤ”の様に、開始年が部分文字列として指定されている場合もある。このような場合は、該当パラメータ値の部分列（例えば、１桁目から２文字）を開始年として取得できるようリクエスト定義情報中のリクエストパラメータを設定すれば良い。

次にステップＳ１３１１でスケジュールイベントテーブル３４４を検索し、ステップＳ１３１２に処理を進める。そして、既にスケジュールイベントテーブル３４４に登録済みのイベントに一致しない新規イベントであると判定した場合、つまりステップＳ１３１２でＹＥＳと判定した場合は、ステップＳ１３１３に処理を進め、スケジュールイベントテーブル３４４に新規スケジュールイベントデータとして登録する。一方、ステップＳ１３１２でＮＯとＣＰＵ２０１が判定した場合には、ステップＳ１３１４に処理を進め、取得したレスポンスデータの各スケジュールイベント情報、１件毎に以下Ｓ１３０５〜Ｓ１３１４の処理を繰り返す。

ステップＳ１３１４では、取得したすべてのイベントの繰り返しが終了すれば本処理を終了する。以上が、イベントＬＩＳＴ取得処理の説明である。

最後に、図１４を参照して本発明における外部サービス同期処理について説明する。この外部サービス同期処理は、前述の外部サービス連携処理に拠らず、外部スケジュールサービスを直接更新した場合や、内部スケジュールサービスだけが更新された場合に、それらサービス間のイベント情報の不一致を解消するための手段である。

図１４は、クライアント装置１０１のＣＰＵ２０１によって行われる外部サービス同期処理の一例を示すフローチャートである。尚、同図のフローチャートに従った処理を開始する時点では、クライアント装置１０１のウェブブラウザ１１１は内部ＨＴＴＰサーバ１０２のＷｅｂ電子スケジュールサービスページにアクセスしており、イベントの取得、更新、削除などを指示可能な状態にある。

まず、ＣＰＵ２０１は、ステップＳ１４０１において、クライアント装置１０１を操作するユーザからの同期実行指示を待つ。クライアント装置１０１のディスプレイ装置２１０上でウェブブラウザのメニューをクリック指示するなどすることにより、拡張機能１１２に同期実行指示を与えることができる。拡張機能１１２が同期実行指示を受信したらステップＳ１４０２に処理を進める。

ステップＳ１４０２では、内部スケジュールサービスに対するＬＩＳＴアクションをリクエスト定義情報テーブル３４２より検索し、検索の結果得られたリクエストパラメータ定義１９０５に従ったＨＴＴＰリクエストデータを内部ＨＴＴＰサーバ１０２に送信することによりイベントリストを取得し、スケジュールイベントテーブルに登録する。尚、イベントＬＩＳＴの取得方法は図１３で説明した手順で、内部ＨＴＴＰサーバ１０２に対して行う。

次に、ステップＳ１４０３では、外部ＨＴＴＰサーバ１０５に対する不一致イベントを検出するために、図１２で説明した対応外部イベント検索処理を行い、内部スケジュールサービスに登録されているスケジュールイベントと外部スケジュールサービスに登録されているスケジュールイベントとの対応付けを行う。

その後、ＣＰＵ２０１は、スケジュールイベントテーブル３４４に登録されているスケジュールイベントデータ１件ごとに、ステップＳ１４０４〜Ｓ１４２０の処理を繰り返し行うことになる。

ＣＰＵ２０１は、ステップＳ１４０５において、スケジュールイベントテーブル３４４の対応イベントデータに従って、対応イベントがあるかを判定する。対応イベントがある判断した場合は（ステップＳ１４０５でＹＥＳ）、ステップＳ１４２０に処理を進め、スケジュールイベントテーブルの次のスケジュールイベントデータに対して本処理を繰り返し行う。一方、対応イベントがないと判定した場合（ステップＳ１４０５でＮＯ）、ステップＳ１４０６に処理を進める。

ステップＳ１４０６ではクライアント装置１０１のディスプレイ装置２１０に不一致スケジュールイベントの情報と、同期または削除の指示入力を受け付ける不図示の画面を表示する。例えば、外部スケジュールサービスには存在するが、内部スケジュールサービスには存在しないスケジュールイベントデータや、逆に内部スケジュールサービスには存在するが、外部スケジュールサービスには存在しないスケジュールイベントデータを表示する。

その後、ステップＳ１４０７では、利用者の解決方法を受け付けるため、解決指示を待つ。ユーザは一方にだけ存在するイベントを他方にも追加するための同期を指示できる。または、一方にだけ存在するイベントを削除することも指示できる。そのような不一致イベントに対して１件ずつ利用者の解決方法を指示を選択させることもできるが、予め解決方法を決めておいて不一致イベントを確認だけすることもできる。また、確認が不要であれば、解決指示を受けずに予め決めておいた解決方法ですべての不一致スケジュールイベントを一括で処理するようにしてももちろん構わない。

次に、ＣＰＵ２０１はユーザより受け付けた解決指示が同期であるかを判定する（ステップＳ１４０８）。同期指示であると判定した場合には（ステップＳ１４０８でＹＥＳ）、ステップＳ１４１５に処理を進める。一方、ステップＳ１４０８でＣＰＵ２０１がＮＯであると判定した場合はステップＳ１４０９に処理を進める。

ＣＰＵ２０１はステップＳ１４０８でＮＯであると判定した場合、ステップＳ１４０９で解決指示が削除であるかを判定する。受け付けた解決指示が削除であると判定した場合には（ステップＳ１４０９でＹＥＳ）、ステップＳ１４１０に処理を進める。一方、ステップＳ１４０９でＮＯと判定した場合には、ステップＳ１４２０に処理を進め、イベントテーブルのイベント１件ごとに、ステップＳ１４０４〜Ｓ１４２０のステップの処理を繰り返す。

ステップＳ１４１０以下の処理は、不一致イベントに対する削除の処理を行う。ステップＳ１４１０では、不一致となったイベントを保持するサービスＩＤに対する、リクエスト定義情報テーブル３４２を参照し、ＤＥＬＥＴＥリクエスト定義情報を取得する。

次にステップＳ１４１１で、不一致となったイベント情報の管理ＩＤをＤＥＬＥＴＥリクエストのパラメータに設定し、続くステップＳ１４１２でＨＴＴＰリクエストデータをＨＴＴＰサーバに対して送信する。

次にステップＳ１４１３でリクエストが成功した場合、つまりステップＳ１４１３で「ＹＥＳ」の場合は、ステップＳ１４１４に処理を進め、スケジュールイベントテーブル３４４から該当不一致イベント情報を削除する。一方、ステップＳ１４１３で「ＮＯ」の場合は、ステップＳ１４０４〜Ｓ１４２０のステップの処理を繰り返す。

ステップＳ１４１５以下では、不一致イベントに対する同期の処理を行う。ステップＳ１４１５では、不一致となったイベントを保持するサービスＩＤに対する、リクエスト定義情報テーブル３４２を参照し、他方のサービスである同期対象のサービスＩＤのＡＤＤリクエスト定義情報を取得する。

次にステップＳ１４１６で、不一致となったイベント情報の開始年、開始月などのイベント項目値をＡＤＤリクエストのパラメータに設定し、続くステップＳ１４１７でそのＨＴＴＰリクエストデータをＨＴＴＰサーバに対して送信する。このイベント送信時に図１０のステップＳ１０１２と同様にイベント内容の書換えを行っても良い。

次に、ステップＳ１４１８でリクエストが成功した場合、つまりステップＳ１４１８で「ＹＥＳ」の場合は、ステップＳ１４１９に処理を進め、イベントテーブルにリクエスト送信したイベント情報を追加する。一方、ステップＳ１４１８で「ＮＯ」の場合は、ステップＳ１４０４〜Ｓ１４２０のステップの処理を繰り返す。

以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。

１００ イントラネット
１０１−１乃至１０１−３ クライアント装置
１０２ 内部ＨＴＴＰサーバ
１０３ ローカルエリアネットワーク（ＬＡＮ）
１０４ 広域ネットワーク
１０５−１乃至１０５−３ 外部ＨＴＴＰサーバ
１１１ ウェブブラウザアプリケーション
１１２ 拡張機能アプリケーション
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＲＯＭ
２０４ システムバス
２０５ 入力コントローラ
２０６ ビデオコントローラ
２０７ メモリコントローラ
２０８ 通信Ｉ／Ｆ（インターフェース）コントローラ
２０９ キーボード
２１０ ディスプレイ装置
２１１ 外部メモリ

Claims (12)

1. スケジュール管理サービスを提供するサーバ装置と通信可能な情報処理装置であって、
   スケジュール管理サービスを提供する第１のサーバ装置に対して送信されるスケジュール管理に係る送信データである第１の送信データの構造を定義した第１の定義情報、及び、前記第１のサーバ装置とは異なる、スケジュール管理サービスを提供する第２のサーバ装置に対して送信されるスケジュール管理に係る送信データである第２の送信データの構造を定義した第２の定義情報を記憶する第１の記憶手段と、
   ブラウザアプリケーションで生成された送信データが前記第１のサーバ装置に対する前記第１の送信データであるかを判定する第１の判定手段と、
   前記第１の判定手段で、前記第１のサーバ装置に対する前記第１の送信データであると判定した後に、前記第１の定義情報で定義された前記第１の送信データの構造に従って、前記第１のサーバ装置に送信される前記第１の送信データからデータ内容を取得する第１の取得手段と、
   前記第１の取得手段で取得したデータ内容と、前記第２の定義情報とに従って、前記第２のサーバ装置に対して送信する前記第２の送信データを生成する生成手段と、
   前記生成手段で生成した前記第２の送信データを前記第２のサーバ装置に対して送信する送信手段と、
   を備えることを特徴とする情報処理装置。
2. 前記第１のサーバ装置に送信される前記第１の送信データに含まれる文字列情報のうち、前記生成手段により前記第２の装置サーバに送信される前記第２の送信データを作成する際に、文字列変換を行う文字列である変換前文字列とその変換後の文字列である変換後文字列とを対応付けて記憶する第２の記憶手段をさらに備え、
   前記第１の取得手段で取得した前記第１のサーバ装置に送信する前記第１の送信データのデータ内容に前記第２の記憶手段に記憶されている変換前文字列に合致する文字列が含まれている場合に、前記生成手段は、前記変換前文字列と対応付けられている変換後文字列を用いて前記第２のサーバに送信する前記第２の送信データを生成すること
   を特徴とする請求項１に記載の情報処理装置。
3. 前記第１の定義情報には、前記第１のサーバ装置に対するデータ操作イベントごとに前記第１の送信データのデータ構造が、前記第２の定義情報には、前記第２のサーバ装置に対するデータ操作イベントごとに前記第２の送信データのデータ構造該定義されており、
   前記第１の判定手段はさらに、前記ブラウザアプリケーションで生成された送信データ前記第１のサーバ装置に対するいずれのデータ操作イベントに対応する第１の送信データあるかを前記第１の定義情報に従って判定し、
   前記第１の取得手段は、前記第１の定義情報のうち、前記第１の判定手段で判定された前記第１のサーバ装置のデータ操作イベントに対応する定義情報に従って、前記第１のサーバ装置に送信される前記第１の送信データからデータ内容を取得し、
   前記生成手段は、前記第１の判定手段で判定されたデータ操作イベントに対応する前記第２の定義情報に従って前記第２のサーバ装置に対する前記第２の送信データを生成する
   ことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記第１の定義情報には、前記第１のサーバ装置に対するデータ取得イベントに係る送信データのデータ構造及び前記データ取得イベントに応じて第１のサーバ装置より送信されるレスポンスデータのデータ構造が含まれ、
   前記第２の定義情報には、前記第２のサーバ装置に対するデータ取得イベントに係る送信データのデータ構造及び前記データ取得イベントに応じて第２のサーバ装置より送信されるレスポンスデータのデータ構造が含まれ、
   前記第１のサーバ装置及び前記第２のサーバ装置で管理されているスケジュール情報を取得する第２の取得手段と、
   前記第１の定義情報に含まれる前記レスポンスデータのデータ構造に従って、前記第１のサーバ装置で管理されているスケジュール情報を、前記第２の定義情報に含まれる前記レスポンスデータのデータ構造に従って、前記第２のサーバ装置で管理されているスケジュール情報を取得し、取得したそれぞれのスケジュール情報の対応付けを行う対応付け手段と、
   前記前記対応付け手段で対応付けられた前記第１のサーバ装置で管理されているスケジュール情報と前記第２のサーバ装置で管理されているスケジュール情報との対応関係を記憶する第３の記憶手段と、
   を備えることを特徴とする請求項３に記載の情報処理装置。
5. 前記データ操作イベントには、スケジュール情報の編集及び削除が含まれ、
   前記第１の判定手段で、データ操作イベントがスケジュール情報の編集若しくはスケジュール情報の削除であると判定された後に、当該データ操作イベントの対象となる第１のサーバ装置で管理されているスケジュール情報に対応する第２のサーバ装置のスケジュール情報が前記第３の記憶手段に記憶されているかを判定する第２の判定手段と、
   をさらに備え、
   前記第２の判定手段で、前記第１のサーバ装置で管理されているスケジュール情報に対応する第２のサーバ装置のスケジュール情報が記憶されていると判定した場合に、前記生成手段は、前記第１の判定手段で判定したデータ操作イベントに対応する前記第２の定義情報に従って、前記第２のサーバのスケジュール情報に対するデータ操作のための前記第２の送信データを生成すること
   を特徴とする請求項４に記載の情報処理装置。
6. 前記第１の判定手段で、前記データ操作がスケジュール情報の編集であると判定され、前記第２の判定手段で、前記データ操作イベントの対象となった第１のサーバ装置で管理されているスケジュール情報に対応する第２のサーバ装置のスケジュール情報が記憶されていないと判定した場合に、前記生成手段は、前記第２のサーバ装置に対する新規データの登録のための前記第２送信データを生成すること
   を特徴とする請求項５に記載の情報処理装置。
7. 前記第２の装置サーバにアクセスする際に使用する認証情報を記憶する第４の記憶手段をさらに備え、
   前記送信手段は、前記認証情報を用いて前記第２のサーバ装置にアクセスし認証を受け付けた後に、前記第２のサーバ装置に対して前記生成手段で生成した前記第２の送信データを送信する
   ことを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 前記第１のサーバ装置は内部ネットワークに、前記第２のサーバ装置は外部ネットワークに設置されているサーバ装置であること
   を特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
9. スケジュール管理サービスを提供する第１のサーバ装置に対して送信されるスケジュール管理に係る送信データである第１の送信データの構造を定義した第１の定義情報、及び、前記第１のサーバ装置とは異なる、スケジュール管理サービスを提供する第２のサーバ装置に対して送信されるスケジュール管理に係る送信データである第２の送信データの構造を定義した第２の定義情報を記憶する記憶装置を備える情報処理装置によって行われる情報処理方法であって、
   ブラウザアプリケーションで生成された送信データが前記第１のサーバ装置に対する前記第１の送信データであるかを判定する第１の判定工程と、
   前記第１の判定工程で、前記第１のサーバ装置に対する前記第１の送信データであると判定した後に、前記第１の定義情報で定義された前記第１の送信データの構造に従って、前記第１のサーバ装置に送信される前記第１の送信データからデータ内容を取得する第１の取得工程と、
   前記第１の取得工程で取得したデータ内容と、前記第２の定義情報とに従って、前記第２のサーバ装置に対して送信する前記第２の送信データを生成する生成工程と、
   前記生成工程で生成した前記第２の送信データを前記第２のサーバ装置に対して送信する送信工程と、
   を備えることを特徴とする情報処理方法。
10. 前記記憶装置にはさらに、前記第１のサーバ装置に送信される前記第１の送信データに含まれる文字列情報のうち、前記生成工程により前記第２の装置サーバに送信される前記第２の送信データを作成する際に、文字列変換を行う文字列である変換前文字列とその変換後の文字列である変換後文字列とが対応付けて記憶されており、
    前記第１の取得工程で取得した前記第１のサーバ装置に送信する前記第１の送信データのデータ内容に前記記憶装置に記憶されている変換前文字列に合致する文字列が含まれている場合に、前記生成工程は、前記変換前文字列と対応付けられている変換後文字列を用いて前記第２のサーバに送信する前記第２の送信データを生成すること
    を特徴とする請求項９に記載の情報処理方法。
11. スケジュール管理サービスを提供する第１のサーバ装置に対して送信されるスケジュール管理に係る送信データである第１の送信データの構造を定義した第１の定義情報、及び、前記第１のサーバ装置とは異なる、スケジュール管理サービスを提供する第２のサーバ装置に対して送信されるスケジュール管理に係る送信データである第２の送信データの構造を定義した第２の定義情報を記憶する記憶装置を備える情報処理装置を、
    ブラウザアプリケーションで生成された送信データが前記第１のサーバ装置に対する前記第１の送信データであるかを判定する第１の判定手段と、
    前記第１の判定手段で、前記第１のサーバ装置に対する前記第１の送信データであると判定した後に、前記第１の定義情報で定義された前記第１の送信データの構造に従って、前記第１のサーバ装置に送信される前記第１の送信データからデータ内容を取得する第１の取得手段と、
    前記第１の取得手段で取得したデータ内容と、前記第２の定義情報とに従って、前記第２のサーバ装置に対して送信する前記第２の送信データを生成する生成手段と、
    前記生成手段で生成した前記第２の送信データを前記第２のサーバ装置に対して送信する送信手段と、
    として機能させることを特徴とするコンピュータプログラム。
12. 前記記憶装置にはさらに、前記第１のサーバ装置に送信される前記第１の送信データに含まれる文字列情報のうち、前記生成手段により前記第２の装置サーバに送信される前記第２の送信データを作成する際に、文字列変換を行う文字列である変換前文字列とその変換後の文字列である変換後文字列とが対応付けて記憶されており、
    前記第１の取得手段で取得した前記第１のサーバ装置に送信する前記第１の送信データのデータ内容に前記記憶装置に記憶されている変換前文字列に合致する文字列が含まれている場合に、前記生成手段は、前記変換前文字列と対応付けられている変換後文字列を用いて前記第２のサーバに送信する前記第２の送信データを生成すること
    を特徴とする請求項１１に記載のコンピュータプログラム。

Images