特許 5763822 データ処理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】5763822

(24)【登録日】2015年6月19日

(45)【発行日】2015年8月12日

(54)【発明の名称】データ処理システム

(51)【国際特許分類】

   G06Q 40/04 20120101AFI20150723BHJP

   G06Q 40/02 20120101ALI20150723BHJP

【ＦＩ】

   G06Q40/04 100

   G06Q40/02 104

【請求項の数】5

【全頁数】10

(21)【出願番号】特願2014-206238(P2014-206238)

(22)【出願日】2014年10月7日

【審査請求日】2014年10月17日

【早期審査対象出願】

(73)【特許権者】

【識別番号】000155469

【氏名又は名称】株式会社野村総合研究所

(74)【代理人】

【識別番号】100105924

【弁理士】

【氏名又は名称】森下 賢樹

(72)【発明者】

【氏名】瀧村 友一

【審査官】 塩田 徳彦

(56)【参考文献】

【文献】 特開２００７−１６４５０３（ＪＰ，Ａ）

【文献】 特開２００９−３０１２３５（ＪＰ，Ａ）

【文献】 特開２００５−０３８１４６（ＪＰ，Ａ）

【文献】 特開２００２−３５２０２３（ＪＰ，Ａ）

【文献】 特開２００４−０６２８５９（ＪＰ，Ａ）

【文献】 特開２００７−０５４４９５（ＪＰ，Ａ）

【文献】 米国特許第６９１５２５２（ＵＳ，Ｂ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ５０／３４

(57)【特許請求の範囲】

【請求項1】

複数のクライアントと接続され、
前記クライアントにデータを送信するデータ送信部と、
前記データのフォーマットを定義するフォーマットファイルを前記クライアントに送信するフォーマット送信部と、
前記フォーマットファイルを参照し、前記フォーマットファイルにおいて定義されるフォーマットと、送信対象のデータの実際のフォーマットが整合しているか否かを判定する判定部と、を備え、
前記データ送信部は、送信対象のデータが前記フォーマットと整合していることを条件として前記データを前記クライアントに送信することを特徴とするデータ処理システム。

【請求項2】

前記データ処理システムは、
前記データを生成する処理サーバと、
前記複数のクライアントと前記処理サーバを仲介する中継サーバと、を備え、
前記中継サーバに、前記データ送信部、前記フォーマット送信部および前記判定部の機能が集約されることを特徴とする請求項１に記載のデータ処理システム。

【請求項3】

前記フォーマットファイルは、選択型のデータについての選択可能項目を定義し、
前記判定部は、選択型のデータが前記選択可能項目に定義されていないときにデータ不整合を通知することを特徴とする請求項１または２に記載のデータ処理システム。

【請求項4】

前記フォーマットファイルは、数値型のデータについての設定可能範囲を定義し、
前記判定部は、数値型のデータが前記設定可能範囲から外れているときにデータ不整合を通知することを特徴とする請求項１から３のいずれかに記載のデータ処理システム。

【請求項5】

複数の証券会社に共通の金融サービスを提供するために、各証券会社の業務システムと接続され、
証券会社の顧客情報ファイルを前記証券会社に送信するデータ送信部と、
前記顧客情報ファイルに含まれるデータのフォーマットを定義するフォーマットファイルを前記証券会社に送信するフォーマット送信部と、
前記フォーマットファイルを参照し、前記フォーマットファイルにおいて定義されるフォーマットと、前記顧客情報ファイルのデータの実際のフォーマットが整合しているか否かを判定する判定部と、を備え、
前記データ送信部は、送信対象の顧客情報ファイルのデータが前記フォーマットと整合していることを条件として前記顧客情報ファイルを前記証券会社に送信することを特徴とするデータ処理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サーバ・クライアント・システムにおいて、データをチェックするための技術、に関する。

【背景技術】

【0002】

