機密性を要求される顧客情報などのデータを公域・広域ネットワークと外部リモートサーバから分離し、利用者・ローカル側に配置することで、セキュリティを向上させるデータベースシステム
【課題】顧客データなどの機密性を要求される情報が、公域・広域ネットワーク越しの外部リモートサーバに存在し、公域・広域ネットワークを流れることから、機密情報の漏洩の危険性が存在した。
【解決手段】図１に示すように、顧客情報などのマスタデータを公域・広域ネットワークとそのネットワーク越しの外部リモートサーバから分離し、相対的に安全性の高い利用者・ローカル側に配置して、公域・広域ネットワークとそのネットワーク越しのサーバでの顧客情報などのマスタ情報漏洩を回避することでネットワークセキュリティを向上させる。また、サーバ側トランザクションデータのID、日付データ、金額データなど、顧客データほどではないにしろ、ある程度の意味を有するデータを、別の数字・記号に変換するもので、それを相対的に安全性の高いローカル側に配置したデータ変換機能によりサーバ側トランザクションデータを更に保護する。
【解決手段】図１に示すように、顧客情報などのマスタデータを公域・広域ネットワークとそのネットワーク越しの外部リモートサーバから分離し、相対的に安全性の高い利用者・ローカル側に配置して、公域・広域ネットワークとそのネットワーク越しのサーバでの顧客情報などのマスタ情報漏洩を回避することでネットワークセキュリティを向上させる。また、サーバ側トランザクションデータのID、日付データ、金額データなど、顧客データほどではないにしろ、ある程度の意味を有するデータを、別の数字・記号に変換するもので、それを相対的に安全性の高いローカル側に配置したデータ変換機能によりサーバ側トランザクションデータを更に保護する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機密性を要求される顧客情報などのデータを公域・広域ネットワークとそのネットワーク越しの外部リモートサーバから分離し、相対的に安全性の高い利用者・ローカル側に配置して、公域・広域ネットワークと外部リモートサーバでの顧客情報などの漏洩を回避することでネットワークセキュリティを向上させる安全性の高いデータベースシステムに関するものである。なお、ここでは、顧客情報等の主となるデータ／テーブルをマスタデータ／マスタテーブルデータと呼称する。また、売上取引などの刻々変化するデータをトランザクションデータ／トランザクションテーブルデータと呼称する。
【背景技術】
【０００２】
ネットワーク、特に公に広く開放されたインターネットなどでの情報漏洩リスクが脅威を増す中、ネットワーク経路の暗号化やデータベースそのものの暗号化などで情報セキュリティを確保する技術が開発・実用化されている。
インターネットでの暗号化技術を用いた仮想専用線（VPN:VirtualPrivateNetwork）はオープンソースソフトウェアでのOpenVpnの出現もあって安価で安全な通信を確保するものとして広く使用されるようになってきた。
【０００３】
データベースは一般的に、機密性を要求される顧客情報などを含むマスタテーブルデータと売上記録などのトランザクションテーブルデータが一体として公域・広域ネットワーク越しの外部リモートサーバに保存されているのが多い。それはデータベースの基本概念がそうであるし、設計と運用管理面からしてもマスタ／トランザクションテーブル一体が望ましい形態ではある。
【０００４】
しかし、マスタテーブルデータとトランザクションテーブルデータが一体として外部リモートサーバに保存されていると、それらのデータが漏洩した場合、利用企業の顧客情報や活動状況が一目瞭然に把握でき、セキュリティ上のリスクが高いといえる。
【０００５】
また、マスタテーブルデータとトランザクションテーブルデータが一体として公域・広域ネットワーク越しの外部リモートサーバに保存されていると、利用者がそのサーバのデータベースにアクセスするたびにネットワーク上をそれらのデータが一体として流れ、盗み見などにより企業情報が解読可能となるリスクがあった。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】サーバ、ネットワークセキュリティで検索される特許文献
【非特許文献】
【０００７】
【非特許文献１】RailsによるアジャイルWebアプリケーション開発 オーム社 2007年
【非特許文献２】AjaxOnRails オライリージャパン 2007年
【非特許文献３】Firefox3Hacks オライリージャパン 2008年
【発明の概要】
【発明が解決しようとする課題】
【０００８】
解決しようとする問題点は、顧客情報などのマスタテーブルデータが、利用者ローカルエリア外部で、部外者により読み取り可能なエリア／ゾーン／ネットワークにあることによる覗き見の脅威である。
【課題を解決するための手段】
【０００９】
本発明は、利用者から見て公域・広域ネットワーク越しの外部リモートサーバから、機密性の高いマスタテーブルデータを分離して利用者側・ローカル側に配置し、サーバ側はIDなどの数値・記号データのみで構成されるトランザクションテーブルデータのみとすることで、第一にマスタテーブルデータの漏洩リスクと、第二にマスタテーブルデータとトランザクションテーブルデータを組み合わせた意味のある実体情報の漏洩リスクを低減させることを最も主要な特徴とする。
【発明の効果】
【００１０】
本発明の特徴とする、マスタテーブルデータを利用者側のローカル側に配置することにより公域・広域ネットワーク及び外部リモートサーバから完全分離という方法は、公域・広域ネットワーク及び外部リモートサーバでのマスタテーブルデータの漏洩リスクをなくする利点がある。公域・広域ネットワーク越のサーバにはIDなどの数値・記号データのみ保存されているため、仮にサーバで情報漏洩があったとしても利用者・ローカルエリアにのみ存在するマスタテーブルデータの参照できない状態では意味のある解析ができないという利点がある。
【図面の簡単な説明】
【００１１】
【図１】図１は本発明でのマスタテーブルデータを分離配置する方式の構成図である。（実施例１）
【図２】図２は従来方式であるマスタ／トランザクションテーブルデータ一体方式とそこでの情報漏洩リスクの説明図である。（実施例１）
【図３】図３は本発明でのマスタテーブルデータを分離配置する方式の情報処理図である。（実施例１）
【図４】図４は従来方式であるマスタ／トランザクションテーブルデータ一体方式のソフトウェア処理・データベース処理の詳細図である。（実施例１）
【図５】図５は本発明でのマスタテーブルデータを分離配置する方式のソフトウェア処理・データベース処理の詳細図である。（実施例１）
【図６】図６は実施例１で説明するマスタテーブルデータ／トランザクションテーブルデータ例示図である。
【図７】図７は実施例１で説明する売上リストのブラウザ表示図である。
【図８】図８は実施例１で説明する売上リストを表示するためのスクリプトある。
【図９】図９は実施例１で説明する売上リストのローカル側データベース・マスタテーブルデータを読み取るためのスクリプトである。
【図１０】図１０はサーバ側トランザクションデータを更に保護するためのデータ変換方式図である。（実施例２）
【図１１】図１１は実施例２で説明するデータ変換の複数テーブル使用方式図である。
【図１２】図１２は実施例２で比較説明する既存技術であるセキュリティキーボードの原理図である。
【発明を実施するための形態】
【００１２】
利用者から見て、公域・広域ネットワーク越し外部リモートサーバ側のデータベースにはマスタテーブルデータは配置しないで、数値・記号などのデータのみで構成されるトランザクションテーブルデータのみを配置し、利用者側・ローカルデータベースへマスタテーブルデータを配置して、公域・広域ネットワークや公域・広域ネットワーク越し外部リモートサーバ側から機密性の要求されるマスタテーブルデータの漏洩の危険性を無くした。
【実施例１】
【００１３】
図１は、本発明の構成図である。１ー１は利用者側のローカルエリアネットワークで、１ー８は外部リモートサーバエリアネットワークである。このリモートサーバは１ー７の複数の他の共同利用者で使用されることも多い。１ー１のローカルエリアと１ー８のリモートサーバエリアの間は１ー５の公域・広域ネットワークで結合され、一般的には１ー４、１ー６のファイヤウオールを設け１ー１０の侵入者からの攻撃を防いでいる。
【００１４】
ここで１ー３の顧客情報などを含むマスタテーブルデータは、従来は１ー９リモートサーバ側のトランザクションテーブルデータと一緒に配置されていたが、高度の機密性が要求されるので、それを利用者側のローカルエリアへ配置して、危険性の高い１ー５の公域・広域ネットワーク、１ー８の外部リモートサーバエリアから分離することにより、１ー１の利用者以外への情報漏洩の危険性を低減させている。
【００１５】
図２は、従来のリモートエリアにあるデータベース利用形態の構成図であり、本来の利用者以外への情報漏洩のリスク箇所を示したものである。従来のリモートデータベースでは、マスタテーブルデータは２ー５のデータベースの中にトランザクションテーブルデータと一体として配備されている。そのため、利用者のデータ要求の都度、２ー４の公域・広域ネットワークをマスタテーブルデータが流れることとなる。２ー１はそのネットワークからの漏洩のリスクである。暗号化されていない場合はもとより、暗号化されていたとしても、暗号化キーの漏洩などもないとは言えず漏洩のリスクは存在する。
【００１６】
２ー５の外部リモートデータベースサーバは利用者と契約した利用者組織外部の組織で運用されているのが一般的である。利用者にとって極めて大切な顧客情報に対する意識は外部組織の運用者にとっては相対的に低いと考えられる。守秘義務などで縛ったとしても、外部組織の人為的不正漏洩のリスクは相対的に高く、２ー２のサーバ運用受託者からのマスタテーブルデータの覗き見、漏洩のリスクはある。
【００１７】
次にリモートサーバが他利用者と共有であった場合の他の利用者によるマスタテーブルデータの漏洩のリスクである。パスワードなどのアクセスコントロールなどで保護されていたとしても、セキュリティの脆弱性はどこかに潜在し、利用者以外の共同利用者からの不正アクセスリスクは存在する。
【００１８】
また、リモートサーバエリアがファイヤウオールで保護されていてもサーバへ接続するための外部入口であるネットワークポートは開放する必要がある。一方、利用者側の外部からの入口としてのネットワークポートは全て遮断可能である。したがって利用者側よりリモートサーバ側の方が外部侵入の可能性が高い。そこで２ー６の侵入者からのサーバ侵入とマスタテーブルデータの覗き見リスクが存在する。
【００１９】
図３は本発明でのマスタテーブルデータを分離配置する方式での情報処理説明図である。３ー１は利用者側ローカルエリアでの情報処理、３ー２は外部リモートサーバ側エリアでの情報処理である。３ー３は利用者側へ配置した機密性の高いマスタテーブルデータベース、３ー４は外部リモートサーバ側の数値・記号のみで記録されたトランザクションデータベースである。
【００２０】
情報処理の流れはサーバ側に記録されたデータを表示する例で説明すると、３ー５では利用者がブラウザでサーバへ接続し、メニューから売上リストなどの表示を要求する。それを受けたサーバは３ー６でデータベースへ接続し、利用者の要求した売上リストなどを検索しサーバ側のメモリへ一時保存する。それと同時に、３ー７でマスタテーブルデータをローカル利用者側で読み取れるようJavaScript（商標登録・以下同じ）などのスクリプトを作成し、リモートデータベースから読み出したトランザクションテーブルデータと結合させてローカル利用者側へ返信する。
【００２１】
利用者ローカル側では３ー８でサーバから受信したJavaScriptなどのスクリプトを含むブラウザ表示言語に従い、ローカル側データベースのマスタテーブル（３ー３）へ接続し、サーバ側から送られてきたデータを元に実際の顧客情報などに変換してブラウザ表示する。
【００２２】
次に売上データなどの新規登録の例を説明すると３ー９でメニューから新規登録をサーバへ要求する。リモートサーバ側では新規登録用のJavaScriptなどのスクリプトを含むブラウザ表示言語を作成し、ローカル利用者側へ返信する（３ー１０）。
【００２３】
利用者ローカル側では３ー１１で受信したJavaScriptなどのスクリプトでローカルデータベース３ー３へ接続し、登録に必要な実体のある顧客情報、商品情報などをリストアップしてブラウザへ表示する。利用者は必要な情報を入力し、その結果、顧客情報、商品情報などは名称そのもの・実体でなく例えば顧客ID、商品IDなどをサーバへ送信する。
【００２４】
３ー１２でそれを受信したサーバはそのまま、３ー４のトランザクションテーブルデータベースへ登録する。
【００２５】
図４は本発明との比較のために示した従来のデータベース利用の形態の詳細である。１から６は情報流順を示す。４ー１で利用者はサーバへ例として売上リスト表示を要求する（情報流順１）。ここでは、RubyOnRailsでサーバ処理を構築する例で説明する。RailsはRuby言語とデータベース、Web技術を統合した開発環境（０００７非特許文献参照）。
【００２６】
サーバはその要求をContorollerで受け取り（４ー２）、データベースを制御しているModel（４ー３）を経由してデータベース（４ー４）から要求に必要なトランザクションテーブルデータと顧客情報・商品情報が入っているマスタテーブルデータを取り出す。（情報流順２、３、４）各テーブルデータの具体例は図６に示す。
【００２７】
４ー５のViewではその取り出したデータをローカル・利用者側ブラウザへ表示させるrailsスクリプトと組み合わせて利用者ローカル側へ送信する（情報流順５、６）。
【００２８】
ローカル・利用者側では受信したデータをそのままブラウザで表示する（４ー６）。
【００２９】
ここで従来の方式でのセキュリティリスクを図４で説明すると、
情報流順６では、顧客情報などの機密性の要求される情報パケットが、ファイヤウオールで保護されていない公域・広域ネットワーク上を流れるため、悪意のあるかつ技術力を有する者からの覗き見の危険性がある。
【００３０】
また、外部リモートサーバエリアにある４ー４のデータベースは利用者にとって機密性の高いマスタテーブルデータが保管されていることから、例えばサーバ管理を受託している者を人為的に欺いてデータを盗み取る危険は存在する。現にそういう事例はある。さらに、サーバ側エリアは利用者側エリアに比べ、ネットワークの入口であるポートを必要分開放する必要があることから外部侵入者の攻撃を受けやすい。
【００３１】
図５は本発明での処理詳細である。図４と比較して違ったところを説明する。１から８は情報流順を示す。
５ー１で利用者側からサーバへ売上リスト（例として）表示を要求する（情報流順１）。なお、ここでもRubyOnRailsでサーバ処理を構築する例で説明する。（従来の方法は００２５）
【００３２】
サーバはその要求をContorollerで受け取り（５ー２）、データベースを制御しているModel（５ー３)を経由してデータベース（５ー４）から必要なトランザクションテーブルデータを取り出す。（情報流順２、３、４）。ここでは従来の方法と異なり、マスタテーブルデータはサーバ側にはなく、トランザクションテーブルデータにある顧客ID、商品IDなどの数値・記号のみである。
テーブルの具体例は図６にあり、その構成内容に限れば従来と同じである。（従来の方法は００２６）
【００３３】
５ー５のViewではサーバトランザクションテーブルデータより取り出したデータをローカル・利用者側ブラウザへ表示させるrailsスクリプト（図８）に基づくブラウザスクリプトと、５ー７ローカル利用者マスタテーブルデータをローカル側の処理で読み出してサーバ側のトランザクションテーブルデータと結合させるためのJavaScript（図９）をローカル利用者側へ送信する（５ー６）（情報流順５、６）。railsスクリプト（図８）は従来の方法ではサーバ側にあるトランザクションテーブルデータとサーバ側マスタテーブルデータを組み合わせてブラウザスクリプトを作成するものであるが、本発明の方法では、図９に示すスクリプトを使って、ローカル側にあるマスタテーブルを読み出す処理をローカル側へ送出し、ローカル側で処理させる。（従来の方法は００２７）
【００３４】
ローカル・利用者側では受信したデータと受信したスクリプト（図９）を使ってローカル側マスタテーブルデータから読み出したデータを組み合わせてブラウザで表示する。（５ー８、５ー９）。売上リストの拡大図を図７に示すが、従来の方法と比較するため、従来のサーバ側顧客マスタでの表示と本発明によるローカル側マスタによる顧客名表示をならべて表示してある（その表示処理である図８のスクリプトも同じ）。本発明の方法ではローカル側にあるマスタテーブルを使ってサーバからのデータと組み合わせて表示している部分が従来と異なる（従来の方法は００２８）
【００３５】
ここでセキュリティリスクが軽減される点を図５で説明すると、情報流順６で従来の方法では流れていた機密性の要求される顧客情報をなどが、本発明では流れないため公域・広域ネットワークでの覗き見の危険性が皆無である。（従来の方法は００２９）
【００３６】
また、外部リモートサーバエリアには利用者にとって機密性の高いマスタテーブルデータが保管されていないため、サーバ側エリアへ利用者以外の関係者や、外部侵入者の攻撃があっても機密性の高いマスタテーブルデータの漏洩の危険性は皆無である。（従来の方法は００３０）
【実施例２】
【００３７】
図１０はサーバ側トランザクションデータを更に保護するためのデータ変換方式図である。１０ー１は本来のマスタIDをトランザクションテーブルで記録する記号として変換する変換テーブルである。記録するときはローカル側のマスタテーブルの該当IDを、この変換テーブルで単独では意味をもたない記号に変換して、変換した記号をサーバ側へ送り、それをサーバ側トランザクションテーブル１０ー２へ記録する。
【００３８】
サーバ側から読み出しするときは、サーバ側トランザクションテーブル１０ー２に記録されている変換された記号をローカル側の変換テーブル１０ー１で本来のIDへ戻した上でマスタテーブル１０ー３を参照し利用者側ブラウザで意味のある顧客名、商品名などの実体情報を表示する。
【００３９】
図１１では、さらにセキュリティ強度を上げる方法を示す。本来のマスタIDを一意的に変換記号に対応付けるのではなく、１１ー４のclass情報を設けて、一つのマスタIDに対し複数の変換記号を対応させて、サーバ側のトランザクションテーブル１１ー２へその変換記号とあわせてclass情報を記録する。記号を復号する時は、ローカル側でその記号とclass情報をキーとし、本来のマスタIDへ戻し、マスタテーブル１１ー３を参照し、利用者側ブラウザで意味のある顧客名、商品名などの実体情報を表示する。
【００４０】
００３７ー００３９ではIDの変換を説明したが、日付や金額などでもそれを応用することができる。たとえば日付の2010-1-20であれば変換テーブルに従ってAzaz-a-Azとできるし、更に複雑な変換もテーブル次第で可能ある。
【００４１】
次に、実施例２で説明したデータ変換方式を従来から使用されているセキュリティ保護方法「セキュリティキーボード」との比較で本発明の優位性を説明する。
図１２は金融機関のパスワード入力などで広く用いられているセキュリティキーボードの原理図であり、変換テーブル方式そのものは既存技術である。１２ー１はサーバ側から利用者側へ送るパスワード数字文字変換テーブルである。その送られてきた変換テーブルをブラウザへ表示し（１２ー２）、パスワード入力を促す。パスワードが1234とし、それぞれ1がa、2がA、3がx、4がYと対応付けされていたと仮定すると、ブラウザ表示にしたがってaAxYとキー入力か、マウスクリックする。それがネットワーク上をサーバ側へaAxY相当の情報が送られ、サーバ側で持っている変換テーブルでパスワードが1234と読み替えられる。
【００４２】
セキュリティキーボードの効果はパスワードそのものがネットワークを通らないためパスワードそのものの漏洩の危険が少ないことと、スパイウェアからの保護である。スパイウェアとは利用者側のパソコンに潜在させ、利用者のキー入力などを読み取り、外部に通知できるソフトウェアである。そこでセキュリティキーボードではキー入力でなく該当キー画面のマウスクリックを推奨している。
【００４３】
しかし、セキュリティキーボードではその変換テーブルがネットワークを流れること、ブラウザ上にその変換テーブルに表示されることから、高度な技術をもった悪意のある不正者から読み取られる危険はないとは言えない。
【００４４】
その点、本発明では実施例２に記したように変換テーブルはローカル側に配置されていることからネットワークを流れず、またブラウザ上にその変換テーブルが表示されることはなく、００４５のような危険性はない。
【産業上の利用可能性】
【００４５】
外部共有サーバを使用している企業にとっては機密性の高い顧客データ含むマスタテーブルデータを相対的に安全性の高いローカル利用者側に残すことができ、安心して共有サーバを利用できる。特に中小企業にとっては費用の安い外部共有サーバを利用しやすくなり、情報活用の拡大による産業発展につながる。
【００４６】
専用サーバを使用している企業にとっても、自社ローカルエリア内で運用するより、外部委託に委ねることも多く、機密性の高い顧客データ含むマスタテーブルデータを委託企業に委ねることのリスクや、利用者と専用サーバ間のネットワークでの情報漏洩のリスクがある。それで、本発明のように機密性の高い顧客データ含むマスタテーブルデータを利用者側の保護されたローカルエリアネットワークに残すことにより、安全性が向上して、顧客情報などの情報漏洩による信用性逸失の損害を食い止めることができる。なお、マスタテーブルのデータ量はトランザクションテーブルのデータ量に比べ相対的に少量であり、また追加変更も頻繁に行われるものではないため、利用者側で管理しやすいといえる。
【００４７】
情報漏洩を回避するためのコストは年々増加しつづけている。本発明は機密性の要求される顧客データなどを利用者ローカル側内部に閉じ込め、ネットワークを含めて外部に出さないというセキュリティの基本を貫くことで余分なセキュリティコストをかけない方法である。その削減できるコストを生産性向上などに振り向けることができれば、産業的資源全体のより望ましい使い方につながる。
【符号の説明】
【００４８】
図１
１ー１ 利用者側ローカルエリア
１ー２ 利用者パソコン
１ー３ 利用者側ローカルデータベース
１ー４ 利用者側ファイヤウオール
１ー５ 公域・広域ネットワーク
１ー６ サーバ側ファイヤウオール
１ー７ サーバの共同利用者
１ー８ 外部リモートサーバエリア
１ー９ リモートデータベースサーバ
１ー１０ サーバへの侵入者
図２
２ー１ 公域・広域ネットワークの覗き見リスク
２ー２ サーバ委託者・他利用者からの覗き見リスク
２ー３ サーバ側マスタ・トランザクションテーブルデータ
２ー４ 公域・広域ネットワーク
２ー５ リモートデータベースサーバ
２ー６ 侵入者からの覗き見リスク
図３
３ー１ 利用者側ローカルエリア
３ー２ 外部リモートサーバエリア
３ー３ 利用者側ローカルマスタデータベース
３ー４ サーバ側トランザクションテーブルデータ
３ー５ 利用者のサーバへの要求処理
３ー６ サーバ側データベース接続処理
３ー７ サーバ側でのスクリプト処理
３ー８ ローカル側でマスタテーブル読出とブラウザ表示処理
３ー９ リモートサーバ側への新規データ追加処理
３ー１０ サーバ側でのスクリプト処理（新規データ追加）
３ー１１ ローカル側でマスタテーブル読出とブラウザ表示処理（新規データ追加）
３ー１２ トランザクション書込処理
図４
４ー１ 利用者のサーバへの要求処理
４ー２ サーバ全体を統括するController
４ー３ データベースを制御するModel
４ー４ サーバ側データベース
４ー５ 利用者側表示を受け持つView
４ー６ 利用者側での表示画面
１、２、３、４、５、６ 情報の流れ順
図５
５ー１ 利用者のサーバへの要求処理
５ー２ サーバ全体を統括するController
５ー３ データベースを制御するModel
５ー４ サーバ側データベース
５ー５ 利用者側表示を受け持つView
５ー６ サーバ側でのスクリプト処理
５ー７ 利用者側ローカルマスタデータベース
５ー８ ローカル側でマスタテーブル読出とブラウザ表示処理
５ー９ 利用者側での表示画面
１、２、３、４、５、６、７、８ 情報の流れ順
図６
６ー１ 顧客マスタテーブル例
６ー２ 商品マスタテーブル例
６ー３ 売上トランザクションテーブル例
図１０
１０ー１ 変換テーブル例
１０ー２ 売上トランザクションテーブル例
１０ー３ 顧客マスタテーブル例
図１１
１１ー１ 変換テーブル例
１１ー２ 売上トランザクションテーブル例
１１ー３ 顧客マスタテーブル例
１１ー４ 変換テーブル識別用Class
図１２
１２ー１ キーボード変換テーブル例
１２ー２ サーバから送られてきたセキュリティキーボード
１２ー３ 利用者側のパスワードなどの入力処理
【技術分野】
【０００１】
本発明は、機密性を要求される顧客情報などのデータを公域・広域ネットワークとそのネットワーク越しの外部リモートサーバから分離し、相対的に安全性の高い利用者・ローカル側に配置して、公域・広域ネットワークと外部リモートサーバでの顧客情報などの漏洩を回避することでネットワークセキュリティを向上させる安全性の高いデータベースシステムに関するものである。なお、ここでは、顧客情報等の主となるデータ／テーブルをマスタデータ／マスタテーブルデータと呼称する。また、売上取引などの刻々変化するデータをトランザクションデータ／トランザクションテーブルデータと呼称する。
【背景技術】
【０００２】
ネットワーク、特に公に広く開放されたインターネットなどでの情報漏洩リスクが脅威を増す中、ネットワーク経路の暗号化やデータベースそのものの暗号化などで情報セキュリティを確保する技術が開発・実用化されている。
インターネットでの暗号化技術を用いた仮想専用線（VPN:VirtualPrivateNetwork）はオープンソースソフトウェアでのOpenVpnの出現もあって安価で安全な通信を確保するものとして広く使用されるようになってきた。
【０００３】
データベースは一般的に、機密性を要求される顧客情報などを含むマスタテーブルデータと売上記録などのトランザクションテーブルデータが一体として公域・広域ネットワーク越しの外部リモートサーバに保存されているのが多い。それはデータベースの基本概念がそうであるし、設計と運用管理面からしてもマスタ／トランザクションテーブル一体が望ましい形態ではある。
【０００４】
しかし、マスタテーブルデータとトランザクションテーブルデータが一体として外部リモートサーバに保存されていると、それらのデータが漏洩した場合、利用企業の顧客情報や活動状況が一目瞭然に把握でき、セキュリティ上のリスクが高いといえる。
【０００５】
また、マスタテーブルデータとトランザクションテーブルデータが一体として公域・広域ネットワーク越しの外部リモートサーバに保存されていると、利用者がそのサーバのデータベースにアクセスするたびにネットワーク上をそれらのデータが一体として流れ、盗み見などにより企業情報が解読可能となるリスクがあった。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】サーバ、ネットワークセキュリティで検索される特許文献
【非特許文献】
【０００７】
【非特許文献１】RailsによるアジャイルWebアプリケーション開発 オーム社 2007年
【非特許文献２】AjaxOnRails オライリージャパン 2007年
【非特許文献３】Firefox3Hacks オライリージャパン 2008年
【発明の概要】
【発明が解決しようとする課題】
【０００８】
解決しようとする問題点は、顧客情報などのマスタテーブルデータが、利用者ローカルエリア外部で、部外者により読み取り可能なエリア／ゾーン／ネットワークにあることによる覗き見の脅威である。
【課題を解決するための手段】
【０００９】
本発明は、利用者から見て公域・広域ネットワーク越しの外部リモートサーバから、機密性の高いマスタテーブルデータを分離して利用者側・ローカル側に配置し、サーバ側はIDなどの数値・記号データのみで構成されるトランザクションテーブルデータのみとすることで、第一にマスタテーブルデータの漏洩リスクと、第二にマスタテーブルデータとトランザクションテーブルデータを組み合わせた意味のある実体情報の漏洩リスクを低減させることを最も主要な特徴とする。
【発明の効果】
【００１０】
本発明の特徴とする、マスタテーブルデータを利用者側のローカル側に配置することにより公域・広域ネットワーク及び外部リモートサーバから完全分離という方法は、公域・広域ネットワーク及び外部リモートサーバでのマスタテーブルデータの漏洩リスクをなくする利点がある。公域・広域ネットワーク越のサーバにはIDなどの数値・記号データのみ保存されているため、仮にサーバで情報漏洩があったとしても利用者・ローカルエリアにのみ存在するマスタテーブルデータの参照できない状態では意味のある解析ができないという利点がある。
【図面の簡単な説明】
【００１１】
【図１】図１は本発明でのマスタテーブルデータを分離配置する方式の構成図である。（実施例１）
【図２】図２は従来方式であるマスタ／トランザクションテーブルデータ一体方式とそこでの情報漏洩リスクの説明図である。（実施例１）
【図３】図３は本発明でのマスタテーブルデータを分離配置する方式の情報処理図である。（実施例１）
【図４】図４は従来方式であるマスタ／トランザクションテーブルデータ一体方式のソフトウェア処理・データベース処理の詳細図である。（実施例１）
【図５】図５は本発明でのマスタテーブルデータを分離配置する方式のソフトウェア処理・データベース処理の詳細図である。（実施例１）
【図６】図６は実施例１で説明するマスタテーブルデータ／トランザクションテーブルデータ例示図である。
【図７】図７は実施例１で説明する売上リストのブラウザ表示図である。
【図８】図８は実施例１で説明する売上リストを表示するためのスクリプトある。
【図９】図９は実施例１で説明する売上リストのローカル側データベース・マスタテーブルデータを読み取るためのスクリプトである。
【図１０】図１０はサーバ側トランザクションデータを更に保護するためのデータ変換方式図である。（実施例２）
【図１１】図１１は実施例２で説明するデータ変換の複数テーブル使用方式図である。
【図１２】図１２は実施例２で比較説明する既存技術であるセキュリティキーボードの原理図である。
【発明を実施するための形態】
【００１２】
利用者から見て、公域・広域ネットワーク越し外部リモートサーバ側のデータベースにはマスタテーブルデータは配置しないで、数値・記号などのデータのみで構成されるトランザクションテーブルデータのみを配置し、利用者側・ローカルデータベースへマスタテーブルデータを配置して、公域・広域ネットワークや公域・広域ネットワーク越し外部リモートサーバ側から機密性の要求されるマスタテーブルデータの漏洩の危険性を無くした。
【実施例１】
【００１３】
図１は、本発明の構成図である。１ー１は利用者側のローカルエリアネットワークで、１ー８は外部リモートサーバエリアネットワークである。このリモートサーバは１ー７の複数の他の共同利用者で使用されることも多い。１ー１のローカルエリアと１ー８のリモートサーバエリアの間は１ー５の公域・広域ネットワークで結合され、一般的には１ー４、１ー６のファイヤウオールを設け１ー１０の侵入者からの攻撃を防いでいる。
【００１４】
ここで１ー３の顧客情報などを含むマスタテーブルデータは、従来は１ー９リモートサーバ側のトランザクションテーブルデータと一緒に配置されていたが、高度の機密性が要求されるので、それを利用者側のローカルエリアへ配置して、危険性の高い１ー５の公域・広域ネットワーク、１ー８の外部リモートサーバエリアから分離することにより、１ー１の利用者以外への情報漏洩の危険性を低減させている。
【００１５】
図２は、従来のリモートエリアにあるデータベース利用形態の構成図であり、本来の利用者以外への情報漏洩のリスク箇所を示したものである。従来のリモートデータベースでは、マスタテーブルデータは２ー５のデータベースの中にトランザクションテーブルデータと一体として配備されている。そのため、利用者のデータ要求の都度、２ー４の公域・広域ネットワークをマスタテーブルデータが流れることとなる。２ー１はそのネットワークからの漏洩のリスクである。暗号化されていない場合はもとより、暗号化されていたとしても、暗号化キーの漏洩などもないとは言えず漏洩のリスクは存在する。
【００１６】
２ー５の外部リモートデータベースサーバは利用者と契約した利用者組織外部の組織で運用されているのが一般的である。利用者にとって極めて大切な顧客情報に対する意識は外部組織の運用者にとっては相対的に低いと考えられる。守秘義務などで縛ったとしても、外部組織の人為的不正漏洩のリスクは相対的に高く、２ー２のサーバ運用受託者からのマスタテーブルデータの覗き見、漏洩のリスクはある。
【００１７】
次にリモートサーバが他利用者と共有であった場合の他の利用者によるマスタテーブルデータの漏洩のリスクである。パスワードなどのアクセスコントロールなどで保護されていたとしても、セキュリティの脆弱性はどこかに潜在し、利用者以外の共同利用者からの不正アクセスリスクは存在する。
【００１８】
また、リモートサーバエリアがファイヤウオールで保護されていてもサーバへ接続するための外部入口であるネットワークポートは開放する必要がある。一方、利用者側の外部からの入口としてのネットワークポートは全て遮断可能である。したがって利用者側よりリモートサーバ側の方が外部侵入の可能性が高い。そこで２ー６の侵入者からのサーバ侵入とマスタテーブルデータの覗き見リスクが存在する。
【００１９】
図３は本発明でのマスタテーブルデータを分離配置する方式での情報処理説明図である。３ー１は利用者側ローカルエリアでの情報処理、３ー２は外部リモートサーバ側エリアでの情報処理である。３ー３は利用者側へ配置した機密性の高いマスタテーブルデータベース、３ー４は外部リモートサーバ側の数値・記号のみで記録されたトランザクションデータベースである。
【００２０】
情報処理の流れはサーバ側に記録されたデータを表示する例で説明すると、３ー５では利用者がブラウザでサーバへ接続し、メニューから売上リストなどの表示を要求する。それを受けたサーバは３ー６でデータベースへ接続し、利用者の要求した売上リストなどを検索しサーバ側のメモリへ一時保存する。それと同時に、３ー７でマスタテーブルデータをローカル利用者側で読み取れるようJavaScript（商標登録・以下同じ）などのスクリプトを作成し、リモートデータベースから読み出したトランザクションテーブルデータと結合させてローカル利用者側へ返信する。
【００２１】
利用者ローカル側では３ー８でサーバから受信したJavaScriptなどのスクリプトを含むブラウザ表示言語に従い、ローカル側データベースのマスタテーブル（３ー３）へ接続し、サーバ側から送られてきたデータを元に実際の顧客情報などに変換してブラウザ表示する。
【００２２】
次に売上データなどの新規登録の例を説明すると３ー９でメニューから新規登録をサーバへ要求する。リモートサーバ側では新規登録用のJavaScriptなどのスクリプトを含むブラウザ表示言語を作成し、ローカル利用者側へ返信する（３ー１０）。
【００２３】
利用者ローカル側では３ー１１で受信したJavaScriptなどのスクリプトでローカルデータベース３ー３へ接続し、登録に必要な実体のある顧客情報、商品情報などをリストアップしてブラウザへ表示する。利用者は必要な情報を入力し、その結果、顧客情報、商品情報などは名称そのもの・実体でなく例えば顧客ID、商品IDなどをサーバへ送信する。
【００２４】
３ー１２でそれを受信したサーバはそのまま、３ー４のトランザクションテーブルデータベースへ登録する。
【００２５】
図４は本発明との比較のために示した従来のデータベース利用の形態の詳細である。１から６は情報流順を示す。４ー１で利用者はサーバへ例として売上リスト表示を要求する（情報流順１）。ここでは、RubyOnRailsでサーバ処理を構築する例で説明する。RailsはRuby言語とデータベース、Web技術を統合した開発環境（０００７非特許文献参照）。
【００２６】
サーバはその要求をContorollerで受け取り（４ー２）、データベースを制御しているModel（４ー３）を経由してデータベース（４ー４）から要求に必要なトランザクションテーブルデータと顧客情報・商品情報が入っているマスタテーブルデータを取り出す。（情報流順２、３、４）各テーブルデータの具体例は図６に示す。
【００２７】
４ー５のViewではその取り出したデータをローカル・利用者側ブラウザへ表示させるrailsスクリプトと組み合わせて利用者ローカル側へ送信する（情報流順５、６）。
【００２８】
ローカル・利用者側では受信したデータをそのままブラウザで表示する（４ー６）。
【００２９】
ここで従来の方式でのセキュリティリスクを図４で説明すると、
情報流順６では、顧客情報などの機密性の要求される情報パケットが、ファイヤウオールで保護されていない公域・広域ネットワーク上を流れるため、悪意のあるかつ技術力を有する者からの覗き見の危険性がある。
【００３０】
また、外部リモートサーバエリアにある４ー４のデータベースは利用者にとって機密性の高いマスタテーブルデータが保管されていることから、例えばサーバ管理を受託している者を人為的に欺いてデータを盗み取る危険は存在する。現にそういう事例はある。さらに、サーバ側エリアは利用者側エリアに比べ、ネットワークの入口であるポートを必要分開放する必要があることから外部侵入者の攻撃を受けやすい。
【００３１】
図５は本発明での処理詳細である。図４と比較して違ったところを説明する。１から８は情報流順を示す。
５ー１で利用者側からサーバへ売上リスト（例として）表示を要求する（情報流順１）。なお、ここでもRubyOnRailsでサーバ処理を構築する例で説明する。（従来の方法は００２５）
【００３２】
サーバはその要求をContorollerで受け取り（５ー２）、データベースを制御しているModel（５ー３)を経由してデータベース（５ー４）から必要なトランザクションテーブルデータを取り出す。（情報流順２、３、４）。ここでは従来の方法と異なり、マスタテーブルデータはサーバ側にはなく、トランザクションテーブルデータにある顧客ID、商品IDなどの数値・記号のみである。
テーブルの具体例は図６にあり、その構成内容に限れば従来と同じである。（従来の方法は００２６）
【００３３】
５ー５のViewではサーバトランザクションテーブルデータより取り出したデータをローカル・利用者側ブラウザへ表示させるrailsスクリプト（図８）に基づくブラウザスクリプトと、５ー７ローカル利用者マスタテーブルデータをローカル側の処理で読み出してサーバ側のトランザクションテーブルデータと結合させるためのJavaScript（図９）をローカル利用者側へ送信する（５ー６）（情報流順５、６）。railsスクリプト（図８）は従来の方法ではサーバ側にあるトランザクションテーブルデータとサーバ側マスタテーブルデータを組み合わせてブラウザスクリプトを作成するものであるが、本発明の方法では、図９に示すスクリプトを使って、ローカル側にあるマスタテーブルを読み出す処理をローカル側へ送出し、ローカル側で処理させる。（従来の方法は００２７）
【００３４】
ローカル・利用者側では受信したデータと受信したスクリプト（図９）を使ってローカル側マスタテーブルデータから読み出したデータを組み合わせてブラウザで表示する。（５ー８、５ー９）。売上リストの拡大図を図７に示すが、従来の方法と比較するため、従来のサーバ側顧客マスタでの表示と本発明によるローカル側マスタによる顧客名表示をならべて表示してある（その表示処理である図８のスクリプトも同じ）。本発明の方法ではローカル側にあるマスタテーブルを使ってサーバからのデータと組み合わせて表示している部分が従来と異なる（従来の方法は００２８）
【００３５】
ここでセキュリティリスクが軽減される点を図５で説明すると、情報流順６で従来の方法では流れていた機密性の要求される顧客情報をなどが、本発明では流れないため公域・広域ネットワークでの覗き見の危険性が皆無である。（従来の方法は００２９）
【００３６】
また、外部リモートサーバエリアには利用者にとって機密性の高いマスタテーブルデータが保管されていないため、サーバ側エリアへ利用者以外の関係者や、外部侵入者の攻撃があっても機密性の高いマスタテーブルデータの漏洩の危険性は皆無である。（従来の方法は００３０）
【実施例２】
【００３７】
図１０はサーバ側トランザクションデータを更に保護するためのデータ変換方式図である。１０ー１は本来のマスタIDをトランザクションテーブルで記録する記号として変換する変換テーブルである。記録するときはローカル側のマスタテーブルの該当IDを、この変換テーブルで単独では意味をもたない記号に変換して、変換した記号をサーバ側へ送り、それをサーバ側トランザクションテーブル１０ー２へ記録する。
【００３８】
サーバ側から読み出しするときは、サーバ側トランザクションテーブル１０ー２に記録されている変換された記号をローカル側の変換テーブル１０ー１で本来のIDへ戻した上でマスタテーブル１０ー３を参照し利用者側ブラウザで意味のある顧客名、商品名などの実体情報を表示する。
【００３９】
図１１では、さらにセキュリティ強度を上げる方法を示す。本来のマスタIDを一意的に変換記号に対応付けるのではなく、１１ー４のclass情報を設けて、一つのマスタIDに対し複数の変換記号を対応させて、サーバ側のトランザクションテーブル１１ー２へその変換記号とあわせてclass情報を記録する。記号を復号する時は、ローカル側でその記号とclass情報をキーとし、本来のマスタIDへ戻し、マスタテーブル１１ー３を参照し、利用者側ブラウザで意味のある顧客名、商品名などの実体情報を表示する。
【００４０】
００３７ー００３９ではIDの変換を説明したが、日付や金額などでもそれを応用することができる。たとえば日付の2010-1-20であれば変換テーブルに従ってAzaz-a-Azとできるし、更に複雑な変換もテーブル次第で可能ある。
【００４１】
次に、実施例２で説明したデータ変換方式を従来から使用されているセキュリティ保護方法「セキュリティキーボード」との比較で本発明の優位性を説明する。
図１２は金融機関のパスワード入力などで広く用いられているセキュリティキーボードの原理図であり、変換テーブル方式そのものは既存技術である。１２ー１はサーバ側から利用者側へ送るパスワード数字文字変換テーブルである。その送られてきた変換テーブルをブラウザへ表示し（１２ー２）、パスワード入力を促す。パスワードが1234とし、それぞれ1がa、2がA、3がx、4がYと対応付けされていたと仮定すると、ブラウザ表示にしたがってaAxYとキー入力か、マウスクリックする。それがネットワーク上をサーバ側へaAxY相当の情報が送られ、サーバ側で持っている変換テーブルでパスワードが1234と読み替えられる。
【００４２】
セキュリティキーボードの効果はパスワードそのものがネットワークを通らないためパスワードそのものの漏洩の危険が少ないことと、スパイウェアからの保護である。スパイウェアとは利用者側のパソコンに潜在させ、利用者のキー入力などを読み取り、外部に通知できるソフトウェアである。そこでセキュリティキーボードではキー入力でなく該当キー画面のマウスクリックを推奨している。
【００４３】
しかし、セキュリティキーボードではその変換テーブルがネットワークを流れること、ブラウザ上にその変換テーブルに表示されることから、高度な技術をもった悪意のある不正者から読み取られる危険はないとは言えない。
【００４４】
その点、本発明では実施例２に記したように変換テーブルはローカル側に配置されていることからネットワークを流れず、またブラウザ上にその変換テーブルが表示されることはなく、００４５のような危険性はない。
【産業上の利用可能性】
【００４５】
外部共有サーバを使用している企業にとっては機密性の高い顧客データ含むマスタテーブルデータを相対的に安全性の高いローカル利用者側に残すことができ、安心して共有サーバを利用できる。特に中小企業にとっては費用の安い外部共有サーバを利用しやすくなり、情報活用の拡大による産業発展につながる。
【００４６】
専用サーバを使用している企業にとっても、自社ローカルエリア内で運用するより、外部委託に委ねることも多く、機密性の高い顧客データ含むマスタテーブルデータを委託企業に委ねることのリスクや、利用者と専用サーバ間のネットワークでの情報漏洩のリスクがある。それで、本発明のように機密性の高い顧客データ含むマスタテーブルデータを利用者側の保護されたローカルエリアネットワークに残すことにより、安全性が向上して、顧客情報などの情報漏洩による信用性逸失の損害を食い止めることができる。なお、マスタテーブルのデータ量はトランザクションテーブルのデータ量に比べ相対的に少量であり、また追加変更も頻繁に行われるものではないため、利用者側で管理しやすいといえる。
【００４７】
情報漏洩を回避するためのコストは年々増加しつづけている。本発明は機密性の要求される顧客データなどを利用者ローカル側内部に閉じ込め、ネットワークを含めて外部に出さないというセキュリティの基本を貫くことで余分なセキュリティコストをかけない方法である。その削減できるコストを生産性向上などに振り向けることができれば、産業的資源全体のより望ましい使い方につながる。
【符号の説明】
【００４８】
図１
１ー１ 利用者側ローカルエリア
１ー２ 利用者パソコン
１ー３ 利用者側ローカルデータベース
１ー４ 利用者側ファイヤウオール
１ー５ 公域・広域ネットワーク
１ー６ サーバ側ファイヤウオール
１ー７ サーバの共同利用者
１ー８ 外部リモートサーバエリア
１ー９ リモートデータベースサーバ
１ー１０ サーバへの侵入者
図２
２ー１ 公域・広域ネットワークの覗き見リスク
２ー２ サーバ委託者・他利用者からの覗き見リスク
２ー３ サーバ側マスタ・トランザクションテーブルデータ
２ー４ 公域・広域ネットワーク
２ー５ リモートデータベースサーバ
２ー６ 侵入者からの覗き見リスク
図３
３ー１ 利用者側ローカルエリア
３ー２ 外部リモートサーバエリア
３ー３ 利用者側ローカルマスタデータベース
３ー４ サーバ側トランザクションテーブルデータ
３ー５ 利用者のサーバへの要求処理
３ー６ サーバ側データベース接続処理
３ー７ サーバ側でのスクリプト処理
３ー８ ローカル側でマスタテーブル読出とブラウザ表示処理
３ー９ リモートサーバ側への新規データ追加処理
３ー１０ サーバ側でのスクリプト処理（新規データ追加）
３ー１１ ローカル側でマスタテーブル読出とブラウザ表示処理（新規データ追加）
３ー１２ トランザクション書込処理
図４
４ー１ 利用者のサーバへの要求処理
４ー２ サーバ全体を統括するController
４ー３ データベースを制御するModel
４ー４ サーバ側データベース
４ー５ 利用者側表示を受け持つView
４ー６ 利用者側での表示画面
１、２、３、４、５、６ 情報の流れ順
図５
５ー１ 利用者のサーバへの要求処理
５ー２ サーバ全体を統括するController
５ー３ データベースを制御するModel
５ー４ サーバ側データベース
５ー５ 利用者側表示を受け持つView
５ー６ サーバ側でのスクリプト処理
５ー７ 利用者側ローカルマスタデータベース
５ー８ ローカル側でマスタテーブル読出とブラウザ表示処理
５ー９ 利用者側での表示画面
１、２、３、４、５、６、７、８ 情報の流れ順
図６
６ー１ 顧客マスタテーブル例
６ー２ 商品マスタテーブル例
６ー３ 売上トランザクションテーブル例
図１０
１０ー１ 変換テーブル例
１０ー２ 売上トランザクションテーブル例
１０ー３ 顧客マスタテーブル例
図１１
１１ー１ 変換テーブル例
１１ー２ 売上トランザクションテーブル例
１１ー３ 顧客マスタテーブル例
１１ー４ 変換テーブル識別用Class
図１２
１２ー１ キーボード変換テーブル例
１２ー２ サーバから送られてきたセキュリティキーボード
１２ー３ 利用者側のパスワードなどの入力処理
【特許請求の範囲】
【請求項１】
顧客情報などのマスタテーブルデータを公域・広域ネットワークとそのネットワーク越しの外部リモートサーバから分離し、相対的に安全性の高い利用者・ローカル側に配置することを特徴として、公域・広域ネットワークとそのネットワーク越しの外部リモートサーバでの顧客情報などのマスタ情報漏洩を回避することで、ネットワークセキュリティを向上させるデータベースシステム。
【請求項２】
サーバ側トランザクションテーブルデータを更に保護するため、サーバ側トランザクションテーブルデータのID、日付データ、金額データなど、顧客データほどではないにしろ、ある程度の意味を有するデータを、意味のない数字・記号に変換するもので、その変換テーブルを相対的に安全性の高い利用者・ローカル側に配置することを特徴とするデータ変換方式。
【請求項３】
請求項２のデータ変換方式において、その変換パターンを複数持たせ、そのパターンを識別する情報をサーバ側トランザクションテーブルデータへ記憶させ、その変換パターンの識別情報を使用することを用いて、利用者・ローカル側に配置した変換テーブルで復号すること特徴とするデータ変換方式。
【請求項１】
顧客情報などのマスタテーブルデータを公域・広域ネットワークとそのネットワーク越しの外部リモートサーバから分離し、相対的に安全性の高い利用者・ローカル側に配置することを特徴として、公域・広域ネットワークとそのネットワーク越しの外部リモートサーバでの顧客情報などのマスタ情報漏洩を回避することで、ネットワークセキュリティを向上させるデータベースシステム。
【請求項２】
サーバ側トランザクションテーブルデータを更に保護するため、サーバ側トランザクションテーブルデータのID、日付データ、金額データなど、顧客データほどではないにしろ、ある程度の意味を有するデータを、意味のない数字・記号に変換するもので、その変換テーブルを相対的に安全性の高い利用者・ローカル側に配置することを特徴とするデータ変換方式。
【請求項３】
請求項２のデータ変換方式において、その変換パターンを複数持たせ、そのパターンを識別する情報をサーバ側トランザクションテーブルデータへ記憶させ、その変換パターンの識別情報を使用することを用いて、利用者・ローカル側に配置した変換テーブルで復号すること特徴とするデータ変換方式。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１０−２６２３２２（Ｐ２０１０−２６２３２２Ａ）
【公開日】平成２２年１１月１８日（２０１０．１１．１８）
【国際特許分類】
【出願番号】特願２００９−１１０１９８（Ｐ２００９−１１０１９８）
【出願日】平成２１年４月２９日（２００９．４．２９）
【出願人】（５９８１２０２８５）
【Ｆターム（参考）】
【公開日】平成２２年１１月１８日（２０１０．１１．１８）
【国際特許分類】
【出願日】平成２１年４月２９日（２００９．４．２９）
【出願人】（５９８１２０２８５）
【Ｆターム（参考）】
[ Back to top ]