(57)【要約】【課題】本発明は、オープンＡＰＩにおいて、エラーが生じにくくさせ、負担を軽減することを目的とする。【解決手段】通信装置から、所定のサービスの提供を受けるためのＵＲＬ情報を含むメッセージを受信する受信部と、ＵＲＬ情報におけるパス階層と当該パス階層に含まれるキーワードによってサービスを特定する第１情報及び当該サービスの利用可能状況を示す第２情報を含むプロパティを参照して、受信されたＵＲＬ情報に対応するサービスを特定するサービス特定部と、プロパティを参照して、特定されたサービスが利用可能か否か判定する開閉局判定部と、サービスが利用可能であると判定された場合に、特定されたサービスに対応するＡＰＩを介して、ＵＲＬ情報に対する応答情報を取得するＡＰＩ処理部と、取得した応答情報に応じたメッセージを通信装置へ送信する送信部と、を含む情報管理装置が提供される。【選択図】図３
2019016138.tif 000002
【特許請求の範囲】
【請求項１】
通信装置から、所定のサービスの提供を受けるためのＵＲＬ情報を含むメッセージを受信する受信部と、
ＵＲＬ情報におけるパス階層と当該パス階層に含まれるキーワードによってサービスを特定する第１情報及び当該サービスの利用可能状況を示す第２情報を含むプロパティを参照して、前記受信されたＵＲＬ情報に対応するサービスを特定するサービス特定部と、
前記プロパティを参照して、前記特定されたサービスが利用可能か否か判定する開閉局判定部と、
前記サービスが利用可能であると判定された場合に、前記特定されたサービスに対応するＡＰＩを介して、前記ＵＲＬ情報に対する応答情報を取得するＡＰＩ処理部と、
前記取得した応答情報に応じたメッセージを前記通信装置へ送信する第１送信部と、
を含む情報管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報管理装置に関する。
【背景技術】
【０００２】
近年、オープンＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を用いた、あるアプリケーションの機能や管理するデータ等を他のアプリケーションから呼び出して利用することへの注目が高まっている。例えば、わが国の銀行界においても、現在、多数の銀行がオープンＡＰＩの活用可能性について検討を開始している（非特許文献１参照）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】一般社団法人全国銀行協会、「オープンＡＰＩのあり方に関する検討会報告書―オープン・イノベーションの活性化に向けて―［中間的な整理（案）］、［ｏｎｌｉｎｅ］、［平成２９年６月２３日検索］、インターネット＜ＵＲＬ：  ｈｔｔｐｓ：／／ｗｗｗ．ｚｅｎｇｉｎｋｙｏ．ｏｒ．ｊｐ／ｆｉｌｅａｄｍｉｎ／ｒｅｓ／ｎｅｗｓ／ｎｅｗｓ２９０３１６＿２．ｐｄｆ＞
【発明の概要】
【発明が解決しようとする課題】
【０００４】
オープンＡＰＩにおいては、オープンＡＰＩにアクセスしないと、そのオープンＡＰＩが利用可能かどうかわからず、無用なアクセスを処理する必要があった。
【０００５】
本発明の目的の一つは、利用可能でないオープンＡＰＩへの無用なアクセスを低減させることにある。
【課題を解決するための手段】
【０００６】
本発明の一実施形態によると、通信装置から、所定のサービスの提供を受けるためのＵＲＬ情報を含むメッセージを受信する受信部と、ＵＲＬ情報におけるパス階層と当該パス階層に含まれるキーワードによってサービスを特定する第１情報及び当該サービスの利用可能状況を示す第２情報を含むプロパティを参照して、前記受信されたＵＲＬ情報に対応するサービスを特定するサービス特定部と、前記プロパティを参照して、前記特定されたサービスが利用可能か否か判定する開閉局判定部と、前記サービスが利用可能であると判定された場合に、前記特定されたサービスに対応するＡＰＩを介して、前記ＵＲＬ情報に対する応答情報を取得するＡＰＩ処理部と、前記取得した応答情報に応じたメッセージを前記通信装置へ送信する第１送信部と、を含む情報管理装置が提供される。
【０００７】
前記情報管理装置は、前記サービスが利用不可能であると判定された場合に、あらかじめ規定した情報に応じたメッセージを前記通信装置に送信する第２送信部をさらに含んでもよい。
【０００８】
前記プロパティは更新可能であってもよい。
【０００９】
少なくとも前記第２情報が更新可能であってもよい。
【００１０】
前記プロパティは、複数のサービスに対する前記第１情報を含み、前記複数のサービスには優先順位が設定され、前記サービス特定部は，前記優先順位に従って、前記受信されたＵＲＬ情報に対応するサービスを特定してもよい。
【００１１】
前記サービス特定部は、前記受信されたＵＲＬ情報と、前記第１情報が特定するサービスとを前記優先順位に従った順に照合し、前記受信されたＵＲＬ情報に対応するサービスが特定されると前記照合を終了してもよい。
【００１２】
前記通信装置は、ユーザ端末であってもよい。
【００１３】
前記通信装置は、前記情報管理装置へのアクセスの認可をユーザ端末から受けたサービスプロバイダであってもよい。
【００１４】
前記アクセスの認可はＯＡｕｔｈを用いて行われてもよい。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施形態に係る情報管理システムの構成を示す図である。
【図２】本発明の一実施形態に係るＯＡｕｔｈ認証の概略に関するフローチャートである。
【図３】本発明の一実施形態に係る情報管理処理機能を示すブロック図である。
【図４】本発明の一実施形態に係る記憶情報とそれを提供するプログラムのＡＰＩを示すサービス提供ＵＲＬの対応表である。
【図５】本発明の一実施形態に係るＵＲＬマッチング情報と、ＵＲＬ開閉局情報を含むプロパティを示す図である
【図６】本発明の一実施形態に係る、一時的に情報管理装置が情報を提供できないことを示す情報の図である。
【図７】本発明の一実施形態に係る情報管理装置において実行される情報管理処理を示すフローチャートである。
【図８】本発明の一実施形態に係る照合処理についてのフローチャートである。
【発明を実施するための形態】
【００１６】
以下、本発明の一実施形態について、図面を参照しながら説明する。以下に示す実施形態は本発明の実施形態の一例であって、本発明はこれらの実施形態に限定されるものではない。なお、本実施形態で参照する図面において、同一部分または同様な機能を有する部分には同一の符号または類似の符号（数字の後にＡ、Ｂなどを付しただけの符号）を付し、その繰り返しの説明は省略する場合がある。また、図面の寸法比率は説明の都合上実際の比率とは異なったり、構成の一部が図面から省略されたりする場合がある。
【００１７】
＜実施形態＞
本発明の実施形態に係る情報管理装置１０を含む情報管理システム１について、図面を参照しながら詳細に説明する。
【００１８】
［概要］
図１は、本発明の実施形態に係る情報管理装置１０を含む情報管理システム１の構成を示す図である。情報管理システム１は、情報管理装置１０と、ユーザ端末２０と、サービスプロバイダ３０とを有する。情報管理装置１０と、ユーザ端末２０と、サービスプロバイダ３０とは、インターネット、通信回線などのネットワーク４０に接続されている。情報管理装置１０は、情報管理サービスを提供するサーバ装置であり、ネットワーク４０に接続し、ユーザ端末２０、サービスプロバイダ３０と通信可能である。情報管理装置１０は、情報管理サービスをユーザ端末２０またはサービスプロバイダ３０に提供する。このユーザ端末２０はログインによる認証を経ており、サービスプロバイダ３０は、この認証を経たユーザ端末２０から情報管理サービスへのアクセスの認可を受けている。情報管理装置１０とサービスプロバイダ３０の通信は、情報管理装置の提供するＡＰＩを用いることで行われる。
【００１９】
ユーザ端末２０は、通信機能を有する情報処理装置である。ユーザ端末２０としては、例えば、パーソナルコンピュータ、タブレット端末又はスマートフォンが挙げられる。ユーザ端末２０には、Ｗｅｂブラウザがインストールされている。ネットワークへのアクセスは、Ｗｅｂブラウザを介して行われる。Ｗｅｂブラウザ上では、アクセス先のＷｅｂサービス用のＪａｖａｓｃｒｉｐｔ（登録商標）によるアプリケーションが動作する。このアプリケーションは、アクセス先からユーザ端末２０に送信される。
【００２０】
サービスプロバイダ３０は、ユーザ端末２０を利用するユーザに向けたＷｅｂサービスを提供するサーバ装置である。
【００２１】
図１に示す情報管理装置１０、ユーザ端末２０、サービスプロバイダ３０、ネットワーク４０を用いて、例えば、次のような処理を実現することができる。ユーザ端末２０を操作するユーザが、サービスプロバイダ３０のＷｅｂサービスと情報管理装置１０の情報管理サービスに登録し、これら各サービスを利用することが出来る。後述するが、情報管理装置１０の情報管理サービスは所定の条件を満たした場合に、記憶された情報を提供するサービスである。ここでは、情報管理装置１０が提供する情報管理サービスは、銀行が提供する情報管理サービスであって、所定の条件を満たした場合に、記憶されたユーザに関する情報、例えば、残高情報を提供するサービスである。サービスプロバイダ３０が提供するＷｅｂサービスは、家計簿をユーザ端末上で作成することができるアプリケーションサービスである。例えば、このユーザは、サービスプロバイダ３０が提供するＷｅｂサービスと、情報管理装置１０が提供する情報管理サービスを連携させて、情報管理装置１０から提供された残高に関する情報を、情報管理サービスからアプリケーションサービスに提供し、その情報をもとに家計簿を作成させることができる。各サービス間の連携には、Ｗｅｂサービス用のＡＰＩが利用される。
【００２２】
［情報管理装置のハードウエア構成］
図１に示すように、情報管理装置１０は、制御部１１、記憶部１２、及び通信部１３を備える。制御部１１は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などの演算処理回路を有する。制御部１１は、記憶部１２に記憶されたプログラムをＣＰＵにより実行して、プログラムに対応した機能を情報管理装置において実現させる。
【００２３】
記憶部１２は、ハードディスク、半導体メモリ等のメモリデバイスによって構成される記憶装置である。記憶部１２は、ＲＯＭ（Ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）を含んでもよい。記憶部１２には、制御部１１によって実行される各種プログラムが記憶されている。記憶部１２に記憶されているプログラムには、例えば、後述する情報管理処理を実現するためのプログラムが含まれる。各プログラムは、磁気記録媒体、光記録媒体、光磁気記録媒体、半導体メモリなどのコンピュータ読み取り可能な記録媒体に記憶した状態で提供されてもよい。また、各プログラムは、ネットワーク４０経由で情報管理装置にダウンロードされてもよい。
【００２４】
通信部１３は、制御部１１の制御によりネットワーク４０と接続して、ユーザ端末、サービスプロバイダ等の外部装置と情報の送受信を行う。送受信される情報には、リクエストメッセージおよびレスポンスメッセージが含まれる。この例では、使用されるプロトコルは、ＨＴＴＰｓである。
【００２５】
［ＯＡｕｔｈ認証］
本実施形態では、サービスプロバイダ３０が、情報管理装置１０にリクエストメッセージを送る。情報管理装置１０は、情報管理サービスを、サービスプロバイダ３０に提供する。このサービスプロバイダ３０は、ログインによる認証を経たユーザ端末２０から情報管理サービスへのアクセスの認可を受けている。このアクセスの認可は、ＯＡｕｔｈ認証をはじめとする公知の方法によって行われる。サービスプロバイダ３０がＷｅｂサービスを提供し、情報管理装置１０が情報管理サービスを提供するときの、ユーザ端末２０がＯＡｕｔｈ認証によってＷＥＢサービスに対し情報管理サービスへのアクセスを認可する方法の概略について図２を用いて説明する。
【００２６】
図２は、本発明の一実施形態に係るＯＡｕｔｈ認証の概略に関するフローチャートである。ユーザ端末２０において、ユーザは、Ｗｅｂブラウザを起動させ、Ｗｅｂブラウザに、ユーザ端末２０の操作部を介して所定の操作を入力する。例えば、ユーザは、Ｗｅｂブラウザに、サービスプロバイダ３０（Ｗｅｂサービス）へのアクセス操作を入力する。Ｗｅｂブラウザは、サービスプロバイダ３０（Ｗｅｂサービス）のＵＲＬに従い、サービスプロバイダ３０にアクセスする。ユーザ端末２０では、Ｗｅｂサービスのサービス画面がＷｅｂブラウザに表示される。Ｗｅｂブラウザでは、Ｗｅｂサービス用のＪａｖａＳｃｒｉｐｔによるアプリケーションが実行される。Ｗｅｂサービス用のＪａｖａＳｃｒｉｐｔは、例えば、Ｗｅｂブラウザがサービスプロバイダ３０にアクセスしたときにダウンロードされるようにしてもよい。
【００２７】
次に、ユーザは、Ｗｅｂブラウザに対して、ＯＡｕｔｈ認証の操作を行う。これに伴い、ユーザ端末２０がＯＡｕｔｈ認証開始要求をサービスプロバイダ３０に送信する（Ｔ１）。ＯＡｕｔｈ認証開始要求に応じて、サービスプロバイダ３０は、ＯＡｕｔｈ認証開始応答をユーザ端末２０に送信する（Ｔ２）。ＯＡｕｔｈ認証開始応答は、情報管理装置１０に対応する認証用のＵＲＩを含む。ユーザ端末２０は、情報管理サービスの認証画面の送信要求を、ＯＡｕｔｈ認証開始応答に含まれるＵＲＩに従い、情報管理装置１０に送信する（Ｔ３）。
【００２８】
Ｔ３での送信要求に応じて、情報管理装置１０は、情報管理サービスの認証画面に対応するデータをユーザ端末に送信する（Ｔ４）。このデータを受信したユーザ端末２０は、情報管理サービス用の認証画面を、Ｗｅｂブラウザに表示する（Ｔ５）。ユーザは、ユーザ端末２０の操作部を介して、認証画面に情報処理サービスのログイン情報を入力する。ユーザ端末は、入力されたログイン情報を受け付け、そのログイン情報を情報管理装置１０に送信する（Ｔ６）。
【００２９】
情報管理装置１０は、ユーザ端末からのログイン情報に従い、認証処理を行う（Ｔ７）。ログイン情報が適切であった場合、情報管理装置１０は、承認画面に対応するデータをユーザ端末２０に送信する（Ｔ８）。承認画面に対応するデータを受信したユーザ端末２０は、承認画面をＷｅｂブラウザに表示する（Ｔ９）。承認画面は、情報管理装置１０のＡＰＩを利用した情報への接続に対して、認可又は不認可の選択を求める画面である。承認画面は、例えば、ＯＫボタンと、キャンセルボタンを含む。ＯＫボタンは認可に関連付けられ、キャンセルボタンは不認可に関連付けられる。ユーザは、ユーザ端末２０の操作部を介して、ＯＫボタンとキャンセルボタンの何れかに対する操作を入力する。ＯＫボタンに対する操作が受け付けられた場合、ユーザ端末２０は、認可指令を情報管理装置１０に送信する（Ｔ１０）。情報管理装置１０は、認可指令に応じてリダイレクトＵＲＩに認可コードを引数として付与する（Ｔ１１）。認可コードは、情報管理装置１０が生成する情報であって、情報管理装置１０のＡＰＩを利用した情報への接続を認める認可情報である。
【００３０】
次に、情報管理装置１０は、認可コードを付与したリダイレクトＵＲＩをユーザ端末２０に送信する（Ｔ１２）。ユーザ端末２０では、Ｗｅｂブラウザにおけるアクセス先が、認可コードが付与されたＵＲＩへと移動する。このとき、ユーザ端末２０は、リダイレクトＵＲＩに引数として付与された認可コードを、サービスプロバイダ３０に送信する（Ｔ１３）。認可コードを受信したサービスプロバイダ３０は、発行要求を情報管理装置１０に送信する（Ｔ１４）。発行要求は、情報管理装置１０に対して、アクセストークンの発行を要求する指令である。アクセストークンは、情報管理装置１０における情報に接続する際に利用される認証情報である。発行要求は、Ｔ１３で受信された認可コードを含む。
【００３１】
情報管理装置１０は、Ｔ１４の発行要求に応じて、アクセストークンを発行する（Ｔ１５）。その後、情報管理装置１０は、発行したアクセストークンを、要求元であるサービスプロバイダ３０に送信する（Ｔ１６）。これにより、ＯＡｕｔｈ認証は終了する。
【００３２】
このＯａｕｔｈ認証後、ユーザ端末２０がサービスプロバイダ３０に対し、情報管理サービスにアクセスして情報を取得することを要求するリクエストメッセージを送信する（Ｔ１７）。当該リクエストメッセージを受信したサービスプロバイダ３０は、情報管理装置１０に対し、ユーザ端末２０が取得を要求する情報についてのリクエストメッセージを送信する（Ｔ１８）。
【００３３】
当該リクエストメッセージを受信した情報管理装置１０は、後述する情報管理処理を行い（Ｔ１９）、ユーザ端末２０が取得を要求する情報もしくはあらかじめ規定した情報をレスポンスメッセージとしてサービスプロバイダ３０に送信する（Ｔ２０）。
【００３４】
当該レスポンスメッセージを受信したサービスプロバイダ３０は、当該レスポンスメッセージに含まれる情報を、レスポンスメッセージとして、さらにユーザ端末２０に送信する（Ｔ２１）。
【００３５】
以上、サービスプロバイダ３０がＷｅｂサービスを提供し、情報管理装置１０が情報管理サービスを提供するときに、ユーザ端末２０がＯＡｕｔｈ認証によってＷＥＢサービスに対し情報管理サービスへのアクセスの認可をする方法の概略について説明したが、情報管理サービスへのアクセスの認可をする方法は上述の方法に限られるものではなく、他の任意の方法を使用してよい。
【００３６】
［情報管理装置の機能構成］
図３は、本発明の実施形態に係る情報管理処理機能を示すブロック図である。なお、上で述べた、ユーザ端末２０がサービスプロバイダ３０に対して行う、情報管理サービスへのアクセスの認可をするための機能構成については省略する。
【００３７】
情報記憶部１０１は、情報（以下「記憶情報」）を記憶する。情報記憶部１０１は記憶情報を複数記憶している。たとえば、記憶情報にはユーザの振込入金明細、入出金明細、残高、振込申請に関する情報が含まれるが、これに限られず任意の情報が含まれてよい。
【００３８】
情報提供部１０３は、記憶情報を提供するプログラムを有し、サービス提供ＵＲＬ２０９によって示されるＡＰＩを提供する。後述するように、記憶情報を提供するプログラムのＡＰＩを示すサービス提供ＵＲＬ２０９が開局状態（当該プログラムが利用可能）か、閉局状態（当該プログラムが利用不可能）かが、ＵＲＬ開閉局情報２０５によって決せられる。
【００３９】
図４は、本実施形態における、記憶情報と、記憶情報を提供するプログラムのＡＰＩを示すサービス提供ＵＲＬ２０９の対応表である。
【００４０】
図４の対応表において、振込入金明細に関する記憶情報を提供するプログラムのＡＰＩを示すサービス提供ＵＲＬ２０９ａはｈｔｔｐｓ：／／［ｈｏｓｔｎａｍｅ］／ｃｏｒｐｏｒａｔｉｏｎ／ｖ１／ａｃｃｏｕｎｔｓ／｛ａｃｃｏｕｎｔ＿ｉｄ｝／ｔｒａｎｓａｃｔｉｏｎｓ／ｐａｙｍｅｎｔａｒｒｉｖａｌｓである。
【００４１】
図４の対応表において、入出金明細に関する記憶情報を提供するプログラムを提供するプログラムのＡＰＩを示すサービス提供ＵＲＬ２０９ｂはｈｔｔｐｓ：／／［ｈｏｓｔｎａｍｅ］／ｃｏｒｐｏｒａｔｉｏｎ／ｖ１／ａｃｃｏｕｎｔｓ／｛ａｃｃｏｕｎｔ＿ｉｄ｝／ｔｒａｎｓａｃｔｉｏｎｓである。
【００４２】
図４の対応表において、残高に関する記憶情報を提供するプログラムのＡＰＩを示すサービス提供ＵＲＬ２０９ｃはｈｔｔｐｓ：／／［ｈｏｓｔｎａｍｅ］／ｃｏｒｐｏｒａｔｉｏｎ／ｖ１／ａｃｃｏｕｎｔｓ／｛ａｃｃｏｕｎｔ＿ｉｄ｝である。
【００４３】
図４の対応表において、振込申請に関する記憶情報を提供するプログラムのＡＰＩを示すサービス提供ＵＲＬ２０９ｄはｈｔｔｐｓ：／／［ｈｏｓｔｎａｍｅ］／ｃｏｒｐｏｒａｔｉｏｎ／ｖ１／ｍｅ／ｔｒａｎｓｆｅｒｓである。以上、本実施形態における、記憶情報と、記憶情報を提供するプログラムのＡＰＩを示すサービス提供ＵＲＬ２０９の対応について説明したが、この対応関係は、もちろんこれに限られるものではない。
【００４４】
図３に戻って説明を続ける。本実施形態では、情報記憶部１０１及び情報提供部１０３は、情報管理装置１０の内部に含まれるものとするが、情報記憶部１０１及び情報提供部１０３は、ネットワーク４０を通じて情報管理装置１０と接続された外部の記憶装置及び情報提供装置であってもよい。
【００４５】
受信部１０５は、サービスプロバイダ３０からネットワーク４０を通じてリクエストメッセージを受信する。このリクエストメッセージは、情報管理装置１０に対し、記憶情報のいずれかを、サービスプロバイダ３０に送信することを要求するメッセージである。このリクエストメッセージはＵＲＬ情報１００を含む。ＵＲＬ情報１００は、当該送信を要求する記憶情報を特定するＵＲＬである。
【００４６】
プロパティ記憶部１０９は、プロパティ２００（図５参照）を記憶する。プロパティ２００は、外部から書き換え可能であってもよい。この外部からの書き換えは、情報管理装置１０の管理者によって行われてもよいし、プロパティ２００を書き換える時間を予約しておき、その時間が到来したときにプロパティ２００の書き換えが行われてもよい。
【００４７】
図５はプロパティ２００を示す図である。図５に示すプロパティ２００は、ＵＲＬサブマッチング情報２０３ａと、ＵＲＬサブマッチング情報２０３ｂと、ＵＲＬサブマッチング情報２０３ｃと、ＵＲＬサブマッチング情報２０３ｄと、ＵＲＬ開閉局情報２０５ａと、ＵＲＬ開閉局情報２０５ｂと、ＵＲＬ開閉局情報２０５ｃと、ＵＲＬ開閉局情報２０５ｄとを含む。このようにプロパティ２００は複数のＵＲＬサブマッチング情報２０３と、複数のＵＲＬ開閉局情報２０５を含む。プロパティ２００が含む全てのＵＲＬサブマッチング情報２０３のみからなる情報がＵＲＬマッチング情報２０１である。
【００４８】
また、ＵＲＬサブマッチング情報２０３ａはＵＲＬパス階層情報２０３ＡａとＵＲＬキーワード情報２０３Ｂａを含む。ＵＲＬサブマッチング情報２０３ｂはＵＲＬパス階層情報２０３ＡｂとＵＲＬキーワード情報２０３Ｂｂを含む。ＵＲＬサブマッチング情報２０３ｃはＵＲＬパス階層情報２０３ＡｃとＵＲＬキーワード情報２０３Ｂｃを含む。ＵＲＬサブマッチング情報２０３ｄはＵＲＬパス階層情報２０３ＡｄとＵＲＬキーワード情報２０３Ｂｄを含む。このように、各ＵＲＬサブマッチング情報２０３は、対となったＵＲＬパス階層情報２０３Ａ及びＵＲＬキーワード情報２０３Ｂを含む。
【００４９】
ＵＲＬパス階層情報２０３Ａは、ＵＲＬの特定のパス階層を示す情報である。
【００５０】
ＵＲＬキーワード情報２０３Ｂは、対となったＵＲＬパス階層情報２０３Ａの示すパス階層に規定されるキーワードを示す情報である。
【００５１】
ＵＲＬのパス階層とは、ＵＲＬの特定の位置を示す概念であり、”ｈｔｔｐｓ：／／”の後ろに位置するスラッシュ（／）の数によって、ＵＲＬの位置を特定する概念である。
【００５２】
”ｈｔｔｐｓ：／／”の直後から、スラッシュで１回区切られる位置までがパス階層１であり、そのスラッシュから次のスラッシュで区切られる位置までがパス階層２である。より深いパス階層についても同様である。なお、パス階層のうち、付された数字が大きいパス階層ほど、深いパス階層であると表現し、付された数字が小さいパス階層ほど、浅いパス階層であると表現することがある。
【００５３】
例えば、ｈｔｔｐｓ：／／［ｈｏｓｔｎａｍｅ］／ｃｏｒｐｏｒａｔｉｏｎ／ｖ１／ａｃｃｏｕｎｔｓ／｛ａｃｃｏｕｎｔ＿ｉｄ｝／ｔｒａｎｓａｃｔｉｏｎｓ／ｐａｙｍｅｎｔａｒｒｉｖａｌｓとのＵＲＬを例にとると、［ｈｏｓｔｎａｍｅ］と規定される位置がパス階層１である。ｃｏｒｐｏｒａｔｉｏｎと規定される位置がパス階層２である。ｖ１と規定される位置がパス階層３である。ａｃｃｏｕｎｔｓと規定される位置がパス階層４である。｛ａｃｃｏｕｎｔ＿ｉｄ｝と規定される位置がパス階層５である。ｔｒａｎｓａｃｔｉｏｎｓと規定される位置がパス階層６である。ｐａｙｍｅｎｔａｒｒｉｖａｌｓと規定される位置がパス階層７である。一番深いパス階層はパス階層７であり、一番浅いパス階層はパス階層１である。
【００５４】
また、例えば、図５のＵＲＬサブマッチング情報２０３ａに含まれるＵＲＬパス階層情報２０３Ａａは「”ｕｒｌ＿ｃｏｎｄｉｔｉｏｎ＿ｐａｔｈ＿ｄｅｐｔｈ”：７」と規定していることから、ＵＲＬパス階層情報２０３Ａａは、パス階層７を示している。
【００５５】
対となったＵＲＬキーワード情報２０３Ｂａは「”ｕｒｌ＿ｃｏｎｄｉｔｉｏｎ＿ｋｅｙｗｏｒｄ”：”ｐａｙｍｅｎｔａｒｒｉｖａｌ”」であるから、ｐａｙｍｅｎｔａｒｒｉｖａｌとのキーワードを規定している。
【００５６】
そして、図４のサービス提供ＵＲＬ２０９ａはｈｔｔｐｓ：／／［ｈｏｓｔｎａｍｅ］／ｃｏｒｐｏｒａｔｉｏｎ／ｖ１／ａｃｃｏｕｎｔｓ／｛ａｃｃｏｕｎｔ＿ｉｄ｝／ｔｒａｎｓａｃｔｉｏｎｓ／ｐａｙｍｅｎｔａｒｒｉｖａｌｓであり、パス階層７にｐａｙｍｅｎｔａｒｒｉｖａｌｓとのキーワードが規定されている。
【００５７】
このように、サービス提供ＵＲＬ２０９が、ＵＲＬパス階層情報２０３Ａａが示すパス階層に、対となったＵＲＬキーワード情報２０３Ｂａの規定するキーワードを規定するとき、サービス提供ＵＲＬ２０９とＵＲＬサブマッチング情報２０３ａとが対応する。
【００５８】
他のＵＲＬサブマッチング情報２０３とサービス提供ＵＲＬ２０９についても同様である。例えば、図４のサービス提供ＵＲＬ２０９と図５のＵＲＬサブマッチング情報２０３では、ＵＲＬサブマッチング情報２０３ｂとサービス提供ＵＲＬ２０９ｂが対応する。また、ＵＲＬサブマッチング情報２０３ｃとサービス提供ＵＲＬ２０９ｃが対応する。また、ＵＲＬサブマッチング情報２０３ｄとサービス提供ＵＲＬ２０９ｄとがそれぞれ対応する。
【００５９】
図３に戻って説明を続ける。ＵＲＬ対応判定部１０７は、プロパティ記憶部１０９が記憶しているプロパティ２００に含まれるＵＲＬマッチング情報２０１と、ＵＲＬ情報１００について、後述する照合処理を行い、その結果、ＵＲＬ情報１００とサービス提供ＵＲＬ２０９のいずれかが対応するかについて判定する。
【００６０】
ＵＲＬ対応判定部１０７がＵＲＬ情報１００とサービス提供ＵＲＬ２０９のいずれかが対応すると判定したとき、開閉局判定部１１１は、そのサービス提供ＵＲＬに対応するＵＲＬサブマッチング情報２０３に対になったＵＲＬ開閉局情報２０５に基づき、サービス提供ＵＲＬ２０９が開局状態か閉局状態かの判定を行う。
【００６１】
図４を見ると、プロパティ２００において、ＵＲＬサブマッチング情報２０３ａの下にはＵＲＬ開閉局情報２０５ａが規定されている。同様に、ＵＲＬサブマッチング情報２０３ｂの下にはＵＲＬ開閉局情報２０５ｂが規定されている。ＵＲＬサブマッチング情報２０３ｃの下にはＵＲＬ開閉局情報２０５ｃが規定されている。ＵＲＬサブマッチング情報２０３ｄの下にはＵＲＬ開閉局情報２０５ｄが規定されている。各ＵＲＬサブマッチング情報２０３と、その直下に規定されたＵＲＬ開閉局情報２０５とはそれぞれ対となっている。ＵＲＬ開閉局情報２０５は、対となるＵＲＬサブマッチング情報に対応するサービス提供ＵＲＬ２０９が開局状態か閉局状態かを示す。
【００６２】
サービス提供ＵＲＬ２０９が開局状態であるとは、そのサービス提供ＵＲＬ２０９が示すＡＰＩで呼び出すことが可能な、情報提供部１０３が有するプログラムが利用可能であることをいう。サービス提供ＵＲＬ２０９が閉局状態であるとは、そのサービス提供ＵＲＬ２０９が示すＡＰＩで呼び出すことが可能な、情報提供部１０３が有するプログラムが利用不可能であることをいう。
【００６３】
ＵＲＬ開閉局情報２０５は、図４に示すように「”ｏｐｅｎ”：ｔｒｕｅ」と規定するときに、それが含まれるＵＲＬサブマッチング情報２０３と対応するサービス提供ＵＲＬ２０９が開局状態であることを示してもよい。また、ＵＲＬ開閉局情報２０５は、「”ｏｐｅｎ”：ｆａｌｓｅ」と規定するときに、それが含まれるＵＲＬサブマッチング情報２０３と対応するサービス提供ＵＲＬ２０９が閉局状態であることを示してもよい。
【００６４】
図３に戻って説明を続ける。開閉局判定部１１１が、サービス提供ＵＲＬ２０９について開局状態だと判定した場合、ＡＰＩ処理部１１３は、情報提供部１０３が有するプログラムを、そのサービス提供ＵＲＬ２０９の示すＡＰＩによって呼び出し、そのプログラムによって、情報記憶部１０１に記憶されている情報の提供を受ける。例えば、開閉局判定部１１１がサービス提供ＵＲＬ２０９ａについて開局状態だと判断した場合、ＡＰＩ処理部１１３は、情報提供部１０３が有するプログラムをサービス提供ＵＲＬ２０９の示すＡＰＩによって呼び出し、そのプログラムによって、情報記憶部１０１に記憶されている振込入金明細に関する情報の提供を受ける。
【００６５】
情報送信部１１５は、ＡＰＩ処理部１１３が情報提供部１０３から提供された情報を、レスポンスメッセージとしてリクエストメッセージを送信した外部装置に送信する。例えば、情報送信部１１５は、ＡＰＩ処理部１１３が取得した振込入金明細に関する情報を、サービスプロバイダ３０に、レスポンスメッセージとして送信する。
【００６６】
閉局表示送信部１１７は、開閉局判定部１１１が、サービス提供ＵＲＬ２０９について閉局状態だと判定した場合、あらかじめ規定した情報をレスポンスメッセージとしてサービスプロバイダ３０に送信する。このあらかじめ規定した情報とは、例えば、図６のように、一時的に情報管理装置１０が情報を提供できない旨を示すものであってもよい。
【００６７】
［情報管理処理］
続いて、情報管理装置における情報管理処理について説明する。
【００６８】
図７は、本発明の実施形態における情報管理装置１０において実行される、情報管理処理を示すフローチャートである。この処理は、情報管理装置１０が起動すると実行される。まず、情報管理装置１０は、ＵＲＬ情報１００を含むリクエストメッセージを受信するまで待機する（ステップＳ１０１；Ｎｏ）。ＵＲＬ情報１００を含むリクエストメッセージを受信すると（ステップＳ１０１；Ｙｅｓ）、ＵＲＬ対応判定部１０７は、ＵＲＬマッチング情報２０１と、ＵＲＬ情報１００を照合し（ステップＳ１０３）、ＵＲＬ情報１００とサービス提供ＵＲＬ２０９のいずれかが対応するかを判定する（ステップＳ１０５）。
【００６９】
図８は、ステップＳ１０３及びステップＳ１０５において、ＵＲＬ対応判定部１０７がＵＲＬ情報１００とＵＲＬマッチング情報２０１を照合し、ＵＲＬ情報１００とサービス提供ＵＲＬ２０９のいずれが対応するかの判定をどのように行うか（以下「照合処理」）についてのフローチャートである。なお、図８の説明に関しては、特に断りがない限り、ＵＲＬパス階層情報２０３ＡとＵＲＬキーワード情報２０３Ｂは対となったものを指す。
【００７０】
受信部１０５がサービスプロバイダ３０からＵＲＬ情報１００を含むリクエストメッセージを受信することで照合処理が始まる。
【００７１】
照合処理においては、まず、ＵＲＬ対応判定部１０７は、いくつかあるＵＲＬサブマッチング情報２０３の中で、最も優先度が高く設定されたＵＲＬサブマッチング情報２０３に含まれるＵＲＬパス階層情報２０３ＡとＵＲＬ情報１００を照合する（パス照合。ステップＳ３０１）。
【００７２】
本実施形態では、図５に示すプロパティ２００の上部に記されたＵＲＬサブマッチング情報２０３ほど優先度が高く、プロパティ２００の下部に記載されたＵＲＬサブマッチング情報２０３ほど優先度が低く設定されている。すなわち、ＵＲＬサブマッチング情報２０３ａに一番高い優先度が設定されており、ＵＲＬサブマッチング情報２０３ｂ、ＵＲＬサブマッチング情報２０３ｃ、ＵＲＬサブマッチング情報２０３ｄの順に優先度が低くなるように設定されている。なお、優先度の決定方法はこれに限られるものではなく、情報管理装置１０が外部装置からリクエストメッセージを受信するよりも先に優先度が決定されている限り、この優先度は任意の方法で設定してもよい。
【００７３】
パス照合の後、ＵＲＬ対応判定部１０７は、ＵＲＬ情報１００がＵＲＬパス階層情報２０３Ａの示すパス階層を有しているかを判定する（ステップＳ３０３）。
【００７４】
ＵＲＬ対応判定部１０７が、ＵＲＬ情報１００はＵＲＬパス階層情報２０３Ａの定めるパス階層を有していると判定した場合（ステップＳ３０３；Ｙｅｓ）、ＵＲＬ対応判定部１０７は、ＵＲＬキーワード情報２０３Ｂと、ＵＲＬ情報１００とを照合する（キーワード照合。ステップ３０５）。
【００７５】
ＵＲＬ対応判定部１０７が、ＵＲＬ情報１００はＵＲＬパス階層情報２０３Ａの定めるパス階層を有していないと判定した場合（ステップＳ３０３；Ｎｏ）、ステップＳ３１１に進み、ＵＲＬ対応判定部１０７は、パス照合を行ったＵＲＬサブマッチング情報２０３に対応するサービス提供ＵＲＬ２０９と、ＵＲＬ情報１００とは対応しない旨の判定をし（非対応判定。ステップＳ３１１）、後述のステップＳ３１３に進む。
【００７６】
キーワード照合（ステップＳ３０５）の後、ＵＲＬ対応判定部１０７は、ＵＲＬ情報１００が、ＵＲＬパス階層情報２０３Ａの示すパス階層に、ＵＲＬキーワード情報２０３Ｂの示すキーワードを有しているかを判定する（ステップＳ３０７）。
【００７７】
ＵＲＬ対応判定部１０７が、ＵＲＬ情報１００はＵＲＬパス階層情報２０３Ａの示すパス階層に、ＵＲＬキーワード情報２０３Ｂの示すキーワードを有していると判定した場合（ステップ３０７；Ｙｅｓ）、ＵＲＬ対応判定部１０７は、そのＵＲＬパス階層情報２０３ＡとＵＲＬキーワード情報２０３Ｂを含むＵＲＬサブマッチング情報２０３に対応するサービス提供ＵＲＬ３０９と、ＵＲＬ情報１００とが対応する旨の判定をし（対応判定。ステップＳ３０９）、照合処理を終了する。
【００７８】
ＵＲＬ対応判定部１０７が、ＵＲＬ情報１００はＵＲＬパス階層情報２０３Ａの示すパス階層にＵＲＬキーワード情報２０３Ｂの示すキーワードを有していないと判定した場合（ステップＳ３０７；Ｎｏ）、ＵＲＬ対応判定部は、そのＵＲＬパス階層情報２０３ＡとＵＲＬキーワード情報２０３Ｂを含むＵＲＬサブマッチング情報２０３に対応するサービス提供ＵＲＬ３０９と、ＵＲＬ情報１００とが対応しない旨の判定をする（非対応判定。ステップＳ３１１）。ＵＲＬ対応判定部１０７は、非対応判定をした後、プロパティ２００にまだパス照合をしていないＵＲＬパス階層情報２０３Ａを含むＵＲＬサブマッチング情報２０３があるかを判定し（ステップＳ３１３）、あると判定すれば（ステップＳ３１３；Ｙｅｓ）そのＵＲＬサブマッチング情報２０３の中で最も優先度の高いものについて再びステップＳ３０１からの処理を行い、ないと判定すれば（ステップＳ３１３；Ｎｏ）、照合処理を終了する。
【００７９】
以上説明した照合処理が具体的にどのように行われるかについて、受信部１０５がサービスプロバイダ３０からｈｔｔｐｓ：／／［ｈｏｓｔｎａｍｅ］／ｃｏｒｐｏｒａｔｉｏｎ／ｖ１／ａｃｃｏｕｎｔｓ／｛ａｃｃｏｕｎｔ＿ｉｄ｝／ｔｒａｎｓａｃｔｉｏｎｓ／ｐａｙｍｅｎｔａｒｒｉｖａｌｓとのＵＲＬ情報１００を含むリクエストメッセージを受信した場合を例にとって説明する。
【００８０】
まず、パス照合が行われる（ステップＳ３０１）。ＵＲＬサブマッチング情報２０３ａの優先度が最も高いため、ステップＳ３０１では、ＵＲＬ対応判定部１０７はＵＲＬパス階層情報２０３ＡａとＵＲＬ情報１００を照合する。
【００８１】
続いて、ステップＳ３０３に進む。上述のとおり、ＵＲＬパス階層情報２０３Ａａは、パス階層７を示している。そして、ＵＲＬ情報１００もパス階層７を有している。したがって、ＵＲＬ対応判定部１０７は、ＵＲＬ情報１００がＵＲＬパス階層情報２０３Ａの示すパス階層を有していると判定する（ステップＳ３０３；Ｙｅｓ）。
【００８２】
続いて、キーワード照合が行われ（ステップＳ３０５）、ステップＳ３０７に進む。上述のとおりＵＲＬパス階層情報２０３Ａａは、パス階層７を示しており、ＵＲＬキーワード情報２０３Ｂａはｐａｙｍｅｎｔａｒｒｉｖａｌとのキーワードを規定している。そして、ＵＲＬ情報１００は、パス階層７にｐａｙｍｅｎｔａｒｒｉｖａｌとのキーワードを規定している。したがって、ＵＲＬ対応判定部１０７は、ＵＲＬ情報１００が、ＵＲＬパス階層情報２０３Ａａの示すパス階層に、ＵＲＬキーワード情報２０３Ｂａの示すキーワードを有していると判定する（ステップＳ３０７；Ｙｅｓ）。
【００８３】
したがって、ステップＳ３０９に進み、ＵＲＬ対応判定部１０７は、ＵＲＬサブマッチング情報２０３ａに対応するサービス提供ＵＲＬ２０９と、ＵＲＬ情報１００とが対応する旨の判定である対応判定をし（ステップＳ３０９）、照合処理を終了する。
【００８４】
図７に戻って説明を続ける。以上述べたＵＲＬマッチング情報２０１とＵＲＬ情報１００の照合の結果、ＵＲＬ情報１００とサービス提供ＵＲＬ１０９のいずれかが対応するとＵＲＬ対応判定部１０７が判定しない場合（ステップＳ１０５；Ｎｏ）、すなわち、全てのＵＲＬサブマッチング情報２０３について非対応判定をした場合、情報管理装置１０は、再びＵＲＬ情報１００を含むリクエストメッセージを受信するまで待機する。
【００８５】
ＵＲＬ対応判定部１０７が、ＵＲＬ情報１００とサービス提供ＵＲＬ１０９のいずれかが対応すると判定した場合（ステップＳ１０５；Ｙｅｓ）、すなわち、ステップ３０９における対応判定をして照合処理を終了した場合には、開閉局判定部１１１は、そのサービス提供ＵＲＬ１０９に対応するＵＲＬ開閉局情報２０５に基づき、サービス提供ＵＲＬ２０９は開局状態が閉局状態かの判定を行う（ステップＳ１０７）。
【００８６】
開閉局判定部１１１がサービス提供ＵＲＬ２０９について開局状態だと判定した場合（ステップＳ１０７；Ｙｅｓ）、ＡＰＩ処理部１１３は、情報提供部１０３が有するプログラムをそのサービス提供ＵＲＬ２０９の示すＡＰＩによって呼び出し、そのプログラムによって、情報記憶部１０１に記憶されている情報の提供を受け（ステップＳ１０９）、情報送信部１１５がこの情報をレスポンスメッセージとして、リクエストメッセージを送信した外部装置に送信し（ステップＳ１１１）、ステップＳ１０１の処理に戻る。
【００８７】
開閉局判定部１１１がサービス提供ＵＲＬ２０９について閉局状態だと判定した場合（ステップＳ１０７；Ｎｏ）、閉局表示送信部１１７は、あらかじめ規定した情報をレスポンスメッセージとして、リクエストメッセージを送信した外部装置に送信し（ステップＳ１１３）、ステップＳ１０１の処理に戻る。
【００８８】
本発明の実施形態の情報管理装置１０は上述の構成を有し、上述の動作を行う。その結果、以下のような作用効果を奏する。
【００８９】
本発明の実施形態によれば、情報管理装置１０は、ＵＲＬ情報１００をＵＲＬパス階層情報２０３ＡとＵＲＬキーワード情報２０３Ｂを含むＵＲＬサブマッチング情報２０３と照合することで、ＵＲＬ情報１００とサービス提供ＵＲＬ２０９が対応するか否かの判定をする。単にＵＲＬキーワード情報２０３ＢとＵＲＬ情報１００とを照合し、ＵＲＬ情報１００がＵＲＬキーワード情報２０３Ｂに規定するキーワードを含むかによってＵＲＬ情報１００とサービス提供ＵＲＬ２０９が対応するか否かの判定をする方法によると、ＵＲＬ情報１００とサービス提供ＵＲＬ２０９が対応するか否かの判定が誤る可能性が高い。しかし、本発明の実施形態では、それに加えてＵＲＬ情報１００とＵＲＬパス階層情報も照合しているので、ＵＲＬ情報１００とサービス提供ＵＲＬ２０９が対応するか否かの判定が誤る可能性が低い。したがって、本来提供すべきでない情報を、リクエストメッセージを送信した外部装置に送信する可能性が低い。
【００９０】
また、ＵＲＬ情報１００とＵＲＬサブマッチング情報２０３を照合し、ＵＲＬサブマッチング情報２０３がＵＲＬ情報１００の規定する情報を全て含むか否かによってＵＲＬ情報１００とサービス提供ＵＲＬ２０９が対応するか否かの判定をする方法によると、ＵＲＬ情報１００の規定する情報に可変部がある場合、あらかじめ定められたＵＲＬサブマッチング情報２０３とＵＲＬ情報１００の照合が困難である。本発明の実施形態によれば、ＵＲＬ情報１００の可変部以外を示すＵＲＬパス階層情報２０３ＡとＵＲＬキーワード情報２０３Ｂを含むＵＲＬサブマッチング情報２０３は、ＵＲＬ情報１００と照合する際、ＵＲＬ情報１００の可変部の影響を受けないため、その照合は容易である。
【００９１】
また、本発明の実施形態によれば、プロパティ２００を外部から書き換えることが可能であるから、ＵＲＬ開閉局情報２０５を書き換えることでサービス提供ＵＲＬ２０９が開局状態であるか閉局状態であるかをコントロールすることができる。また、ＵＲＬサブマッチング情報２０３ごとの優先度を変更することで、優先的に照合されるＵＲＬサブマッチング情報２０３を変更することが可能となり、これによって優先的に情報管理装置１０が提供する情報を変更することができる。
【００９２】
また、本発明の実施形態によれば、ＵＲＬサブマッチング情報２０３とＵＲＬ情報１００との照合は、ＵＲＬパス階層情報２０３ＡとＵＲＬキーワード情報２０３Ｂを用いて行われ、そのＵＲＬサブマッチング情報２０３と対応するサービス提供ＵＲＬ２０９が開局状態か閉局状態かはそのＵＲＬサブマッチング情報２０３と対応する開閉局情報２０５によって決定されるから、ＵＲＬパス階層情報２０３Ａが定めるパス階層にＵＲＬキーワード情報２０３Ｂを含むＵＲＬ情報１００と対応する全てのサービス提供ＵＲＬ２０９について、１つの開閉局情報２０５を用いて開局状態か閉局状態かをまとめてコントロールできる。
【００９３】
＜変形例１＞
実施形態では、ＵＲＬマッチング情報２０１とＵＲＬ情報１００の照合において（ステップＳ１０３）、ＵＲＬマッチング情報２０１が含むＵＲＬサブマッチング情報２０３のうち、設定された優先度が高いＵＲＬサブマッチング情報２０３から順にＵＲＬ情報１００とパス照合とキーワード照合を行うものとしたが、ＵＲＬマッチング情報２０１とＵＲＬ情報１００の照合は他の方法をとってもよい。例えば、全てのＵＲＬサブマッチング情報２０３をＵＲＬ情報１００と照合し、ＵＲＬ情報１００が、ＵＲＬパス階層情報２０３Ａの規定するパス階層に、ＵＲＬキーワード情報２０３Ｂを規定していると判定されるＵＲＬサブマッチング情報２０３はどれかを判定し、このうち、最も優先度が高く設定されたＵＲＬサブマッチング情報２０３はどれかを判定し、そのＵＲＬサブマッチング情報２０３に対応するサービス提供ＵＲＬ２０９と、ＵＲＬ情報１００とが対応する旨の判定をしてもよい。
【００９４】
＜変形例２＞
実施形態では、情報管理装置１０が提供する情報管理サービスへのアクセスの認可をユーザ端末２０から受けたサービスプロバイダ３０が、情報管理装置１０にリクエストメッセージを送り、情報管理装置１０がそれを受信するものとしていたが、ユーザ端末２０が直接、情報管理装置１０にリクエストメッセージを送り、情報管理装置１０がリクエストメッセージを受信してもよい。
【００９５】
＜変形例３＞
実施形態では、照合処理において、まずパス照合を行い、ＵＲＬ情報１００がＵＲＬパス階層情報２０３Ａの規定するパス階層を有する場合にキーワード照合を行うものとしていたが、この順序を逆にして、まずＵＲＬ情報１００とＵＲＬキーワード情報２０３Ｂを照合し、ＵＲＬ情報１００中にＵＲＬキーワード情報２０３Ｂの規定するキーワードが含まれるかを判定し、含まれると判定された場合には、そのキーワードがＵＲＬパス階層情報２０３Ａの規定するパス階層にあるかをＵＲＬ情報１００とＵＲＬキーワード情報２０３Ｂの照合によって判定し、そのキーワードがＵＲＬパス階層情報２０３Ａの規定するパス階層にある場合には、そのＵＲＬサブマッチング情報２０３に対応するサービス提供ＵＲＬ２０９と、ＵＲＬ情報１００が対応する旨の判定をしてもよい。
【符号の説明】
【００９６】
１：情報管理システム、１０：情報管理装置、１１：制御部、１２：記憶部、１３：通信部、２０：ユーザ端末、３０：サービスプロバイダ、４０：ネットワーク、１００：ＵＲＬ情報、１０１：情報記憶部、１０３：情報提供部、１０５：受信部、１０７：対応判定部、１０９：プロパティ記憶部、１１１：開閉局判定部、１１３：ＡＰＩ処理部、１１５：情報送信部、１１７：閉局表示送信部、２００：プロパティ、２０１：ＵＲＬマッチング情報、２０３：ＵＲＬサブマッチング情報、２０３Ａ：パス階層情報、２０３Ｂ：キーワード情報、２０５：開閉局情報
【図１】
2019016138.tif 000003
【図２】
2019016138.tif 000004
【図３】
2019016138.tif 000005
【図４】
2019016138.tif 000006
【図５】
2019016138.tif 000007
【図６】
2019016138.tif 000008
【図７】
2019016138.tif 000009
【図８】
2019016138.tif 000010