ＡＳＰ（Application Service Provider）は、複数のユーザに対してネットワーク経由で各種サービスを提供する。ユーザは、通常、ウェブブラウザを介してＡＳＰのサービスを受ける。たとえば、クラウド・サービスも一種のＡＳＰであるといえる。

【0003】

証券業界でも、ＡＳＰ型のサーバ・クライアント・システムを導入することが多い（たとえば、特許文献１参照）。証券業務サービスのＡＳＰ（以下、単に「プロバイダ」とよぶ）が、株式取引、顧客情報管理、与信チェックなどをまとめてバックグラウンドで実行し、証券会社はプロバイダが提供する各種データに基づいて顧客にフロントエンドのサービスを提供するというビジネスモデルも可能である。各証券会社は基幹業務をプロバイダに委託できるので、業務システムを一から構築する必要はない。プロバイダにも、１つの業務システムで複数の証券会社に共通のサービスを提供できるという規模のメリットがある。

【0004】

証券会社はウェブサーバだけを設置して顧客へのユーザインタフェースだけを担当するというのがもっとも簡単なシステム構成である。この場合、証券会社は、顧客から入力されたデータの処理をすべてプロバイダに任せることができる。

【0005】

その一方、証券会社でもプロバイダの業務システム（以下、「基幹システム」とよぶ）を独自の業務システム（以下、「拡張システム」とよぶ）で拡張・補完することにより、独自のサービスを提供したいというニーズもある。この場合、プロバイダは、顧客情報などのデータファイルとともに、フォーマットファイルも証券会社に提供する。データファイルは、基幹システムのアウトプットである。フォーマットファイルは、データファイルに含まれるデータのフォーマットを定義する仕様書である。たとえば、顧客の投資経験が「なし」「３年未満」「３年以上」のいずれかから選ばれるものであるとき、このような選択肢を定義するのがフォーマットファイルである。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２００５−３８１４６号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

多様な証券業務に対応するため、プロバイダが構築する基幹システムは大規模なものになりやすい。大規模な基幹システムにおいては、複数の処理サーバにおいて実行される分散型のプログラムが頻繁に更新される。データのフォーマットも運用中に適宜変更される。たとえば、ソフトウェア・エンジニアが、投資経験について「なし」「３年未満」「３年以上１０年未満」「１０年以上」の４択に選択肢を設計変更したとする。このときには、フォーマットファイルの該当箇所も変更しなければならない。もし、フォーマットファイルの更新を忘れたり、あるいは、フォーマットファイルの更新を間違えると、あとで仕様（フォーマットファイル）がまちがっているのかアウトプット（データファイル）が間違っているのかわからなくなってしまう。特に、フォーマットファイルと整合しないデータファイルを証券会社に送ってしまうと、証券会社の拡張システムにまで影響を及ぼしてしまう。

【0008】

本発明は、上記課題に鑑みてなされたものであり、その主たる目的は、業務システムにおいてデータとそのフォーマットの不整合を検出することである。

【課題を解決するための手段】

【0009】

本発明のある態様のデータ処理システムは、複数のクライアントと接続され、クライアントにデータを送信するデータ送信部と、データのフォーマットを定義するフォーマットファイルをクライアントに送信するフォーマット送信部と、フォーマットファイルを参照し、データがフォーマットに整合しているか否かを判定する判定部と、を備える。
データ送信部は、送信対象のデータがフォーマットと整合していることを条件としてデータをクライアントに送信する。

【発明の効果】

【0010】

本発明によれば、業務システムにおいてフォーマットと整合しないデータの送信を抑止しやすくなる。

【図面の簡単な説明】

【0011】

【図1】プロバイダと証券会社の関係を示すハードウェア構成図である。

【図2(a)】属性ファイルを示す図である。

【図2(b)】取引ファイルを示す図である。

【図3(a)】属性フォーマットファイルを示す図である。

【図3(b)】取引フォーマットファイルを示す図である。

