JP2004341818A - 個人情報管理システム - Google Patents
個人情報管理システム Download PDFInfo
- Publication number
- JP2004341818A JP2004341818A JP2003137507A JP2003137507A JP2004341818A JP 2004341818 A JP2004341818 A JP 2004341818A JP 2003137507 A JP2003137507 A JP 2003137507A JP 2003137507 A JP2003137507 A JP 2003137507A JP 2004341818 A JP2004341818 A JP 2004341818A
- Authority
- JP
- Japan
- Prior art keywords
- request
- personal information
- management system
- information management
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】異なる装置の異なるアプリケーションに分散する個人情報の整合性を保ち、個人情報を共有化する。
【解決手段】個人情報を扱うアプリケーションが動作する個人情報管理システムであって、前記アプリケーションと、要求を含むデータのやり取りをおこなうアプリケーションインターフェース手段と、実行手段と、他の個人情報管理システムの実行手段と、要求を含むデータのやり取りを行なうデータ送受信手段とを備え、前記実行手段は、前記アプリケーションまたは外部の実行手段から要求を受け付けると、あらかじめ要求対応に定められた規則にしたがって、前記アプリケーションあるいは他の個人情報管理システムの実行手段に対して処理要求を行なうことを特徴とする個人情報管理システムを提供する。
【選択図】 図２
【解決手段】個人情報を扱うアプリケーションが動作する個人情報管理システムであって、前記アプリケーションと、要求を含むデータのやり取りをおこなうアプリケーションインターフェース手段と、実行手段と、他の個人情報管理システムの実行手段と、要求を含むデータのやり取りを行なうデータ送受信手段とを備え、前記実行手段は、前記アプリケーションまたは外部の実行手段から要求を受け付けると、あらかじめ要求対応に定められた規則にしたがって、前記アプリケーションあるいは他の個人情報管理システムの実行手段に対して処理要求を行なうことを特徴とする個人情報管理システムを提供する。
【選択図】 図２
Description
【０００１】
【発明の属する技術分野】
本発明は、異なる装置の異なるアプリケーションに分散する個人情報の整合性を保ち、個人情報を共有化するための技術に関する。
【０００２】
【従来の技術】
近年、コンピュータ等の情報処理装置を用いて個人情報の管理を行なうことが盛んに行なわれるようになっている。個人情報は、情報処理装置への依存度が高まるにつれて肥大化／多様化する一方であるが、通常、個人情報は、情報の種類等毎に異なるアプリケーションを用いて管理されるため、個人情報が分散して管理されることになる。このため、個人情報の整合性をとることが難しくなるという問題が生じていた。
【０００３】
個人情報の整合性をとるために個人情報を一元的に管理することが考えられるが、このための技術として、特許文献１において個人情報管理装置が提案されている。これは、利用者の個人情報を電子的に管理する個人情報管理装置において、同一の利用者が持つ、異なる立場に対する個人情報を、立場毎にそれぞれ格納した複数の個人情報データベースを備えた個人情報格納手段から、所定のルールに基づいた個人情報データベースを選択する個人情報データベース選択手段と、個人情報データベース選択手段によって選択された個人情報データベースに対して、個人情報の読み書きを許可するように処理する処理手段とを備えたものである。
【０００４】
【特許文献１】
特開２００２−３６６５５０号公報
【０００５】
【発明が解決しようとする課題】
しかし、コンピュータネットワークが普及し、装置間での情報のやり取りが頻繁に行なわれるようになった今日、個人情報の分散による整合性の問題は、その個人が使用する情報処理装置内にとどまらず、コンピュータネットワーク上に存在する情報処理装置間においても起こり得る問題である。このため、個人情報はなるべく共有化できることが望ましい。しかしながら、特定の情報処理装置に個人情報を一元的に管理させるようにすると、負荷の集中を招き好ましくない。
【０００６】
本発明は、異なる装置の異なるアプリケーションに分散する個人情報の整合性を保ち、個人情報を共有化するための技術を提供することを目的とする。
【０００７】
【課題を解決するための手段】
上記目的を達成するため、本発明によれば、
個人情報を扱うアプリケーションが動作する個人情報管理システムであって、前記アプリケーションと、要求を含むデータのやり取りをおこなうアプリケーションインターフェース手段と、
実行手段と、
他の個人情報管理システムの実行手段と、要求を含むデータのやり取りを行なうデータ送受信手段とを備え、
前記実行手段は、前記アプリケーションまたは外部の実行手段から要求を受け付けると、あらかじめ要求対応に定められた規則にしたがって、前記アプリケーションあるいは他の個人情報管理システムの実行手段に対して処理要求を行なうことを特徴とする個人情報管理システムが提供される。
【０００８】
【発明の実施の形態】
本発明の実施の形態を図面を参照して詳細に説明する。以下では、本発明をオフィス機器のメンテナンスサービスを提供する会社の保守員のパーソナル情報管理に適用した場合を例に説明する。
【０００９】
図１は、本発明のシステム構成の概略を示す図である。オフィス機器のメンテナンスサービスを提供する会社である保守サービス会社Ａは、従業する保守員のクライアント企業への訪問スケジュール等を管理するための保守員訪問管理システム３１０を運用している。保守サービス会社Ａの従業員である保守員Ｘおよび保守員Ｙは、それぞれ携帯端末３４０、３５０を所持している。
【００１０】
また、保守サービス会社Ａのクライアントである会社Ｃでは、自社への訪問者の受付を管理する訪問者受付システム３３０を運用している。訪問者受付システム３３０の管理担当者である担当者Ｚは、デスクトップ端末３６０を用いて訪問者受付システム３３０の管理を行なっている。
【００１１】
保守員訪問管理システム３１０、保守員Ｘの携帯端末３４０、保守員Ｙの携帯端末３５０、訪問者受付システム３３０のそれぞれは、インターネット３００に接続されており、ＨＴＴＰ、ＦＴＰ等のプロトコルを用いて互いにデータの授受ができるようになっている。
【００１２】
また、インターネット３００には、情報サービスプロバイダが管理する位置情報サービスシステム３２０が接続され、端末に位置情報を提供している。
【００１３】
本実施例において、保守員訪問管理システム３１０、保守員Ｘの携帯端末３４０、保守員Ｙの携帯端末３５０、訪問者受付システム３３０、デスクトップ端末３６０では、それぞれの端末が担う機能を実現するためのアプリケーション１０１（図２参照）、および、ＨＴＴＰ、ＦＴＰ等のプロトコルを用いてインターネット３００を介した通信を行なうためのデータ通信プロトコル処理部１８０（図２参照）が動作している。
【００１４】
また、各端末には、アプリケーション１０１が管理している個人データを各端末間で同期させるためのシンクロマネージャ１００が動作している。
【００１５】
図２は、シンクロマネージャ１００の機能構成の概略を示すブロック図である。本図の例では、端末上に、３つのアプリケーション１０１ａ〜１０１ｃが動作しているものとする。
【００１６】
本図において、アプリケーションデータ変換部１１１ａ〜１１１ｃは、シンクロマネージャ１００と各アプリケーション１０１ａ〜１０１ｃとの間のインターフェース処理を行なう。アプリケーションデータ変換部１１１ａ〜１１１ｃは、例えば、アプリケーション１０１ａ〜１０１ｃ対応に設けられ、対応するアプリケーション１０１の固有のインターフェースにより、アプリケーション１０１とデータのやり取りを行なう。そして、あらかじめ定められた規則にしたがって、対応するアプリケーション１０１が採用するデータ形式と、シンクロマネージャ１００が採用する共通のデータ形式とを相互に変換する。
【００１７】
アプリケーションデータ制御部１１０は、アプリケーション１０１が出力したデータをシンクロマネージャ１００に要求として通知したり、シンクロマネージャ１００からアプリケーション１０１への処理を適切なアプリケーション１０１に振り分けたりする等の、シンクロマネージャ１００とアプリケーション１０１との間のデータのやり取りを制御する。
【００１８】
シンクロポリシー実行部１２０は、シンクロポリシーＤＢ部１３０を参照して、自端末装置が管理する個人データと他の端末装置が管理する個人データとを同期させるための処理を実行する。この処理を定めるルールをシンクロポリシーと称する。シンクロポリシー実行部１２０の詳細な処理内容については、後述する。
【００１９】
アプリケーションデータ送受信部１４０は、他の端末のシンクロマネージャ１００との間でデータ（要求）をやり取りする。
【００２０】
位置情報取得部１５０は、位置情報サービスシステム３２０と連携して端末の位置情報を取得する。
【００２１】
シンクロポリシー設定部１６０は、例えば、ＧＵＩを通じて、ユーザからシンクロポリシーの設定を受け付け、シンクロポリシーＤＢ部１３０に登録する。
【００２２】
シンクロポリシー交換部１７０は、設定されたシンクロポリシーを指定された端末のシンクロマネージャ１００に通知し、相手方がこのシンクロポリシーを受け入れた場合には、シンクロポリシーＤＢ部１３０に登録する。また、他のシンクロマネージャ１００からシンクロポリシーを通知されると、ユーザに登録の可否を問い、登録の許可を受け付けるとシンクロポリシーＤＢ部１３０に登録する。
【００２３】
各端末は、パーソナルコンピュータ、携帯型情報装置等の一般的な情報処理装置を用いることができる。図３は、一般的な情報処理装置のハードウェア構成を示すブロック図である。ただし、各端末として用いるハードウェアはこれに限定されない。例えば、情報処理機能を備えた携帯電話等を用いるようにしてもよい。
【００２４】
図３において、情報処理装置は、プログラムにしたがって処理を行なうＣＰＵ２０１と、プログラムを格納するメモリ２０２と、入出力インターフェース２０３とを備え、さらに、入出力インターフェース２０３を介して、内部あるいは外部に、ディスプレイ等の表示装置２０４、キーボード、マウス等の入力装置２０５、補助記憶装置２０６、インターネット３００に接続するための処理を行なうネットワーク装置２０７が接続される。シンクロマネージャ１００、各種アプリケーション１０１は、メモリ２０２に格納された専用プログラムをＣＰＵ２０１が実行すること等により、端末上で動作する。
【００２５】
シンクロマネージャ１００のシンクロポリシーＤＢ部１３０には、その端末装置の用途等に応じたシンクロポリシーが登録される。
【００２６】
図４に示すように、シンクロポリシーは、ポリシーテーブル５１０と、条件テーブル５２０と、アクションテーブル５３０とから構成される。
【００２７】
ポリシーテーブル５１０は、ポリシＩＤ毎に１つ以上の条件ＩＤと１つ以上のアクションＩＤとを対応させたテーブルである。
【００２８】
条件テーブル５２０は、条件ＩＤ毎に、要求元、要求種類、要求データ条件が定められる。これらは、シンクロポリシー実行部１２０に対する要求がどこから送られてきたか、どのような種類の要求か、具体的な要求の内容の条件をそれぞれ示すものである。
【００２９】
アクションテーブル５３０は、シンクロマネージャ１００が行なうべき処理を規定するテーブルで、アクションＩＤ毎に、宛先、呼出アドレス／モジュール、呼出パラメータが定められる。すなわち、宛先および呼出アドレス／モジュールで特定される相手先に、呼出パラメータで定められる情報が送信される。
【００３０】
なお、図４は、保守員Ｘが所持する携帯端末３４０で動作するシンクロマネージャ１００のシンクロポリシーＤＢ部１３０に設定されているシンクロポリシーの例を示している。
【００３１】
本図の例では、ポリシーＩＤ：Ｐ００１で特定されるポリシーにおいて、条件ＩＤ：Ｃ００１とアクションＩＤ：Ａ００１とが対応付けられている。この場合、ある要求に対するポリシーＩＤ：Ｐ００１で特定されるポリシーの評価は以下のように行なわれる。
【００３２】
すなわち、条件ＩＤ：Ｃ００１で特定される条件データを条件テーブル５２０から抽出する。そして、ある要求が、要求元、要求種類、要求データ条件のすべてを満たすかどうかを判断する。この場合、ある要求の要求元が自端末で動作しているスケジュールアプリケーションであり、要求種類がスケジュール問い合わせであり、問い合わせユーザ名がＣ社担当保守員グループに含まれ、かつ、問い合わせデータ名がＣ社訪問スケジュールである場合に、条件ＩＤ：Ｃ００１が満たされることになる。条件ＩＤ：Ｃ００１が満たされている場合には、ポリシーＩＤ：Ｐ００１で特定されるポリシーで条件ＩＤに対応付けられたアクションＩＤに対応するアクションデータをアクションテーブル５３０から抽出して、そのアクションを実行する。なお、Ｃ社担当保守員グループに含まれるユーザ名等の条件判断に必要な情報は、あらかじめアプリケーションデータ変換部１１１に設定しておくことができる。
【００３３】
以上の評価を、ポリシーテーブル５１０に登録されたすべてのポリシーについて行なうことになる。
【００３４】
また、図５は、保守サービス会社Ａの保守員訪問管理システム３１０上で動作するシンクロマネージャ１００のシンクロポリシーＤＢ部１３０に設定シンクロポリシーの例であり、図６は、保守員Ｙが所持する携帯端末３５０で動作するシンクロマネージャ１００のシンクロポリシーＤＢ部１３０に設定されているシンクロポリシーの例を示している。そして、図７は、クライアントである会社Ｃの訪問者受付システム３３０上で動作するシンクロマネージャ１００のシンクロポリシーＤＢ部１３０に設定シンクロポリシーの例である。このように、シンクロポリシーは、各端末毎に、その端末の使用目的等に応じた設定を行なうことができる。
【００３５】
つぎに、シンクロポリシー実行部１２０の処理について図８のフロー図を参照して説明する。
【００３６】
シンクロポリシー実行部１２０は、要求を受け付けて、その要求に対応した処理を行なう。この要求は、自端末のアプリケーション１０１から送られる場合と、他の端末のシンクロマネージャ１００から送られる場合とがある。また、要求に対応した処理は、自端末のアプリケーション１０１に対して処理の内容を示したデータを送る場合と、他の端末のシンクロマネージャ１００に対して処理の内容を示したデータを送る場合とがあり、これは、実行するアクションテーブル５３０の宛先により定められる。
【００３７】
自端末のアプリケーション１０１から要求が送られる場合は、アプリケーションデータ制御部１１０を介して要求を受け付ける。また、他の端末のシンクロマネージャ１００から要求が送られる場合は、アプリケーションデータ送受信部１４０を介して要求を受け付ける。
【００３８】
自端末のアプリケーション１０１に対して処理の内容を示したデータを送る場合は、アプリケーションデータ制御部１１０を介してデータを送信する。また、他の端末のシンクロマネージャ１００に対して処理の内容を示したデータを送る場合は、アプリケーションデータ送受信部１４０を介してデータを送信する。この場合、他の端末のシンクロマネージャ１００にとっては、要求が送られることになる。
【００３９】
本処理は、シンクロポリシー実行部１２０が、要求を受け付けることにより開始される（Ｓ１０１）。
【００４０】
シンクロポリシー実行部１２０は、シンクロポリシーＤＢ部１３０のポリシーテーブル５１０に設定されているポリシーデータを順番に選択する（Ｓ１０２）。そして、要求の内容が、選択されたポリシーデータの条件ＩＤで特定される条件データの要求元、要求種類、要求データ条件のすべてを満たすかどうかを判断する（Ｓ１０３）。このとき、条件判断に位置情報が必要である場合には、位置情報取得部１５０に問い合わせて自端末の位置情報を取得して条件判断を行なう。
【００４１】
要求の内容が、ポリシーデータの条件ＩＤで特定される条件データを満たさない場合には（Ｓ１０３：Ｎ）、ポリシーテーブル５１０に、つぎのポリシーデータがあるかどうかを調べ（Ｓ１０７）、ある場合には、そのポリシーデータを選択して（Ｓ１０２）、同様の処理を行なう。一方、つぎのポリシーデータがない場合には、本処理を終了する。
【００４２】
要求の内容が、ポリシーデータの条件ＩＤで特定される条件データのすべてを満たす場合には（Ｓ１０３：Ｙ）、対応するアクションＩＤで特定されるアクションデータをアクションテーブル５３０から抽出する（Ｓ１０４）。アクションＩＤが複数設定されている場合には、すべてのアクションデータを抽出する。
【００４３】
そして、抽出されたアクションデータにしたがった処理を行なう（Ｓ１０５）。具体的には、宛先で示された相手先（例えば、自端末のアプリケーション、他の端末のシンクロマネージャ）の呼出アドレス／モジュールに対して、呼出パラメータで示された情報を送信する。このとき、処理に位置情報が必要である場合には、位置情報取得部１５０に問い合わせて自端末の位置情報を取得して処理を行なう。
【００４４】
送信した情報を相手先が受領した場合には（Ｓ１０６：Ｙ）、上述のように、つぎのポリシーデータがあるかどうかの判断を行なう（Ｓ１０７）。送信した情報を相手先が受領できなかった場合には（Ｓ１０６：Ｎ）、所定時間経過後に再度送信するようにする。
【００４５】
上記シンクロマネージャ１００を備えた端末間の具体的な処理の例を図９に示したシーケンス図を参照して説明する。
【００４６】
保守員Ｘの携帯端末３４０上と保守員Ｙの携帯端末３５０上には、アプリケーション１０１として、訪問スケジュール管理アプリケーションがそれぞれ動作しているものとする。
【００４７】
本処理では、保守員Ｘが、クライアント会社Ｃを担当している保守員の最新の訪問スケジュールを取得して、訪問スケジュールを変更した場合を例とする。
【００４８】
まず、保守員Ｘが、訪問スケジュール管理アプリケーション上で、クライアント会社Ｃを担当している保守員の訪問スケジュールを問い合わせる。
【００４９】
すると、携帯端末３４０の訪問スケジュール管理アプリケーションは、シンクロマネージャ１００に対して、クライアント会社Ｃを担当している保守員の訪問スケジュールを問い合わせ要求を行なう（４１０ａ）。
【００５０】
携帯端末３４０のシンクロマネージャ１００のアプリケーションデータ制御部１１０は、アプリケーションデータ変換部１１１を介して、この要求を取得し、シンクロポリシー実行部１２０に通知する。
【００５１】
この要求は、図４に示した条件ＩＤ：Ｃ００１に規定された条件を満たすため、シンクロポリシー実行部１２０は、ポリシーＩＤ：Ｐ００１のポリシーデータにしたがい、アクションＩＤ：Ａ００１に規定された処理を行なう。すなわち、保守員訪問管理システム３１０のシンクロマネージャ１００に対して、呼出アドレス／モジュールとしてｓｙｎｃｓｒｖ．ａｂｃ．ｃｏ．ｊｐ／ｏｐｅｒａｔｉｏｎ＿ｃｅｎｔｅｒを指定し、呼出パラメータを｛オペレーション名＝ｑｕｅｒｙ｝＆｛ユーザ名＝アプリ指定｝＆｛暗号化フラグ＝ＯＮ｝として要求を行なう（４１０ｂ）。
【００５２】
保守員訪問管理システム３１０のシンクロマネージャ１００は、この要求が、図５に示した条件ＩＤ：Ｃ００１に規定された条件を満たすと判断し、シンクロポリシー実行部１２０が、ポリシーＩＤ：Ｐ００１のポリシーデータにしたがい、アクションＩＤ：Ａ００１に規定された処理を行なう。すなわち、自端末で動作するアプリケーションのｓｃｈｅｄｕｌｅｒモジュールに対してスケジュールを問い合わせ（４１０ｃ）、クライアント会社Ｃを担当している保守員の訪問スケジュールを取得する（４１０ｄ）。
【００５３】
そして、保守員訪問管理システム３１０のシンクロマネージャ１００は、この応答に対応するシンクロポリシーにしたがって保守員Ｘの携帯端末３４０のシンクロマネージャ１００に対してクライアント会社Ｃを担当している保守員の訪問スケジュールを送信する（４１０ｅ）。
【００５４】
携帯端末３４０のシンクロマネージャ１００は、受信した要求に対応するシンクロポリシーにしたがって、自端末で動作する訪問スケジュール管理アプリケーションに、受信したクライアント会社Ｃを担当している保守員の訪問スケジュールを送る（４１０ｆ）。
【００５５】
これにより、携帯端末３４０を使用する保守員Ｘは、クライアント会社Ｃを担当している保守員の最新の訪問スケジュールを訪問スケジュール管理アプリケーション上で確認することができる。
【００５６】
つぎに、携帯端末３４０を使用する保守員Ｘが、訪問スケジュール管理アプリケーション上で訪問スケジュールの変更をすると、訪問スケジュール管理アプリケーションは、携帯端末３４０のシンクロマネージャ１００に要求を送る（４２０ａ）。その後は、上述と同様にして、携帯端末３４０のシンクロマネージャ１００および保守員訪問管理システム３１０のシンクロマネージャ１００がそれぞれのシンクロポリシーにしたがって処理を行なうことで、保守員訪問管理システム３１０が管理するクライアント会社Ｃを担当している保守員の訪問スケジュールが更新される（４２０ｂ〜４２０ｆ）。
【００５７】
また、保守員訪問管理システム３１０のシンクロマネージャ１００は、保守員Ｘの携帯端末３４０のシンクロマネージャ１００からのスケジュール変更要求に対応して、保守員Ｘの携帯端末３５０のシンクロマネージャ１００に対してスケジュール変更要求を送る（４３０ａ）。保守員Ｘの携帯端末３５０のシンクロマネージャ１００は、この要求に対応して、携帯端末３５０上で動作する訪問スケジュール管理アプリケーションのスケジュールを変更する（４３０ｂ〜４３０ｄ）。
【００５８】
さらに、保守員Ｘの携帯端末３５０のシンクロマネージャ１００は、保守員訪問管理システム３１０のシンクロマネージャ１００からのスケジュール変更要求に対応して、クライアント会社Ｃの訪問者受付システム３３０のシンクロマネージャ１００に対してスケジュール変更要求を送る（４４０ａ）。この要求に対応して、シンクロマネージャ１００は、訪問者受付システム３３０が管理する訪問者受付スケジュールを変更する（４４０ｂ〜４４０ｄ）。
【００５９】
図１０は、上記処理で用いられるデータ内容の一例を示している。図１０（ａ）は、訪問スケジュール管理アプリケーションが保持しているスケジュール変更前のデータの例で、図１０（ｂ）が変更後のデータの例である。そして、図１０（ｃ）は、シンクロマネージャ１００間で渡されるスケジュール変更要求の例である。本例では、スケジュール変更要求は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で記述されているが、これに限られるものではない。
【００６０】
このように、本発明によると保守員の急なスケジュール変更を他の保守員や訪問先のスケジュールに反映することができ、各装置のアプリケーションがそれぞれ管理する個人データの整合性を保つことができるようになる。
【００６１】
また、他の具体的な処理の例を、図１１のシーケンス図を参照して説明する。
【００６２】
本処理では、コンタクト情報の同期を行なう場合を例にする。本例では、保守員Ｙの携帯端末３５０上でコンタクト情報管理アプリケーションが動作しているものとする。
【００６３】
保守員Ｙが、訪問先に到着後、携帯端末３５０を用いてクライアント会社Ｃの訪問者受付システム３３０に接続すると、訪問者受付アプリケーションが処理を開始する。
【００６４】
クライアント会社Ｃの訪問者受付システム３３０の訪問者受付アプリケーションが、シンクロマネージャ１００に、保守員Ｙのコンタクト情報の同期を要求すると（４５０ａ）、シンクロマネージャ１００は、保守員Ｙの携帯端末３５０のシンクロマネージャ１００に要求を転送する（４５０ｂ）。これは、例えば、以下のようなポリシーを実行することにより実現することができる。
【００６５】
条件：要求元＝受付アプリ、要求種類＝コンタクト情報取得、要求データ条件＝保守員ＹがＣ社対応保守員グループに属す。アクション１：宛先＝保守員Ｙのコンタクト管理アプリ、呼出アドレス＝ｓｙｎｃｓｒｖ．ａｂｃ．ｃｏ．ｊｐ／ｌｉｓｔ／Ｃｌｉｅｎｔ−Ｃ、呼出パラメータ＝｛オペ名＝ｑｕｅｒｙ｝＆｛ユーザ名＝取得ユーザＩＤ｝。アクション２：宛先＝Ｃ社担当者Ｚのコンタクト情報管理アプリ、呼出アドレス＝ｓｙｎｓｒｖ．Ｃ−Ｃｏｍｐａｎｙ．ｃｏ．ｊｐ／Ａｄｍｉｎ、呼出パラメータ＝｛オペ名＝ｎｏｔｉｆｙ｝＆｛ユーザ名＝取得ユーザＩＤ｝。なお、アクション２はアクション１が完了した後に実行する。
【００６６】
保守員Ｙの携帯端末３５０のシンクロマネージャ１００は、コンタクト情報管理アプリケーションからコンタクト情報を取得し（４５０ｃ〜４５０ｄ）、取得したコンタクト情報を訪問者受付システム３３０に送信する（４５０ｅ〜４５０ｆ）。これは、例えば、以下のようなポリシーを実行することにより実現することができる。
【００６７】
条件：要求元＝受付アプリ、要求種類＝コンタクト情報取得、要求データ条件＝取得ユーザがＣ社対応保守員グループに属す。アクション：宛先＝自端末のコンタクト情報管理アプリ、呼出モジュール＝ＣｏｎｔａｃｔＡｐｐ、呼出パラメータ＝｛オペ名＝ｑｕｅｒｙ｝＆｛ユーザ名＝取得ユーザＩＤ｝。
【００６８】
図１２は、このときのコンタクト情報の一例を示す図である。本例では、コンタクト情報は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で記述されているが、これに限られるものではない。
【００６９】
さらに、訪問者受付システム３３０のシンクロマネージャ１００は、担当者Ｚのデスクトップ端末３６０のシンクロマネージャ１００にコンタクト情報を伝え（４６０ａ）、このシンクロマネージャ１００が担当者Ｚのデスクトップ端末３６０で動作するコンタクト情報管理アプリケーションに保守員Ｙからのコンタクト情報を設定する（４６０ｂ〜４６０ｄ）。これは、例えば、以下のようなポリシーを実行することにより実現することができる。
【００７０】
条件：要求元＝受付アプリ、要求種類＝コンタクト情報通知、要求データ条件＝通知ユーザがＣ社対応保守員グループに属す。アクション：宛先＝自端末のコンタクト情報管理アプリ、呼出モジュール＝ＡｄｄｒｅｓｓＭａｎａｇｅｒ、呼出パラメータ＝｛オペ名＝ｎｏｔｉｆｙ｝＆｛ユーザ名＝取得ユーザＩＤ｝。
【００７１】
このように、本発明によると変更された保守員のコンタクト情報を訪問先のシステムおよび担当者に伝えることができ、各装置のアプリケーションがそれぞれ管理する個人データの整合性を保つことができるようになる。
【００７２】
つぎに、端末におけるシンクロポリシーの設定および端末間でのシンクロポリシーの交換について説明する。
【００７３】
端末のユーザは、シンクロマネージャ１００のシンクロポリシー設定部１６０が提供するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を利用して、シンクロポリシーを設定することができる。
【００７４】
図１３に、シンクロポリシー設定部１６０が提供するＧＵＩの一例を示す。本図において、シンクロポリシー設定画面９００は、新規ポリシーを登録する「新規」ボタン９７０、登録済みポリシーを変更する「変更」ボタン９７１、登録済みポリシーを直ちに実行に移す「実行」ボタン９７２を備え、ユーザからの指示を受け付ける。
【００７５】
そして、「新規」または「変更」の内容を設定するためのシンクアプリケーション領域とシンクロ先端末／サーバ領域とを備えている。シンクアプリケーション領域は、主として条件データを定義するための領域で、シンクロ先端末／サーバ領域は、アクションデータを定義するための領域である。
【００７６】
シンクロアプリケーション領域では、アプリケーション指定欄９１０で、端末上で動作可能なアプリケーションのうちから、データ同期の対象となるアプリケーションを選択できる。ここで指定されたアプリケーションが条件データの要求元として規定される。データ同期条件入力欄９１１で、対象アプリケーションのどの範囲のデータについて同期するかを指定することができる。例えば、データ項目が特定の文字列に一致する、一致しない、一部を含む、一部を含まない等を指定することができ、複数の条件に対しては、ＡＮＤ条件とＯＲ条件で結合することができる。ここで指定された条件が条件データの要求データ条件として規定される。さらに、アクセス条件指定欄９１２で、データに対する作成、参照、変更、削除等のうちの対象とする組合せを指定することができる。ここで指定された内容が条件データの要求種類として規定される。また、暗号化指定欄９１３ではデータを送信する際に暗号化および復号化処理を行うか否かを指定することができる。
【００７７】
シンクロ先端末／サーバ領域は、同期する相手を指定する欄９２０と、端末／サーバにアクセスするエンドポイント情報を指定するアドレス情報欄９２１とを備えている。これらの欄に指定した内容がアクションデータの宛先と呼び出しアドレス／モジュールに規定される。位置情報入力欄９２２には、オプション条件として、端末／サーバの位置情報を指定することができる。位置情報は、緯度・経度情報のほか、地図上の目印となる目標物名称（交通機関、公共施設等）、物理的な位置と対応付けられた論理的な場所を表す名称（本社、支社等）を記述してもよい。さらに、認証情報指定欄９５０には、オプションとして、相手端末／サーバにアクセスする際に必要となる情報（ＩＤ・パスワード、電子証明書等）を指定するすることができる。
【００７８】
シンクロポリシー設定画面９００で、「登録」ボタン９６０のクリックを受け付けると、シンクロポリシー設定部１６０は、シンクロポリシーの登録と交換処理を行なう。
【００７９】
シンクロポリシーの登録と交換処理について、図１４のフロー図を参照して説明する。
【００８０】
シンクロポリシー設定画面９００で、「登録」ボタン９６０のクリックを受け付けると（Ｓ２０１）、シンクロポリシー設定部１６０は、設定された内容に基づいて、条件データとアクションデータとを生成し、ポリシーデータで両者を関連付けてシンクロポリシーＤＢ部１３０に登録する（Ｓ２０２）。
【００８１】
つぎに、シンクロポリシー交換部１７０がシンクロ先として指定された端末／サーバにポリシーの受け入れ要求を送る（Ｓ２０３）。
【００８２】
相手方がポリシーを受け入れると応答した場合には処理を終了する。このとき、相手方は受け入れたポリシーに応じたシンクロポリシーを生成して、シンクロポリシーＤＢ部１３０に登録する。一方、相手方が受け入れないとの応答した場合には、対応するシンクロポリシーの宛先から相手先の端末／サーバを削除する（Ｓ２０４）。なお、すべての相手方が受け入れないと応答した場合には、処理（Ｓ２０２）で登録したシンクロポリシー自体をシンクロポリシーＤＢ部１３０から削除する。
【００８３】
【発明の効果】
以上説明したように、本発明によれば、異なる装置の異なるアプリケーションに分散する個人情報の整合性を保ち、個人情報を共有化するための技術が提供される。
【図面の簡単な説明】
【図１】本発明のシステム構成の概略を示す図である。
【図２】シンクロマネージャ１００の機能構成の概略を示すブロック図である。
【図３】一般的な情報処理装置のハードウェア構成を示すブロック図である。
【図４】シンクロポリシーの構成および保守員Ｘが所持する携帯端末３４０で設定されているシンクロポリシーの例を示す図である。
【図５】保守員訪問管理システム３１０で設定されているシンクロポリシーの例を示す図である。
【図６】保守員Ｙが所持する携帯端末３５０で設定されているシンクロポリシーの例を示す図である。
【図７】会社Ｃの訪問者受付システム３３０で設定されているシンクロポリシーの例を示す図である。
【図８】シンクロポリシー実行部１２０の処理について説明するためのフロー図である。
【図９】シンクロマネージャ１００を備えた端末間の具体的な処理の例を説明するためのシーケンス図である。
【図１０】端末間の処理で用いられるデータ内容の一例を示す図である。
【図１１】シンクロマネージャ１００を備えた端末間の具体的な処理の他例を説明するためのシーケンス図である。
【図１２】コンタクト情報の一例を示す図である。
【図１３】シンクロポリシー設定部１６０が提供するＧＵＩの一例を示す図である。
【図１４】シンクロポリシーの登録と交換処理について説明するためのフロー図である。
【符号の説明】
１００…シンクロマネージャ、１０１…アプリケーション、１１０…アプリケーションデータ制御部、１１１…アプリケーションデータ変換部、１２０…シンクロポリシー実行部、１３０…シンクロポリシーＤＢ部、１４０…アプリケーションデータ送受信部、１５０…位置情報取得部、１６０…シンクロポリシー設定部、１７０…シンクロポリシー交換部、１８０…データ通信プロトコル処理部、２０１…ＣＰＵ、２０２…メモリ、２０３…入出力インターフェース、２０４…表示装置、２０５…入力装置、２０６…補助記憶装置、２０７…ネットワーク装置、３００…インターネット、３１０…保守員訪問管理システム、３２０…位置情報サービスシステム、３２０…位置情報サービスシステム、３３０…訪問者受付システム、３４０…携帯端末、３５０…携帯端末
【発明の属する技術分野】
本発明は、異なる装置の異なるアプリケーションに分散する個人情報の整合性を保ち、個人情報を共有化するための技術に関する。
【０００２】
【従来の技術】
近年、コンピュータ等の情報処理装置を用いて個人情報の管理を行なうことが盛んに行なわれるようになっている。個人情報は、情報処理装置への依存度が高まるにつれて肥大化／多様化する一方であるが、通常、個人情報は、情報の種類等毎に異なるアプリケーションを用いて管理されるため、個人情報が分散して管理されることになる。このため、個人情報の整合性をとることが難しくなるという問題が生じていた。
【０００３】
個人情報の整合性をとるために個人情報を一元的に管理することが考えられるが、このための技術として、特許文献１において個人情報管理装置が提案されている。これは、利用者の個人情報を電子的に管理する個人情報管理装置において、同一の利用者が持つ、異なる立場に対する個人情報を、立場毎にそれぞれ格納した複数の個人情報データベースを備えた個人情報格納手段から、所定のルールに基づいた個人情報データベースを選択する個人情報データベース選択手段と、個人情報データベース選択手段によって選択された個人情報データベースに対して、個人情報の読み書きを許可するように処理する処理手段とを備えたものである。
【０００４】
【特許文献１】
特開２００２−３６６５５０号公報
【０００５】
【発明が解決しようとする課題】
しかし、コンピュータネットワークが普及し、装置間での情報のやり取りが頻繁に行なわれるようになった今日、個人情報の分散による整合性の問題は、その個人が使用する情報処理装置内にとどまらず、コンピュータネットワーク上に存在する情報処理装置間においても起こり得る問題である。このため、個人情報はなるべく共有化できることが望ましい。しかしながら、特定の情報処理装置に個人情報を一元的に管理させるようにすると、負荷の集中を招き好ましくない。
【０００６】
本発明は、異なる装置の異なるアプリケーションに分散する個人情報の整合性を保ち、個人情報を共有化するための技術を提供することを目的とする。
【０００７】
【課題を解決するための手段】
上記目的を達成するため、本発明によれば、
個人情報を扱うアプリケーションが動作する個人情報管理システムであって、前記アプリケーションと、要求を含むデータのやり取りをおこなうアプリケーションインターフェース手段と、
実行手段と、
他の個人情報管理システムの実行手段と、要求を含むデータのやり取りを行なうデータ送受信手段とを備え、
前記実行手段は、前記アプリケーションまたは外部の実行手段から要求を受け付けると、あらかじめ要求対応に定められた規則にしたがって、前記アプリケーションあるいは他の個人情報管理システムの実行手段に対して処理要求を行なうことを特徴とする個人情報管理システムが提供される。
【０００８】
【発明の実施の形態】
本発明の実施の形態を図面を参照して詳細に説明する。以下では、本発明をオフィス機器のメンテナンスサービスを提供する会社の保守員のパーソナル情報管理に適用した場合を例に説明する。
【０００９】
図１は、本発明のシステム構成の概略を示す図である。オフィス機器のメンテナンスサービスを提供する会社である保守サービス会社Ａは、従業する保守員のクライアント企業への訪問スケジュール等を管理するための保守員訪問管理システム３１０を運用している。保守サービス会社Ａの従業員である保守員Ｘおよび保守員Ｙは、それぞれ携帯端末３４０、３５０を所持している。
【００１０】
また、保守サービス会社Ａのクライアントである会社Ｃでは、自社への訪問者の受付を管理する訪問者受付システム３３０を運用している。訪問者受付システム３３０の管理担当者である担当者Ｚは、デスクトップ端末３６０を用いて訪問者受付システム３３０の管理を行なっている。
【００１１】
保守員訪問管理システム３１０、保守員Ｘの携帯端末３４０、保守員Ｙの携帯端末３５０、訪問者受付システム３３０のそれぞれは、インターネット３００に接続されており、ＨＴＴＰ、ＦＴＰ等のプロトコルを用いて互いにデータの授受ができるようになっている。
【００１２】
また、インターネット３００には、情報サービスプロバイダが管理する位置情報サービスシステム３２０が接続され、端末に位置情報を提供している。
【００１３】
本実施例において、保守員訪問管理システム３１０、保守員Ｘの携帯端末３４０、保守員Ｙの携帯端末３５０、訪問者受付システム３３０、デスクトップ端末３６０では、それぞれの端末が担う機能を実現するためのアプリケーション１０１（図２参照）、および、ＨＴＴＰ、ＦＴＰ等のプロトコルを用いてインターネット３００を介した通信を行なうためのデータ通信プロトコル処理部１８０（図２参照）が動作している。
【００１４】
また、各端末には、アプリケーション１０１が管理している個人データを各端末間で同期させるためのシンクロマネージャ１００が動作している。
【００１５】
図２は、シンクロマネージャ１００の機能構成の概略を示すブロック図である。本図の例では、端末上に、３つのアプリケーション１０１ａ〜１０１ｃが動作しているものとする。
【００１６】
本図において、アプリケーションデータ変換部１１１ａ〜１１１ｃは、シンクロマネージャ１００と各アプリケーション１０１ａ〜１０１ｃとの間のインターフェース処理を行なう。アプリケーションデータ変換部１１１ａ〜１１１ｃは、例えば、アプリケーション１０１ａ〜１０１ｃ対応に設けられ、対応するアプリケーション１０１の固有のインターフェースにより、アプリケーション１０１とデータのやり取りを行なう。そして、あらかじめ定められた規則にしたがって、対応するアプリケーション１０１が採用するデータ形式と、シンクロマネージャ１００が採用する共通のデータ形式とを相互に変換する。
【００１７】
アプリケーションデータ制御部１１０は、アプリケーション１０１が出力したデータをシンクロマネージャ１００に要求として通知したり、シンクロマネージャ１００からアプリケーション１０１への処理を適切なアプリケーション１０１に振り分けたりする等の、シンクロマネージャ１００とアプリケーション１０１との間のデータのやり取りを制御する。
【００１８】
シンクロポリシー実行部１２０は、シンクロポリシーＤＢ部１３０を参照して、自端末装置が管理する個人データと他の端末装置が管理する個人データとを同期させるための処理を実行する。この処理を定めるルールをシンクロポリシーと称する。シンクロポリシー実行部１２０の詳細な処理内容については、後述する。
【００１９】
アプリケーションデータ送受信部１４０は、他の端末のシンクロマネージャ１００との間でデータ（要求）をやり取りする。
【００２０】
位置情報取得部１５０は、位置情報サービスシステム３２０と連携して端末の位置情報を取得する。
【００２１】
シンクロポリシー設定部１６０は、例えば、ＧＵＩを通じて、ユーザからシンクロポリシーの設定を受け付け、シンクロポリシーＤＢ部１３０に登録する。
【００２２】
シンクロポリシー交換部１７０は、設定されたシンクロポリシーを指定された端末のシンクロマネージャ１００に通知し、相手方がこのシンクロポリシーを受け入れた場合には、シンクロポリシーＤＢ部１３０に登録する。また、他のシンクロマネージャ１００からシンクロポリシーを通知されると、ユーザに登録の可否を問い、登録の許可を受け付けるとシンクロポリシーＤＢ部１３０に登録する。
【００２３】
各端末は、パーソナルコンピュータ、携帯型情報装置等の一般的な情報処理装置を用いることができる。図３は、一般的な情報処理装置のハードウェア構成を示すブロック図である。ただし、各端末として用いるハードウェアはこれに限定されない。例えば、情報処理機能を備えた携帯電話等を用いるようにしてもよい。
【００２４】
図３において、情報処理装置は、プログラムにしたがって処理を行なうＣＰＵ２０１と、プログラムを格納するメモリ２０２と、入出力インターフェース２０３とを備え、さらに、入出力インターフェース２０３を介して、内部あるいは外部に、ディスプレイ等の表示装置２０４、キーボード、マウス等の入力装置２０５、補助記憶装置２０６、インターネット３００に接続するための処理を行なうネットワーク装置２０７が接続される。シンクロマネージャ１００、各種アプリケーション１０１は、メモリ２０２に格納された専用プログラムをＣＰＵ２０１が実行すること等により、端末上で動作する。
【００２５】
シンクロマネージャ１００のシンクロポリシーＤＢ部１３０には、その端末装置の用途等に応じたシンクロポリシーが登録される。
【００２６】
図４に示すように、シンクロポリシーは、ポリシーテーブル５１０と、条件テーブル５２０と、アクションテーブル５３０とから構成される。
【００２７】
ポリシーテーブル５１０は、ポリシＩＤ毎に１つ以上の条件ＩＤと１つ以上のアクションＩＤとを対応させたテーブルである。
【００２８】
条件テーブル５２０は、条件ＩＤ毎に、要求元、要求種類、要求データ条件が定められる。これらは、シンクロポリシー実行部１２０に対する要求がどこから送られてきたか、どのような種類の要求か、具体的な要求の内容の条件をそれぞれ示すものである。
【００２９】
アクションテーブル５３０は、シンクロマネージャ１００が行なうべき処理を規定するテーブルで、アクションＩＤ毎に、宛先、呼出アドレス／モジュール、呼出パラメータが定められる。すなわち、宛先および呼出アドレス／モジュールで特定される相手先に、呼出パラメータで定められる情報が送信される。
【００３０】
なお、図４は、保守員Ｘが所持する携帯端末３４０で動作するシンクロマネージャ１００のシンクロポリシーＤＢ部１３０に設定されているシンクロポリシーの例を示している。
【００３１】
本図の例では、ポリシーＩＤ：Ｐ００１で特定されるポリシーにおいて、条件ＩＤ：Ｃ００１とアクションＩＤ：Ａ００１とが対応付けられている。この場合、ある要求に対するポリシーＩＤ：Ｐ００１で特定されるポリシーの評価は以下のように行なわれる。
【００３２】
すなわち、条件ＩＤ：Ｃ００１で特定される条件データを条件テーブル５２０から抽出する。そして、ある要求が、要求元、要求種類、要求データ条件のすべてを満たすかどうかを判断する。この場合、ある要求の要求元が自端末で動作しているスケジュールアプリケーションであり、要求種類がスケジュール問い合わせであり、問い合わせユーザ名がＣ社担当保守員グループに含まれ、かつ、問い合わせデータ名がＣ社訪問スケジュールである場合に、条件ＩＤ：Ｃ００１が満たされることになる。条件ＩＤ：Ｃ００１が満たされている場合には、ポリシーＩＤ：Ｐ００１で特定されるポリシーで条件ＩＤに対応付けられたアクションＩＤに対応するアクションデータをアクションテーブル５３０から抽出して、そのアクションを実行する。なお、Ｃ社担当保守員グループに含まれるユーザ名等の条件判断に必要な情報は、あらかじめアプリケーションデータ変換部１１１に設定しておくことができる。
【００３３】
以上の評価を、ポリシーテーブル５１０に登録されたすべてのポリシーについて行なうことになる。
【００３４】
また、図５は、保守サービス会社Ａの保守員訪問管理システム３１０上で動作するシンクロマネージャ１００のシンクロポリシーＤＢ部１３０に設定シンクロポリシーの例であり、図６は、保守員Ｙが所持する携帯端末３５０で動作するシンクロマネージャ１００のシンクロポリシーＤＢ部１３０に設定されているシンクロポリシーの例を示している。そして、図７は、クライアントである会社Ｃの訪問者受付システム３３０上で動作するシンクロマネージャ１００のシンクロポリシーＤＢ部１３０に設定シンクロポリシーの例である。このように、シンクロポリシーは、各端末毎に、その端末の使用目的等に応じた設定を行なうことができる。
【００３５】
つぎに、シンクロポリシー実行部１２０の処理について図８のフロー図を参照して説明する。
【００３６】
シンクロポリシー実行部１２０は、要求を受け付けて、その要求に対応した処理を行なう。この要求は、自端末のアプリケーション１０１から送られる場合と、他の端末のシンクロマネージャ１００から送られる場合とがある。また、要求に対応した処理は、自端末のアプリケーション１０１に対して処理の内容を示したデータを送る場合と、他の端末のシンクロマネージャ１００に対して処理の内容を示したデータを送る場合とがあり、これは、実行するアクションテーブル５３０の宛先により定められる。
【００３７】
自端末のアプリケーション１０１から要求が送られる場合は、アプリケーションデータ制御部１１０を介して要求を受け付ける。また、他の端末のシンクロマネージャ１００から要求が送られる場合は、アプリケーションデータ送受信部１４０を介して要求を受け付ける。
【００３８】
自端末のアプリケーション１０１に対して処理の内容を示したデータを送る場合は、アプリケーションデータ制御部１１０を介してデータを送信する。また、他の端末のシンクロマネージャ１００に対して処理の内容を示したデータを送る場合は、アプリケーションデータ送受信部１４０を介してデータを送信する。この場合、他の端末のシンクロマネージャ１００にとっては、要求が送られることになる。
【００３９】
本処理は、シンクロポリシー実行部１２０が、要求を受け付けることにより開始される（Ｓ１０１）。
【００４０】
シンクロポリシー実行部１２０は、シンクロポリシーＤＢ部１３０のポリシーテーブル５１０に設定されているポリシーデータを順番に選択する（Ｓ１０２）。そして、要求の内容が、選択されたポリシーデータの条件ＩＤで特定される条件データの要求元、要求種類、要求データ条件のすべてを満たすかどうかを判断する（Ｓ１０３）。このとき、条件判断に位置情報が必要である場合には、位置情報取得部１５０に問い合わせて自端末の位置情報を取得して条件判断を行なう。
【００４１】
要求の内容が、ポリシーデータの条件ＩＤで特定される条件データを満たさない場合には（Ｓ１０３：Ｎ）、ポリシーテーブル５１０に、つぎのポリシーデータがあるかどうかを調べ（Ｓ１０７）、ある場合には、そのポリシーデータを選択して（Ｓ１０２）、同様の処理を行なう。一方、つぎのポリシーデータがない場合には、本処理を終了する。
【００４２】
要求の内容が、ポリシーデータの条件ＩＤで特定される条件データのすべてを満たす場合には（Ｓ１０３：Ｙ）、対応するアクションＩＤで特定されるアクションデータをアクションテーブル５３０から抽出する（Ｓ１０４）。アクションＩＤが複数設定されている場合には、すべてのアクションデータを抽出する。
【００４３】
そして、抽出されたアクションデータにしたがった処理を行なう（Ｓ１０５）。具体的には、宛先で示された相手先（例えば、自端末のアプリケーション、他の端末のシンクロマネージャ）の呼出アドレス／モジュールに対して、呼出パラメータで示された情報を送信する。このとき、処理に位置情報が必要である場合には、位置情報取得部１５０に問い合わせて自端末の位置情報を取得して処理を行なう。
【００４４】
送信した情報を相手先が受領した場合には（Ｓ１０６：Ｙ）、上述のように、つぎのポリシーデータがあるかどうかの判断を行なう（Ｓ１０７）。送信した情報を相手先が受領できなかった場合には（Ｓ１０６：Ｎ）、所定時間経過後に再度送信するようにする。
【００４５】
上記シンクロマネージャ１００を備えた端末間の具体的な処理の例を図９に示したシーケンス図を参照して説明する。
【００４６】
保守員Ｘの携帯端末３４０上と保守員Ｙの携帯端末３５０上には、アプリケーション１０１として、訪問スケジュール管理アプリケーションがそれぞれ動作しているものとする。
【００４７】
本処理では、保守員Ｘが、クライアント会社Ｃを担当している保守員の最新の訪問スケジュールを取得して、訪問スケジュールを変更した場合を例とする。
【００４８】
まず、保守員Ｘが、訪問スケジュール管理アプリケーション上で、クライアント会社Ｃを担当している保守員の訪問スケジュールを問い合わせる。
【００４９】
すると、携帯端末３４０の訪問スケジュール管理アプリケーションは、シンクロマネージャ１００に対して、クライアント会社Ｃを担当している保守員の訪問スケジュールを問い合わせ要求を行なう（４１０ａ）。
【００５０】
携帯端末３４０のシンクロマネージャ１００のアプリケーションデータ制御部１１０は、アプリケーションデータ変換部１１１を介して、この要求を取得し、シンクロポリシー実行部１２０に通知する。
【００５１】
この要求は、図４に示した条件ＩＤ：Ｃ００１に規定された条件を満たすため、シンクロポリシー実行部１２０は、ポリシーＩＤ：Ｐ００１のポリシーデータにしたがい、アクションＩＤ：Ａ００１に規定された処理を行なう。すなわち、保守員訪問管理システム３１０のシンクロマネージャ１００に対して、呼出アドレス／モジュールとしてｓｙｎｃｓｒｖ．ａｂｃ．ｃｏ．ｊｐ／ｏｐｅｒａｔｉｏｎ＿ｃｅｎｔｅｒを指定し、呼出パラメータを｛オペレーション名＝ｑｕｅｒｙ｝＆｛ユーザ名＝アプリ指定｝＆｛暗号化フラグ＝ＯＮ｝として要求を行なう（４１０ｂ）。
【００５２】
保守員訪問管理システム３１０のシンクロマネージャ１００は、この要求が、図５に示した条件ＩＤ：Ｃ００１に規定された条件を満たすと判断し、シンクロポリシー実行部１２０が、ポリシーＩＤ：Ｐ００１のポリシーデータにしたがい、アクションＩＤ：Ａ００１に規定された処理を行なう。すなわち、自端末で動作するアプリケーションのｓｃｈｅｄｕｌｅｒモジュールに対してスケジュールを問い合わせ（４１０ｃ）、クライアント会社Ｃを担当している保守員の訪問スケジュールを取得する（４１０ｄ）。
【００５３】
そして、保守員訪問管理システム３１０のシンクロマネージャ１００は、この応答に対応するシンクロポリシーにしたがって保守員Ｘの携帯端末３４０のシンクロマネージャ１００に対してクライアント会社Ｃを担当している保守員の訪問スケジュールを送信する（４１０ｅ）。
【００５４】
携帯端末３４０のシンクロマネージャ１００は、受信した要求に対応するシンクロポリシーにしたがって、自端末で動作する訪問スケジュール管理アプリケーションに、受信したクライアント会社Ｃを担当している保守員の訪問スケジュールを送る（４１０ｆ）。
【００５５】
これにより、携帯端末３４０を使用する保守員Ｘは、クライアント会社Ｃを担当している保守員の最新の訪問スケジュールを訪問スケジュール管理アプリケーション上で確認することができる。
【００５６】
つぎに、携帯端末３４０を使用する保守員Ｘが、訪問スケジュール管理アプリケーション上で訪問スケジュールの変更をすると、訪問スケジュール管理アプリケーションは、携帯端末３４０のシンクロマネージャ１００に要求を送る（４２０ａ）。その後は、上述と同様にして、携帯端末３４０のシンクロマネージャ１００および保守員訪問管理システム３１０のシンクロマネージャ１００がそれぞれのシンクロポリシーにしたがって処理を行なうことで、保守員訪問管理システム３１０が管理するクライアント会社Ｃを担当している保守員の訪問スケジュールが更新される（４２０ｂ〜４２０ｆ）。
【００５７】
また、保守員訪問管理システム３１０のシンクロマネージャ１００は、保守員Ｘの携帯端末３４０のシンクロマネージャ１００からのスケジュール変更要求に対応して、保守員Ｘの携帯端末３５０のシンクロマネージャ１００に対してスケジュール変更要求を送る（４３０ａ）。保守員Ｘの携帯端末３５０のシンクロマネージャ１００は、この要求に対応して、携帯端末３５０上で動作する訪問スケジュール管理アプリケーションのスケジュールを変更する（４３０ｂ〜４３０ｄ）。
【００５８】
さらに、保守員Ｘの携帯端末３５０のシンクロマネージャ１００は、保守員訪問管理システム３１０のシンクロマネージャ１００からのスケジュール変更要求に対応して、クライアント会社Ｃの訪問者受付システム３３０のシンクロマネージャ１００に対してスケジュール変更要求を送る（４４０ａ）。この要求に対応して、シンクロマネージャ１００は、訪問者受付システム３３０が管理する訪問者受付スケジュールを変更する（４４０ｂ〜４４０ｄ）。
【００５９】
図１０は、上記処理で用いられるデータ内容の一例を示している。図１０（ａ）は、訪問スケジュール管理アプリケーションが保持しているスケジュール変更前のデータの例で、図１０（ｂ）が変更後のデータの例である。そして、図１０（ｃ）は、シンクロマネージャ１００間で渡されるスケジュール変更要求の例である。本例では、スケジュール変更要求は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で記述されているが、これに限られるものではない。
【００６０】
このように、本発明によると保守員の急なスケジュール変更を他の保守員や訪問先のスケジュールに反映することができ、各装置のアプリケーションがそれぞれ管理する個人データの整合性を保つことができるようになる。
【００６１】
また、他の具体的な処理の例を、図１１のシーケンス図を参照して説明する。
【００６２】
本処理では、コンタクト情報の同期を行なう場合を例にする。本例では、保守員Ｙの携帯端末３５０上でコンタクト情報管理アプリケーションが動作しているものとする。
【００６３】
保守員Ｙが、訪問先に到着後、携帯端末３５０を用いてクライアント会社Ｃの訪問者受付システム３３０に接続すると、訪問者受付アプリケーションが処理を開始する。
【００６４】
クライアント会社Ｃの訪問者受付システム３３０の訪問者受付アプリケーションが、シンクロマネージャ１００に、保守員Ｙのコンタクト情報の同期を要求すると（４５０ａ）、シンクロマネージャ１００は、保守員Ｙの携帯端末３５０のシンクロマネージャ１００に要求を転送する（４５０ｂ）。これは、例えば、以下のようなポリシーを実行することにより実現することができる。
【００６５】
条件：要求元＝受付アプリ、要求種類＝コンタクト情報取得、要求データ条件＝保守員ＹがＣ社対応保守員グループに属す。アクション１：宛先＝保守員Ｙのコンタクト管理アプリ、呼出アドレス＝ｓｙｎｃｓｒｖ．ａｂｃ．ｃｏ．ｊｐ／ｌｉｓｔ／Ｃｌｉｅｎｔ−Ｃ、呼出パラメータ＝｛オペ名＝ｑｕｅｒｙ｝＆｛ユーザ名＝取得ユーザＩＤ｝。アクション２：宛先＝Ｃ社担当者Ｚのコンタクト情報管理アプリ、呼出アドレス＝ｓｙｎｓｒｖ．Ｃ−Ｃｏｍｐａｎｙ．ｃｏ．ｊｐ／Ａｄｍｉｎ、呼出パラメータ＝｛オペ名＝ｎｏｔｉｆｙ｝＆｛ユーザ名＝取得ユーザＩＤ｝。なお、アクション２はアクション１が完了した後に実行する。
【００６６】
保守員Ｙの携帯端末３５０のシンクロマネージャ１００は、コンタクト情報管理アプリケーションからコンタクト情報を取得し（４５０ｃ〜４５０ｄ）、取得したコンタクト情報を訪問者受付システム３３０に送信する（４５０ｅ〜４５０ｆ）。これは、例えば、以下のようなポリシーを実行することにより実現することができる。
【００６７】
条件：要求元＝受付アプリ、要求種類＝コンタクト情報取得、要求データ条件＝取得ユーザがＣ社対応保守員グループに属す。アクション：宛先＝自端末のコンタクト情報管理アプリ、呼出モジュール＝ＣｏｎｔａｃｔＡｐｐ、呼出パラメータ＝｛オペ名＝ｑｕｅｒｙ｝＆｛ユーザ名＝取得ユーザＩＤ｝。
【００６８】
図１２は、このときのコンタクト情報の一例を示す図である。本例では、コンタクト情報は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で記述されているが、これに限られるものではない。
【００６９】
さらに、訪問者受付システム３３０のシンクロマネージャ１００は、担当者Ｚのデスクトップ端末３６０のシンクロマネージャ１００にコンタクト情報を伝え（４６０ａ）、このシンクロマネージャ１００が担当者Ｚのデスクトップ端末３６０で動作するコンタクト情報管理アプリケーションに保守員Ｙからのコンタクト情報を設定する（４６０ｂ〜４６０ｄ）。これは、例えば、以下のようなポリシーを実行することにより実現することができる。
【００７０】
条件：要求元＝受付アプリ、要求種類＝コンタクト情報通知、要求データ条件＝通知ユーザがＣ社対応保守員グループに属す。アクション：宛先＝自端末のコンタクト情報管理アプリ、呼出モジュール＝ＡｄｄｒｅｓｓＭａｎａｇｅｒ、呼出パラメータ＝｛オペ名＝ｎｏｔｉｆｙ｝＆｛ユーザ名＝取得ユーザＩＤ｝。
【００７１】
このように、本発明によると変更された保守員のコンタクト情報を訪問先のシステムおよび担当者に伝えることができ、各装置のアプリケーションがそれぞれ管理する個人データの整合性を保つことができるようになる。
【００７２】
つぎに、端末におけるシンクロポリシーの設定および端末間でのシンクロポリシーの交換について説明する。
【００７３】
端末のユーザは、シンクロマネージャ１００のシンクロポリシー設定部１６０が提供するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を利用して、シンクロポリシーを設定することができる。
【００７４】
図１３に、シンクロポリシー設定部１６０が提供するＧＵＩの一例を示す。本図において、シンクロポリシー設定画面９００は、新規ポリシーを登録する「新規」ボタン９７０、登録済みポリシーを変更する「変更」ボタン９７１、登録済みポリシーを直ちに実行に移す「実行」ボタン９７２を備え、ユーザからの指示を受け付ける。
【００７５】
そして、「新規」または「変更」の内容を設定するためのシンクアプリケーション領域とシンクロ先端末／サーバ領域とを備えている。シンクアプリケーション領域は、主として条件データを定義するための領域で、シンクロ先端末／サーバ領域は、アクションデータを定義するための領域である。
【００７６】
シンクロアプリケーション領域では、アプリケーション指定欄９１０で、端末上で動作可能なアプリケーションのうちから、データ同期の対象となるアプリケーションを選択できる。ここで指定されたアプリケーションが条件データの要求元として規定される。データ同期条件入力欄９１１で、対象アプリケーションのどの範囲のデータについて同期するかを指定することができる。例えば、データ項目が特定の文字列に一致する、一致しない、一部を含む、一部を含まない等を指定することができ、複数の条件に対しては、ＡＮＤ条件とＯＲ条件で結合することができる。ここで指定された条件が条件データの要求データ条件として規定される。さらに、アクセス条件指定欄９１２で、データに対する作成、参照、変更、削除等のうちの対象とする組合せを指定することができる。ここで指定された内容が条件データの要求種類として規定される。また、暗号化指定欄９１３ではデータを送信する際に暗号化および復号化処理を行うか否かを指定することができる。
【００７７】
シンクロ先端末／サーバ領域は、同期する相手を指定する欄９２０と、端末／サーバにアクセスするエンドポイント情報を指定するアドレス情報欄９２１とを備えている。これらの欄に指定した内容がアクションデータの宛先と呼び出しアドレス／モジュールに規定される。位置情報入力欄９２２には、オプション条件として、端末／サーバの位置情報を指定することができる。位置情報は、緯度・経度情報のほか、地図上の目印となる目標物名称（交通機関、公共施設等）、物理的な位置と対応付けられた論理的な場所を表す名称（本社、支社等）を記述してもよい。さらに、認証情報指定欄９５０には、オプションとして、相手端末／サーバにアクセスする際に必要となる情報（ＩＤ・パスワード、電子証明書等）を指定するすることができる。
【００７８】
シンクロポリシー設定画面９００で、「登録」ボタン９６０のクリックを受け付けると、シンクロポリシー設定部１６０は、シンクロポリシーの登録と交換処理を行なう。
【００７９】
シンクロポリシーの登録と交換処理について、図１４のフロー図を参照して説明する。
【００８０】
シンクロポリシー設定画面９００で、「登録」ボタン９６０のクリックを受け付けると（Ｓ２０１）、シンクロポリシー設定部１６０は、設定された内容に基づいて、条件データとアクションデータとを生成し、ポリシーデータで両者を関連付けてシンクロポリシーＤＢ部１３０に登録する（Ｓ２０２）。
【００８１】
つぎに、シンクロポリシー交換部１７０がシンクロ先として指定された端末／サーバにポリシーの受け入れ要求を送る（Ｓ２０３）。
【００８２】
相手方がポリシーを受け入れると応答した場合には処理を終了する。このとき、相手方は受け入れたポリシーに応じたシンクロポリシーを生成して、シンクロポリシーＤＢ部１３０に登録する。一方、相手方が受け入れないとの応答した場合には、対応するシンクロポリシーの宛先から相手先の端末／サーバを削除する（Ｓ２０４）。なお、すべての相手方が受け入れないと応答した場合には、処理（Ｓ２０２）で登録したシンクロポリシー自体をシンクロポリシーＤＢ部１３０から削除する。
【００８３】
【発明の効果】
以上説明したように、本発明によれば、異なる装置の異なるアプリケーションに分散する個人情報の整合性を保ち、個人情報を共有化するための技術が提供される。
【図面の簡単な説明】
【図１】本発明のシステム構成の概略を示す図である。
【図２】シンクロマネージャ１００の機能構成の概略を示すブロック図である。
【図３】一般的な情報処理装置のハードウェア構成を示すブロック図である。
【図４】シンクロポリシーの構成および保守員Ｘが所持する携帯端末３４０で設定されているシンクロポリシーの例を示す図である。
【図５】保守員訪問管理システム３１０で設定されているシンクロポリシーの例を示す図である。
【図６】保守員Ｙが所持する携帯端末３５０で設定されているシンクロポリシーの例を示す図である。
【図７】会社Ｃの訪問者受付システム３３０で設定されているシンクロポリシーの例を示す図である。
【図８】シンクロポリシー実行部１２０の処理について説明するためのフロー図である。
【図９】シンクロマネージャ１００を備えた端末間の具体的な処理の例を説明するためのシーケンス図である。
【図１０】端末間の処理で用いられるデータ内容の一例を示す図である。
【図１１】シンクロマネージャ１００を備えた端末間の具体的な処理の他例を説明するためのシーケンス図である。
【図１２】コンタクト情報の一例を示す図である。
【図１３】シンクロポリシー設定部１６０が提供するＧＵＩの一例を示す図である。
【図１４】シンクロポリシーの登録と交換処理について説明するためのフロー図である。
【符号の説明】
１００…シンクロマネージャ、１０１…アプリケーション、１１０…アプリケーションデータ制御部、１１１…アプリケーションデータ変換部、１２０…シンクロポリシー実行部、１３０…シンクロポリシーＤＢ部、１４０…アプリケーションデータ送受信部、１５０…位置情報取得部、１６０…シンクロポリシー設定部、１７０…シンクロポリシー交換部、１８０…データ通信プロトコル処理部、２０１…ＣＰＵ、２０２…メモリ、２０３…入出力インターフェース、２０４…表示装置、２０５…入力装置、２０６…補助記憶装置、２０７…ネットワーク装置、３００…インターネット、３１０…保守員訪問管理システム、３２０…位置情報サービスシステム、３２０…位置情報サービスシステム、３３０…訪問者受付システム、３４０…携帯端末、３５０…携帯端末
Claims (8)
- 個人情報を扱うアプリケーションが動作する個人情報管理システムであって、前記アプリケーションと、要求を含むデータのやり取りをおこなうアプリケーションインターフェース手段と、
実行手段と、
他の個人情報管理システムの実行手段と、要求を含むデータのやり取りを行なうデータ送受信手段とを備え、
前記実行手段は、前記アプリケーションまたは外部の実行手段から要求を受け付けると、あらかじめ要求対応に定められた規則にしたがって、前記アプリケーションあるいは他の個人情報管理システムの実行手段に対して処理要求を行なうことを特徴とする個人情報管理システム。 - 請求項１に記載の個人情報管理システムにおいて、
前記あらかじめ要求対応に定められた規則を格納する格納手段をさらに備え、前記格納手段は、要求に関する条件と実行手段が行なうべき処理要求とを関連付けて記憶することを特徴とする個人情報管理システム。 - 請求項２に記載の個人情報管理システムにおいて、
前記格納手段は、要求に関する条件を複数格納しており、前記実行手段は、受け付けた要求が満たす要求に関する条件と関連付けられた実行手段が行なうべき処理要求を行なうことを特徴とする個人情報管理システム - 請求項２に記載の個人情報管理システムにおいて、
前記要求に関する条件には、要求の発信元、要求の種類が含まれ、
前記実行手段が行なうべき処理要求には、要求の宛先が含まれることを特徴とする個人情報管理システム。 - 請求項２に記載の個人情報管理システムにおいて、
前記格納手段に格納する規則の設定を受け付ける受付手段と、
受け付けた規則の設定について、要求の宛先に通知する通知手段とをさらに備えることを特徴とする個人情報管理システム。 - 請求項５に記載の個人情報管理システムにおいて、
前記受付手段は、前記通知手段が要求の宛先に通知した結果、相手側が受け入れた場合に、前記受け付けた規則の設定を前記格納手段に格納することを特徴とする個人情報管理システム。 - 請求項２に記載の個人情報管理システムにおいて、
位置情報を取得する位置情報取得手段をさらに備え、
前記格納手段が格納する前記要求に関する条件、あるいは、実行手段が行なうべき処理要求には、位置に関する情報が含まれることを特徴とする個人情報管理システム。 - 請求項１に記載の個人情報管理システムにおいて、
他の個人情報管理システムとはインターネットを介して情報のやり取りを行なうことを特徴とする個人情報管理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003137507A JP2004341818A (ja) | 2003-05-15 | 2003-05-15 | 個人情報管理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003137507A JP2004341818A (ja) | 2003-05-15 | 2003-05-15 | 個人情報管理システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004341818A true JP2004341818A (ja) | 2004-12-02 |
Family
ID=33527148
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003137507A Pending JP2004341818A (ja) | 2003-05-15 | 2003-05-15 | 個人情報管理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004341818A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010165264A (ja) * | 2009-01-16 | 2010-07-29 | Yahoo Japan Corp | 携帯端末同期システムおよび方法 |
-
2003
- 2003-05-15 JP JP2003137507A patent/JP2004341818A/ja active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010165264A (ja) * | 2009-01-16 | 2010-07-29 | Yahoo Japan Corp | 携帯端末同期システムおよび方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9565155B2 (en) | System and method for openly sharing and synchronizing information across a plurality of mobile client application computers | |
| EP1220510B1 (en) | Method and system for context-aware network policy determination and enforcement | |
| JP5162505B2 (ja) | 環境対話式のコンテキスト指向デバイス、および、方法 | |
| JP4932861B2 (ja) | 分散情報アクセスシステム、分散情報アクセス方法及びプログラム | |
| JP2003532210A (ja) | コンテキスト認識型のコンピューティングデバイスおよび方法 | |
| JP2004506964A (ja) | 階層ツリー構造を利用するコンテキスト認識型のシステムおよび方法 | |
| JP2000032033A (ja) | 情報交換方法、情報管理流通装置、情報管理装置、情報流通装置、情報管理流通プログラムを記録したコンピュータ読み取り可能な記録媒体、情報管理プログラムを記録したコンピュータ読み取り可能な記録媒体及び情報流通プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| KR20120105583A (ko) | 통신 시스템에서 소셜 네트워크 서비스의 컨텐츠를 공유하기 위한 장치 및 방법 | |
| JP2004252723A (ja) | 出退勤管理装置及び出退勤管理システム | |
| JP2010086080A (ja) | 分散情報連携システム及び分散情報連携方法 | |
| US20060165106A1 (en) | Contact information management apparatus and method for managing contact information | |
| JP2002073561A (ja) | 通信網を介してアクセスするユーザの認証方法及び認証システム、並びに、これらを利用した情報処理システム | |
| JP2014013492A (ja) | 情報処理システム、情報処理装置、デバイス選択方法およびプログラム | |
| CA2456134C (en) | Method for registering and searching user's position information, and system thereof | |
| JP6442587B1 (ja) | 情報管理システム、情報管理方法及びプログラム | |
| JP2009116459A (ja) | 携帯端末、スケジュール通知システム、スケジュール通知方法、及びスケジュール通知プログラム | |
| JP2009181334A (ja) | 情報管理代行装置、サービス提供システムおよびサービス提供方法 | |
| JP6662517B1 (ja) | 知的財産情報管理サーバ、知的財産情報管理システム、知的財産情報管理方法および知的財産情報管理プログラム | |
| JP6652267B1 (ja) | 遠隔診療支援装置、システム、方法及びプログラム | |
| JP2023073488A (ja) | 遠隔診療支援装置、方法及びプログラム | |
| JP2004341818A (ja) | 個人情報管理システム | |
| US20030163535A1 (en) | Bedside communication system | |
| JP2001325368A (ja) | 医療データ配送システム | |
| JP2005184151A (ja) | 通信システム、端末装置、サーバ及び通信方法 | |
| JP2018190208A (ja) | 在宅訪問支援システム |