米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> 株式会社野村総合研究所

発明の名称 業務統合方法、業務統合装置、業務統合システムおよび業務統合プログラム
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2007−164535(P2007−164535A)
公開日 平成19年6月28日(2007.6.28)
出願番号 特願2005−360901(P2005−360901)
出願日 平成17年12月14日(2005.12.14)
代理人 【識別番号】100083806
【弁理士】
【氏名又は名称】三好 秀和
発明者 齋藤 義徳 / 甲斐澤 貴
要約 課題
複数のユーザが利用する共同利用型システムにおいて、EAIツールに対する定義変更の手間を低減し、システム運用負荷をより軽減する。

解決手段
業務統合装置5は、業務システム3を利用する複数のユーザシステム1毎にデータの宛先が設定された宛先制御テーブルと、処理部とを有し、処理部は、業務システム各々からデータを受信する受信ステップと、受信ステップで受信した受信データの発生元のユーザシステムを特定し、特定したユーザシステムに対応する宛先を宛先制御テーブルから取得する取得ステップと、取得した宛先を受信データに設定した宛先設定データを生成する生成ステップと、宛先設定データに設定された宛先を参照し、受信データを少なくとも1つの業務システムに配信する配信ステップと、を行う。
特許請求の範囲
【請求項1】
複数の業務システムを統合する業務統合装置が行う業務統合方法であって、
前記業務統合装置は、
前記業務システムを利用する複数のユーザシステム毎にデータの宛先が設定された宛先制御テーブルと、処理部と、を有し、
前記処理部は、
前記業務システム各々からデータを受信する受信ステップと、
前記受信ステップで受信した受信データの発生元のユーザシステムを特定し、特定したユーザシステムに対応する宛先を前記宛先制御テーブルから取得する取得ステップと、
前記取得した宛先を前記受信データに設定した宛先設定データを生成する生成ステップと、
前記宛先設定データに設定された宛先を参照し、前記受信データを少なくとも1つの業務システムに配信する配信ステップと、を行うこと
を特徴とする業務統合方法。
【請求項2】
請求項1記載の業務統合方法であって、
前記業務統合装置は、
前記ユーザシステムの承認が必要なデータを記憶する承認用記憶部を、さらに有し、
前記処理部は、
前記宛先設定データが前記ユーザシステムの承認が必要か否かを判別し、承認が必要な場合、前記承認用記憶部に当該宛先設定データを記憶する判別ステップと、
前記承認用記憶部に記憶された宛先設定データに対する承認指示を受け付ける承認受付ステップと、をさらに行い、
前記配信ステップは、前記承認指示を受け付けた宛先設定データを前記承認用記憶部から読み出し、当該宛先設定データに設定された宛先を参照して前記受信データを少なくとも1つの業務システムに配信すること
を特徴とする業務統合方法。
【請求項3】
複数の業務システムを統合する業務統合装置であって、
前記業務システムを利用する複数のユーザシステム毎に、データの宛先が設定された宛先制御テーブルと、
前記業務システム各々からデータを受信する受信手段と、
前記受信手段が受信した受信データの発生元のユーザシステムを特定し、特定したユーザシステムに対応する宛先を前記宛先制御テーブルから取得する取得手段と、
前記取得した宛先を前記受信データに設定した宛先設定データを生成する生成手段と、
前記宛先設定データに設定された宛先を参照し、前記受信データを少なくとも1つの業務システムに配信する配信手段と、を有すること
を特徴とする業務統合装置。
【請求項4】
複数の業務システムと、当該複数の業務システムを統合する業務統合装置と、を有する業務統合システムであって、
前記業務システム各々は、
複数のユーザシステムで発生したデータを、前記業務統合装置に送信する送信手段と、
前記業務統合装置から配信されたデータを受信する受信手段と、を有し、
前記業務統合装置は、
前記ユーザシステム毎に、データの宛先が設定された宛先制御テーブルと、
前記業務システム各々が送信したデータを受信する受信手段と、
前記受信手段が受信した受信データの発生元のユーザシステムを特定し、特定したユーザシステムに対応する宛先を前記宛先制御テーブルから取得する取得手段と、
前記取得した宛先を前記受信データに設定した宛先設定データを生成する生成手段と、
前記宛先設定データに設定された宛先を参照し、前記受信データを少なくとも1つの業務システムに配信する配信手段と、を有すること
を特徴とする業務統合システム。
【請求項5】
複数の業務システムを統合する業務統合装置が実行する業務統合プログラムであって、
前記業務統合装置は、
前記業務システムを利用する複数のユーザシステム毎にデータの宛先が設定された宛先制御テーブルと、処理部と、を有し、
前記処理部に、
前記業務システム各々からデータを受信する受信ステップと、
前記受信ステップで受信した受信データの発生元のユーザシステムを特定し、特定したユーザシステムに対応する宛先を前記宛先制御テーブルから取得する取得ステップと、
前記取得した宛先を前記受信データに設定した宛先設定データを生成する生成ステップと、
前記宛先設定データに設定された宛先を参照し、前記受信データを少なくとも1つの業務システムに配信する配信ステップと、を実行させること
を特徴とする業務統合プログラム。
発明の詳細な説明
【技術分野】
【0001】
本発明は、複数の業務システムを統合する業務統合技術に関し、特に、複数の業務システム間でデータを連携させる技術に関する。
【背景技術】
【0002】
企業における情報システムには、一般的に、各業務に応じて勘定系システム、販売系システムなど複数の業務システムが存在する。EAI(enterprise application integration)は、企業内で使用される複数の業務システムを連携させ、システム統合を行うための技術である。なお、EAIについては、例えば、非特許文献1および非特許文献2に記載されている。
【非特許文献1】八木晃二、藤岡賢治、“ハイブリットEAIモデルの技術的検討”、[online]、2001年11月、野村総合研究所、システムマンスリー、[平成17年10月20日検索]、インターネット<URL:http://www.nri.co.jp/opinion/it_solution/2001/pdf/IT20011102.pdf>
【非特許文献2】角田勝、常峰誠、小林賢治、“EAIに関する基盤技術評価”、[online]、2002年、野村総合研究所、技術創発、[平成17年10月20日検索]、インターネット<URL: http://www.nri.co.jp/opinion/g_souhatsu/pdf/gs20020103.pdf>
【発明の開示】
【発明が解決しようとする課題】
【0003】
さて、複数のユーザが共同で利用する共同利用型システムにおいて、EAIを実現するEAIツール(ミドルウェア)を用いる場合、以下の問題がある。すなわち、ユーザ毎にデータの接続先(連携先)の業務システムが異なる場合、EAIツールに対してユーザ毎にルーティング情報を定義する必要がある。また、ユーザの追加・削除あるいはユーザシステム側での変更が発生する度に、EAIツールに対してルーティング情報等の変更作業が発生する。
【0004】
このようなEAIツールに対する変更作業は、システム管理者の作業負荷が大きく、またシステム管理者の作業ミスなどによる人為的障害を誘発するおそれがある。
【0005】
本発明は上記事情に鑑みてなされたものであり、本発明の目的は、複数のユーザが利用する共同利用型システムにおいて、EAIツールに対する定義変更の手間を低減し、システム運用負荷をより軽減することにある。
【課題を解決するための手段】
【0006】
上記課題を解決するために、本発明では、例えば、複数の業務システムを統合する業務統合装置が行う業務統合方法であって、業務統合装置は、業務システムを利用する複数のユーザシステム毎にデータの宛先が設定された宛先制御テーブルと、処理部と、を有する。そして、処理部は、業務システム各々からデータを受信する受信ステップと、受信ステップで受信した受信データの発生元のユーザシステムを特定し、特定したユーザシステムに対応する宛先を宛先制御テーブルから取得する取得ステップと、取得した宛先を受信データに設定した宛先設定データを生成する生成ステップと、宛先設定データに設定された宛先を参照し、受信データを少なくとも1つの業務システムに配信する配信ステップと、を行う。
【発明の効果】
【0007】
本発明では、複数のユーザが利用する共同利用型システムにおいて、EAIツールに対する定義変更の手間を低減し、システム運用負荷をより軽減することができる。
【発明を実施するための最良の形態】
【0008】
以下、本発明の実施の形態について説明する。
【0009】
図1は、本発明の一実施形態が適用された業務統合システムの構成図である。本実施形態では、複数のユーザシステム1が、業務統合システムを共同利用するものとする。
【0010】
業務統合システムは、複数の業務システム3とEAIサーバ5とを有し、業務システム3各々とEAIサーバ5とはLANなどのネットワーク9により接続されている。業務システム3は、各ユーザシステム1で発生した各種のデータを受け付け、EAIサーバ5に送信する。EAIサーバ5は、各業務システム3のデータを連携し、業務システム3を統合する。
【0011】
業務システム3は、インターネットなどのネットワーク8により、複数のユーザシステム1と接続されている。本実施形態のユーザシステム1は、例えば、各種銀行、証券会社等の金融機関のシステムであるものとする。ユーザシステム1のユーザ端末11は、ユーザが入力した取引データ(債券、株式、投信、為替など)を受け付け、受け付けた取引データを所定の業務システム3に送信する。なお、ユーザシステム1は、MQ(message queueing)サーバ12を用いて、MQサーバ用の業務システム3に取引データを送信することとしてもよい。MQサーバ12は、メッセージキューイング方式により取引データを送信する。
【0012】
図示する業務システム3各々は、業務処理部31と、MQ通信部32と、を有する。業務処理部31は、ユーザシステム1から受け付けた取引データの決済、レポート作成などの業務処理を行う。そして、業務処理部31は、自業務システム以外の他業務システムに連携するデータを、MQ通信部32の送信キュー(不図示)に書き込む。
【0013】
MQ通信部32は、図示しない送信キューおよび受信キューを有し、メッセージキューイング方式によりデータを送受信する。すなわち、MQ通信部32は、送信キューに書き込まれたデータを、メッセージキューイング方式によりEAIサーバ5に送信する。また、MQ通信部32は、EAIサーバ5からのデータを、メッセージキューイング方式により受信キューに受信する。
【0014】
EAIサーバ5は、データ配信部51と、承認部52と、照会部53と、データ修正部54と、MQ通信部55と、テーブル管理部56と、宛先制御テーブル57と、承認用データベース(以下、「承認用DB」)58と、保存用データベース(以下、「保存用DB」)59と、を有する。
【0015】
データ配信部51は、宛先制御テーブル57を参照し、各業務システム3から受信したデータを、他の業務システム3に配信する。承認部52は、承認用DB58に記憶された承認対象データに対する承認指示を、ユーザ端末11から受け付ける。照会部53は、ユーザ端末11の要求を受け付けて、保存用DB59に記憶されたデータの処理状況(ステータス)をユーザ端末11に提示する。データ修正部54は、ユーザ端末11から入力されたエラー修正指示を受け付けて、エラーデータを修正する。
【0016】
MQ通信部55は、図示しない送信キューおよび受信キューを有し、メッセージキューイング方式によりデータを送受信する。すなわち、MQ通信部55は、送信キューに書き込まれたデータを、メッセージキューイング方式により各業務システム3に送信する。また、MQ通信部55は、各業務システム3からのデータを、メッセージキューイング方式により受信キューに受信する。テーブル管理部56は、宛先制御テーブル57を管理(メンテナンス)する。
【0017】
宛先制御テーブル57は、業務システム3から受信したデータの宛先(ルーティング情報)が設定されたテーブルである。なお、宛先制御テーブル57については、後述する。承認用DB58には、ユーザシステム1の管理者の承認が必要な承認対象データが記憶される。保存用DB59には、各業務システム3から受信したデータおよび当該データの処理状況が記憶される。
【0018】
上記説明したユーザ端末11、MQサーバ12、業務システム3、および、EAIサーバ5は、いずれも、例えば図2に示すようなCPU901と、メモリ902と、HDD等の外部記憶装置903と、キーボードやマウスなどの入力装置904と、ディスプレイやプリンタなどの出力装置905と、ネットワークと接続するための通信制御装置906と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPU901がメモリ902上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。
【0019】
例えば、業務システム3およびEAIサーバ5の各機能は、業務システム3用のプログラムの場合は業務システム3のCPU901が、そして、EAIサーバ5用のプログラムの場合はEAIサーバ5のCPU901が、それぞれ実行することにより実現される。なお、入力装置904および出力装置905については、各装置が必要に応じて備えるものとする。
【0020】
次に、宛先制御テーブル57について説明する。
【0021】
図3は、宛先制御テーブル57の一例を示す図である。図示する宛先制御テーブル57は、ユーザID(会社コード)571と、トランザクションコード572と、配信先業務システム573と、上限金額574と、適用開始日575と、適用終了日576と、を有する。ユーザID571は、ユーザシステム1(例えば、金融機関などのシステム)を識別するための識別情報である。トランザクションコード572は、データの処理種別を示すコードである。配信先業務システム573には、業務システム名または業務システムコードが設定される。
【0022】
上限金額574には、ユーザシステム1の管理者の承認を必要とする承認対象データか否かを判別するための金額が設定される。すなわち、EAIサーバ5は、取引金額が上限金額574を超えるデータについては、管理者の承認指示を受け付けた後に配信する。適用開始日575および適用終了日576には、当該レコードの適用を開始する年月日、および、適用を終了する年月日が設定される。宛先制御テーブル57に適用開始日575を備えることにより、業務統合システムの利用を開始する新規ユーザのレコードを、実際の利用開始日より前に、あらかじめ宛先制御テーブル57に登録することができる。また、宛先制御テーブル57に適用終了日576を備えることにより、業務統合システムの利用を終了するユーザのレコードを、利用終了日当日に宛先制御テーブル57から削除することなく、事前に更新することができる。
【0023】
なお、テーブル管理部56が、業務統合システムのシステム管理者の指示を受け付けて、宛先制御テーブル57のレコードの追加、削除または変更などの更新処理を行う。
【0024】
次に、EAIサーバ5が、各業務システム3から受信したデータを、所定の業務システム3に配信する配信処理について説明する。
【0025】
図4は、EAIサーバ5の配信処理を模式的に示した図である。図示する例では、3つの業務システム3がEAIサーバ5に接続されているものとする。各業務システム3の業務処理部31は、所定の業務処理により生成したデータを、MQ通信部32の送信キュー321に書き込む。そして、MQ通信部32は、送信キュー321に書き込まれたデータを、EAIサーバ5の当該業務システム3に対応する受信キュー551に、メッセージキューイング方式により送信する(S11)。
【0026】
そして、EAIサーバ5のMQ通信部55は、業務システム3が送信したデータを、当該業務システム3に対応する受信キュー551に受信する。そして、データ配信部51は、各受信キュー551のデータを取り出す(S12)。そして、データ配信部51は、宛先制御テーブル57を参照して、各受信キュー551から取り出したデータの配信先業務システム3を特定する。そして、データ配信部51は、特定した配信先業務システムの送信キュー552に、S12で取り出したデータを書き込む(S13)。そして、MQ通信部55は、各送信キュー552に書き込まれたデータを、対応する業務システム3の受信キュー322に、メッセージキューイング方式により送信する(S14)。
【0027】
次に、EAIサーバ5の配信処理(図4:S12〜S14)について、さらに詳述する。
【0028】
図5は、EAIサーバ5の配信処理のフローチャートである。また、図6は、後述する各データのデータフォーマットの一例を示したものである。
【0029】
まず、図4で説明したように、各業務システム3が送信したデータが、EAIサーバ5のそれぞれの受信キュー551に受信される。そして、EAIサーバ5のデータ配信部51は、受信キュー551のデータ(受信データ)を取り出す(S21)。
【0030】
図6(a)は、受信データのデータフォーマットの一例である。図示する受信データは、業務ヘッダ61と、複数の業務データ項目を有する業務データ62と、を有する。業務ヘッダ61には、当該受信データの発生元であるユーザシステム1のユーザIDと、トランザクションコードとが含まれる。なお、業務システム3の送信キュー321に書き込まれるデータ(図4:S11)は、図6(a)の受信データと同様である。
【0031】
そして、EAIサーバ5のデータ配信部51は、宛先制御テーブル57を参照し、受信データの配信先を取得する(S22)。すなわち、データ配信部51は、受信データの業務ヘッダ61に設定されたユーザIDおよびトランザクションコードを検索キーとして、宛先制御テーブル57から対応する配信先業務システム(業務システム名、業務システムコードなど)を取得する。なお、データ配信部51は、業務ヘッダ61のユーザIDおよびトランザクションコードに対応する配信先業務システムが複数存在する場合、対応する全ての配信先業務システムを取得する。そして、データ配信部51は、受信データに宛先情報を設定(付加)した宛先設定データを生成する(S23)。
【0032】
図6(b)は、宛先設定データのデータフォーマットの一例を示す図である。宛先設定データは、業務ヘッダ61と、宛先情報63と、業務データ62とを有する。図示する宛先情報63には、EAIサーバ5に接続された全ての業務システム3の配信フラグが設定されている。データ配信部51は、宛先制御テーブル57から取得した業務システムに対応する配信フラグを例えば「1」に設定し、それ以外の業務システムの配信フラグには「0」または「スペース」を設定する。なお、業務システムと配信フラグとは、あらかじめ対応付けられているものとする。例えば、業務システムAには配信フラグ1が、また、業務システムBには配信フラグ2が、それぞれ対応付けられているものとする。
【0033】
そして、データ配信部51は、宛先設定データが、承認対象データが否かを判別する(S24)。本実施形態では、例えば、所定の取引金額を超えるデータについては、承認対象データであると判別する。データ配信部51は、宛先設定データの業務ヘッダに設定されたユーザIDおよびトランザクションコードを検索キーとして、宛先制御テーブル57から対応する上限金額を取得する。そして、データ配信部51は、宛先設定データの所定の業務データ項目に設定された取引金額と、取得した上限金額とを比較する。そして、取引金額が上限金額を超える場合、データ配信部51は、承認対象データであると判別すする(S24:YES)。一方、取引金額が上限金額と等しいか、または上限金額より小さい場合、データ配信部51は、承認対象データではないと判別する。
【0034】
なお、取引金額以外に、業務ヘッダに設定されたトランザクションコードを用いて承認対象データか否かを判別することとしてもよい。すなわち、データ配信部51は、トランザクションコードが例えば「取消処理」など所定のコードの場合、承認対象データであると判別することとしてもよい。
【0035】
また、データ配信部51は、業務ヘッダに設定されたユーザIDと、所定の業務データ項目に設定された顧客コードとを用いて承認対象データか否かを判別することとしてもよい。すなわち、データ配信部51は、新規に口座を開設した顧客コードとユーザIDとが設定された新規顧客リスト(不図示)を参照し、承認対象データであるか否かを判別することとしてもよい。
【0036】
承認対象データでない場合(S24:NO)、S27に進む。一方、承認対象データの場合(S24:YES)、データ配信部51は、宛先設定データを承認用DB58に記憶する(S25)。そして、ユーザシステム1の管理者は、ユーザ端末11を用いて承認用DB58を参照し、当該承認用DB58に記憶された自ユーザシステム1の宛先設定データを承認する。EAIサーバ5の承認部52は、ユーザ端末11の承認指示を受け付けると、承認された宛先設定データをデータ配信部51に送出する(S26)。
【0037】
そして、データ配信部51は、宛先設定データの宛先情報を参照し、送信フラグに「1」が設定されている配信先業務システムを特定する。そして、データ配信部51は、宛先設定データから宛先情報を削除した受信データ(図6(a)参照)を複製し、複製した受信データを配信先業務システムの各送信キューにそれぞれ書き込む(S27)。なお、データ配信部51は、受信データを各送信キューに書き込む際に、配信先業務システムの仕様に応じて、受信データのデータフォーマットを変換することとしてもよい。そして、MQ通信部55は、各送信キューに書き込まれた受信データを、対応する業務システム3の受信キューに、メッセージキューイング方式により送信する(S28)。
【0038】
次に、EAIサーバ5の照会処理について説明する。
【0039】
EAIサーバ5のデータ配信部51は、各受信キューから受信データを取り出す際に(図5:S21)、当該受信データを保存用DB59に蓄積する。そして、データ配信部51は、所定のタイミングで、保存用DB59に蓄積された受信データの処理状況(ステータス)を設定する。
【0040】
例えば、データ配信部51は、承認用DB58に宛先設定データを記憶した後(図5:S25)、保存用DB59に蓄積された対応する受信データの処理状況を「承認待ち」に更新する。また、データ配信部51は、所定の業務システム3に受信データを配信した後(図5:S28)、保存用DB59に蓄積された対応する受信データの処理状況を「業務システムに送信済み」に更新する。
【0041】
そして、照会部53は、ユーザシステム1のユーザ端末11からの照会要求を受け付けて、保存用DB59から所望の受信データの処理状況を取得し、要求元のユーザ端末11に送信する。これにより、ユーザシステム1の管理者は、EAIサーバ5にアクセスすることで、いずれかの業務システム3に送信した全てのデータの処理状況を把握することができる。
【0042】
次に、EAIサーバ5のエラー修正処理について説明する。
【0043】
EAIサーバ5が配信したデータにエラーが存在する場合、配信先の業務システム3は、エラーメッセージをEAIサーバ5に送信する。EAIサーバ5のデータ修正部54は、エラーメッセージを受け付けると、保存用DB59に蓄積された対応する受信データの処理状況を「エラー」に更新する。そして、データ修正部54は、ユーザ端末11からのエラー訂正要求を受け付けて、処理状況が「エラー」の受信データを保存用DB59から抽出し、要求元のユーザ端末11に出力する。そして、データ修正部54は、ユーザ端末11の指示を受け付けて、受信データを修正する。そして、データ修正部54は、修正後の受信データを、データ配信部51に送出する。これにより、データ配信部51は、図5の配信処理を行い、再度、受信データを所定の業務システム3に配信する。これにより、EAIサーバ5は、エラー修正後の受信データを、業務システム3に再送することができる。
【0044】
本実施形態のEAIサーバ5は、ユーザおよびトランザクションコード毎にデータの宛先が設定された宛先制御テーブル57を有する。これにより、ユーザ毎にデータの配信先が異なる場合であっても、複数のデータ配信部51を備える必要がない。また、データ配信部51に対してユーザ毎にデータの宛先情報を定義する必要がない。すなわち、宛先制御テーブル57を変更するだけでユーザの追加・削除あるいは配信先の変更に柔軟に対応できるため、システム運用負荷をより軽減することができる。
【0045】
また、本実施形態のEAIサーバ5は、承認対象データか否かを判別し、承認対象データについては承認用DB58に一旦、保存する。これにより、ユーザシステム1からの承認指示を受け付けたタイミングで、承認対象データを各業務システム3に配信することができる。
【0046】
なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記実施形態では、複数のユーザが共同利用する業務統合システムを例に説明した。しかしながら、本発明を企業内で利用する業務統合システムに適用することとしてもよい。すなわち、債券、株式、投信、為替など金融商品毎に、データの配信先が異なる場合がある。この場合、EAIサーバ5は、金融商品毎にデータの宛先を設定した宛先制御テーブルを備える。これによりEAIサーバ5は、金融商品毎にデータを柔軟に配信することができる。
【図面の簡単な説明】
【0047】
【図1】本発明の一実施形態が適用された業務統合システムの構成図である。
【図2】各装置のハードウェア構成例を示す図である。
【図3】宛先制御テーブルの一例を示す図である。
【図4】EAIサーバの配信処理を模式的に示した図である。
【図5】EAIサーバの配信処理のフローチャートである。
【図6】データフォーマットの一例を示す図である。
【符号の説明】
【0048】
1:ユーザシステム、11:ユーザ端末、12:MQサーバ、3:業務システム、31業務処理部、32:MQ通信部、5:EAIサーバ、51:データ配信部、52:承認部、53:照会部、54:データ修正部、55:MQ通信部、56:テーブル管理部、57:宛先制御テーブル、58:承認用DB、59:保存用DB、8:ネットワーク、9:ネットワーク




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013