【図4】中継サーバの機能ブロック図である。

【図5】データファイルとフォーマットファイルの整合性チェック過程を示すフローチャートである。

【発明を実施するための形態】

【0012】

図１は、プロバイダ１００と証券会社１０２の関係を示すハードウェア構成図である。
プロバイダ１００は、証券業務サービスのための基幹システム１０６を構築する。プロバイダ１００は、インターネット１０８を介して複数の証券会社１０２ａ、１０２ｂ、１０２ｃ・・・と接続される。証券会社１０２（クライアント）は、インターネット１０８を介して、顧客のユーザ端末１０４と接続される。たとえば、証券会社１０２ａは、ユーザ端末１０４ａ、１０４ｂ、１０４ｃ、１０４ｄ・・・と接続される。

【0013】

証券会社１０２は、ウェブサーバを運用し、ウェブブラウザを介して顧客に証券サービスを提供する。基幹システム１０６は、複数の処理サーバ１１０ａ〜１１０ｆと、中継サーバ１１２（ゲートウェイ）を含む。ユーザ端末１０４から、顧客は各種情報を入力する。たとえば、顧客が株式取引を発注したとき、発注指示は、証券会社１０２からプロバイダ１００に送られ、基幹システム１０６における１以上の処理サーバ１１０において株式取引プログラムにより処理され、処理結果は処理サーバ１１０ｆ、中継サーバ１１２、証券会社１０２を介して、ユーザ端末１０４のウェブブラウザに提供する。

【0014】

証券会社１０２は、ユーザインタフェースのみを担当し、証券業務のための処理をすべて基幹システム１０６に委託してもよいし、独自の拡張システム１１４を構築してもよい。たとえば、証券会社１０２ｃは、キャンペーン期間中に１００万円以上の株式取引をした顧客に対して株式手数料の割引きサービスをしたいとする。このときには、証券会社１０２ｃは、優遇対象者を選ぶ処理を拡張システム１１４により実行する。

【0015】

このような拡張システム１１４を構築するためには、基幹システム１０６のアウトプットであるデータファイルだけでなく、データのフォーマットを定義する仕様書としてのフォーマットファイルも必要である。そこで、本実施形態におけるプロバイダ１００は、証券会社１０２からの求めに応じて、データファイルに加えてフォーマットファイルも証券会社１０２に提供することができる。データファイルとは、詳細は後述するが、たとえば、顧客の属性情報や取引情報など基幹システム１０６の処理過程で生成されるさまざまなアウトプット情報である。

【0016】

図２（ａ）は、属性ファイル１１６である。
属性ファイル１１６は、顧客属性を示すデータファイルである。属性ファイル１１６は、主として、顧客本人から入力された情報をまとめたものである。図２（ａ）の属性ファイル１１６には、名前：野村太郎、年収：６００〜８００万円、破産経験：なし、株式取引経験年数：５〜１０年などの顧客属性データが登録されている。属性ファイル１１６は、顧客ごとに生成されてもよいし、複数の顧客属性をまとめた単一のデータファイルとして生成されてもよい。

【0017】

図２（ｂ）は、取引ファイル１１８である。
取引ファイル１１８は、図２（ａ）に示した「野村太郎」についての株式取引情報を示すデータファイルである。取引ファイル１１８も顧客情報の一種である。図２（ｂ）の取引ファイル１１８によると、２０１４年３月６日にＡ社株を１００株、単価４，２８０円で購入し、２０１４年６月８日にＢ社株を１０株、単価１４１，０００円で購入していることがわかる。

【0018】

図３（ａ）は、属性フォーマットファイル１２０である。
図３（ａ）の属性フォーマットファイル１２０は、属性ファイル１１６のデータフォーマットを定義するフォーマットファイルである。属性フォーマットファイル１２０は、各データ項目についてタイプと入力条件を定義する。図３（ａ）の属性フォーマットファイル１２０では、
（１）名前：仮名文字で自由入力される。２〜１５文字の範囲で入力可能。
（２）年収：「０〜１００（万円）」から「３０００（万円）以上」までの選択式。選択肢は１０個。
（３）破産経験：「あり」と「なし」の二者択一。
（４）株式取引経験年数：「なし」から「１０年以上」までの選択式。選択肢は５個。
のように定義されている。
たとえば、顧客が名前を登録するときに１６文字以上を入力しても、基幹システム１０６はそのような名前を受け付けない。フォーマットファイルは、基幹システム１０６の仕様書であり、Ｅｘｃｅｌ（登録商標）によるドキュメントファイルとしてまとめられる。

【0019】

図３（ｂ）は、取引フォーマットファイル１２２である。
図３（ｂ）の取引フォーマットファイル１２２は、取引ファイル１１８のデータフォーマットを定義するフォーマットファイルである。取引フォーマットファイル１２２は、各データ項目についての入力条件が定義される。基幹システム１０６は、顧客からの入力にしたがって取引ファイル１１８を生成する。

【0020】

図３（ｂ）の取引フォーマットファイル１２２によれば、取引の日付は２００１年１月１日〜現在日時までが設定可能であり、この期間を外れるような入力は不正である。いいかえれば、この期間から外れる取引日時が取引ファイル１１８に登録されている場合、基幹システム１０６にエラーが発生している。銘柄はＡ社、Ｂ社・・・のように投資可能な銘柄が指定される。各銘柄について、最小取引単位が指定される。また、約定価格の範囲も指定される。たとえば、Ａ社の場合、最近の取引価格からみて３０００〜８０００円の範囲から外れる約定価格は想定できず、この範囲からはずれるような約定価格となっている場合、なんらかの処理ミスが発生している可能性がある。株式売買方法は、現物買い、信用買い、現物売り、信用売りのいずれかである。

【0021】

属性ファイル１１６や取引ファイル１１８に含まれるデータの中にはフォーマットを頻繁に変更されるものも多い。データ項目の選択肢が変更されることもあるし、新しいデータ項目が追加されたり、あるいは既存のデータ項目が廃止されることもある。取引ファイル１１８についても、新しい企業が株式市場に上場されるたり、あるいは、上場廃止になったり、単位株が変わったりすることもある。基幹システム１０６をメンテナンスするソフトウェア・エンジニアは、状況に応じて基幹システム１０６のプログラムを適宜変更する。

【0022】

基幹システム１０６のシステム変更時に仕様書にあたるフォーマットファイルもきちんと更新していれば問題ない。しかし、フォーマットファイルの更新を忘れたり、あるいは、間違った変更をしてしまうとデータファイルとフォーマットファイルが不整合となってしまう。この場合には、フォーマットファイルが間違えているのか、それとも、フォーマットファイルが正しくて基幹システム１０６のプログラムが間違えているのかがわからなくなってしまう。したがって、フォーマットファイルをきちんとメンテナンスすることはもちろん、フォーマットファイルとデータファイルの不整合が生じたときには、これを早期に発見することも重要である。

【0023】

一般的には、属性ファイル１１６と属性フォーマットファイル１２０の不整合は、システム変更が属性フォーマットファイル１２０に正しく反映されていないときに発生しやすい。一方、取引ファイル１１８と取引フォーマットファイル１２２の不整合は基幹システム１０６のエラーに起因する可能性が高い。たとえば、取引ファイル１１８に１９５０年の取引履歴が登録されている場合、基幹システム１０６のエラーが疑われる。このような場合も、取引ファイル１１８を取引フォーマットファイル１２２に基づいてチェックすることにより、エラーを早期に発見できる。

【0024】

本実施形態においては、基幹システム１０６はデータファイルとともにフォーマットファイルも証券会社１０２に送信する。より具体的には、バッチ処理により、プロバイダ１００から証券会社１０２に定期的にこれらのファイルが送信される。

【0025】

データファイルとフォーマットファイルが不整合であった場合、証券会社１０２の拡張システム１１４に混乱を及ぼす可能性がある。たとえば、顧客の名前の文字数が２〜１５文字ではなく２〜２０文字に設計変更され、属性ファイル１１６に１８文字の名前が実際に登録されたとする。一方、属性フォーマットファイル１２０では名前の入力条件が２〜１５文字のままできちんと更新されていないとする。基幹システム１０６は「２〜２０文字」に対応できていても、属性フォーマットファイル１２０にその新仕様が反映されていないため、属性ファイル１１６と属性フォーマットファイル１２０は不整合である。

【0026】

あるいは、ある顧客の年収について「２０００〜２５００（万円）」と属性ファイル１１６（データファイル）では設定されているのに、属性フォーマットファイル１２０にはそのような選択項目が定義されていない場合にも、両者は整合しない。

【0027】

データファイルとフォーマットファイルが不整合となっていると、証券会社１０２はプロバイダ１００から提供されるデータを安心して取り扱うことができない。

【0028】

そこで、本実施形態における基幹システム１０６は、データファイルとフォーマットファイルの整合性をチェックしてからデータファイルを送信することにより、このような問題に対処している。

【0029】

また、取引ファイル１１８において、株価が数千円オーダーのＡ社の約定価格が数万円オーダーとなっていた場合、基幹システム１０６にエラーが発生している可能性がある。取引フォーマットファイル１２２においては、Ａ社の約定価格は３０００円〜８０００円という境界条件が設定されているので（図３（ｂ）参照）、取引ファイル１１８と取引フォーマットファイル１２２の整合性をチェックすることにより、基幹システム１０６にエラーがあったとしても早期に発見できる。

【0030】

図４は、中継サーバ１１２の機能ブロック図である。
中継サーバ１１２の各構成要素は、任意のコンピュータのＣＰＵ、メモリ、メモリにロードされた本図の構成要素を実現するプログラム、そのプログラムを格納するハードディスクなどの記憶ユニット、ネットワーク接続用インタフェースを中心にハードウェアとソフトウェアの任意の組み合わせによって実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。以下説明する各図は、ハードウェア単位の構成ではなく、機能単位のブロックを示している。

【0031】

本実施形態においては、データファイルとフォーマットファイルの整合性チェック機能はゲートウェイサーバである中継サーバ１１２に集約されている。中継サーバ１１２を追加するだけでチェック機能を追加できるため、既存の基幹システム１０６との親和性が高いというメリットがある。もちろん、チェック機能の全部または一部をいずれかの処理サーバ１１０が担ってもよい。

【0032】

中継サーバ１１２は、証券会社１０２や処理サーバ１１０との通信インタフェースとなる通信部１２４と、データファイルとフォーマットファイルの整合性をチェックする判定部１２６と、フォーマットファイルを格納するフォーマット格納部１２８と、データファイルを格納するデータ格納部１３０を含む。

【0033】

通信部１２４は、送信部１３２、受信部１３４および通知部１３６を含む。通知部１３６は、不整合検出時に基幹システム１０６の責任者や特定の処理サーバ１１０などに不整合の発見を通知する。責任者に電子メールによって通知してもよいし、処理サーバ１１０に所定のエラー情報を送信することで通知してもよい。

【0034】

送信部１３２は、データファイルを証券会社１０２に送信するデータ送信部１３８と、フォーマットファイルを証券会社１０２に送信するフォーマット送信部１４０を含む。受信部１３４は、処理サーバ１１０からデータファイルを取得するデータ受信部１４２と処理サーバ１１０からフォーマットファイルを取得するフォーマット受信部１４４を含む。

【0035】

判定部１２６は、データファイルとフォーマットファイルを送信する前に、両者が整合しているかをチェックする。不整合のときには通知部１３６はエラー通知する。また、データ送信部１３８は、不整合を検出したデータファイルを証券会社１０２には送信しない。

【0036】

図５は、データファイルとフォーマットファイルの整合性チェック過程を示すフローチャートである。
中継サーバ１１２は、バッチ処理により夜間の決められた時間に図５に示すチェック処理を実行する。データ受信部１４２は処理サーバ１１０からデータファイルを受信し（Ｓ１０）、フォーマット受信部１４４は処理サーバ１１０からフォーマットファイルを受信する（Ｓ１１）。データファイルはデータ格納部１３０に保存され、フォーマットファイルはフォーマット格納部１２８に保存される。

【0037】

次回送信対象となるデータファイルのうち、整合性チェックを未実行のデータファイルがあれば（Ｓ１２のＹ）、判定部１２６はデータファイルを１つ選択し（Ｓ１４）、対応するフォーマットファイルを参照して整合性をチェックする（Ｓ１６）。すべてのデータの整合性を確認できれば（Ｓ１８のＹ）、処理はＳ１２に戻り次のデータファイルについてチェックする。不整合があれば（Ｓ１８のＮ）、通知部１３６は不整合を通知し（Ｓ２０）、判定部１２６はデータファイルを隔離する（Ｓ２２）。隔離されたデータファイルは送信対象から外れる。

【0038】

次回送信対象となるデータファイルのすべてについて整合性チェックを実行すると（Ｓ１２のＮ）、処理は終了し、整合性を確認できたデータファイルと対応するフォーマットファイルが所定時間にまとめて送信される。

【0039】

以上、実施形態に基づいて基幹システム１０６について説明した。
本実施形態によれば、基幹システム１０６が出力するデータをまとめたデータファイルとそのフォーマットを定義するフォーマットファイルを顧客企業である証券会社１０２に提供するときに両者の整合性を確認してから送信できる。このため、基幹システム１０６における実際のアウトプットであるデータファイルと、仕様書としてのフォーマットファイルが矛盾したまま外部に提供されるリスクを抑制できる。

【0040】

以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

【0041】

本実施形態においては、証券会社を対象としたＡＳＰサービスについて説明したが、本発明は証券業務に限らずさまざまなＡＳＰサービスへの応用が可能である。たとえば、ネット通販やチケット販売などのＡＳＰサービスが考えられる。

【符号の説明】

【0042】

１００ プロバイダ、 １０２ 証券会社、 １０４ ユーザ端末、 １０６ 基幹システム、 １０８ インターネット、 １１０ 処理サーバ、 １１２ 中継サーバ、 １１４ 拡張システム、 １１６ 属性ファイル、 １１８ 取引ファイル、 １２０ 属性フォーマットファイル、 １２２ 取引フォーマットファイル、 １２４ 通信部、 １２６ 判定部、 １２８ フォーマット格納部、 １３０ データ格納部、 １３２ 送信部、 １３４ 受信部、 １３６ 通知部、 １３８ データ送信部、 １４０ フォーマット送信部、 １４２ データ受信部、 １４４ フォーマット受信部。

【要約】

【課題】業務システムにおいてデータとそのフォーマットの不整合を検出する。
【解決手段】プロバイダ１００は複数の証券会社１０２（クライアント）と接続される。プロバイダ１００において構成される基幹システム１０６は、証券会社１０２に対して、データとともにデータのフォーマットを定義するフォーマットファイルを送信する。送信前に、データがフォーマットに整合しているか否かを判定し、整合していることを条件としてデータを証券会社１０２に送信する。基幹システム１０６は、複数の処理サーバ１１０と中継サーバ１１２（ゲートウェイ）を含み、中継サーバ１１２が整合性チェック機能を担う。
【選択図】図１

【図1】

【図2(a)】

【図2(b)】

【図3(a)】

【図3(b)】

【図4】

【図5】