図面 (/)

技術 データ処理システム

出願人 株式会社野村総合研究所
発明者 瀧村友一
出願日 2014年10月7日 (6年1ヶ月経過) 出願番号 2014-206238
公開日 2016年5月12日 (4年6ヶ月経過) 公開番号 2016-076096
状態 特許登録済
技術分野 金融・保険関連業務,支払い・決済
主要キーワード 顧客属性データ 選択可能項目 ネット通販 拡張システム 経験年数 証券業 選択式 選択型
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年5月12日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (8)

課題

業務システムにおいてデータとそのフォーマット不整合を検出する。

解決手段

プロバイダ100は複数の証券会社102(クライアント)と接続される。プロバイダ100において構成される基幹システム106は、証券会社102に対して、データとともにデータのフォーマットを定義するフォーマットファイルを送信する。送信前に、データがフォーマットに整合しているか否かを判定し、整合していることを条件としてデータを証券会社102に送信する。基幹システム106は、複数の処理サーバ110と中継サーバ112(ゲートウェイ)を含み、中継サーバ112が整合性チェック機能を担う。

概要

背景

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

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

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

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

概要

業務システムにおいてデータとそのフォーマットの不整合を検出する。プロバイダ100は複数の証券会社102(クライアント)と接続される。プロバイダ100において構成される基幹システム106は、証券会社102に対して、データとともにデータのフォーマットを定義するフォーマットファイルを送信する。送信前に、データがフォーマットに整合しているか否かを判定し、整合していることを条件としてデータを証券会社102に送信する。基幹システム106は、複数の処理サーバ110と中継サーバ112(ゲートウェイ)を含み、中継サーバ112が整合性チェック機能を担う。

目的

ASP(Application Service Provider)は、複数のユーザに対してネットワーク経由で各種サービスを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

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

請求項3

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

請求項4

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

請求項5

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

技術分野

0001

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

背景技術

0002

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

0003

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

0004

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

0005

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

先行技術

0006

特開2005−38146号公報

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

0007

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

0008

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

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

0009

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

発明の効果

0010

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

図面の簡単な説明

0011

プロバイダと証券会社の関係を示すハードウェア構成図である。
属性ファイルを示す図である。
取引ファイルを示す図である。
属性フォーマットファイルを示す図である。
取引フォーマットファイルを示す図である。
中継サーバ機能ブロック図である。
データファイルとフォーマットファイルの整合性チェック過程を示すフローチャートである。

実施例

0012

図1は、プロバイダ100と証券会社102の関係を示すハードウェア構成図である。
プロバイダ100は、証券業務サービスのための基幹システム106を構築する。プロバイダ100は、インターネット108を介して複数の証券会社102a、102b、102c・・・と接続される。証券会社102(クライアント)は、インターネット108を介して、顧客のユーザ端末104と接続される。たとえば、証券会社102aは、ユーザ端末104a、104b、104c、104d・・・と接続される。

0013

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

0014

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

0015

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

0016

図2(a)は、属性ファイル116である。
属性ファイル116は、顧客属性を示すデータファイルである。属性ファイル116は、主として、顧客本人から入力された情報をまとめたものである。図2(a)の属性ファイル116には、名前野村太郎年収:600〜800万円、破産経験:なし、株式取引経験年数:5〜10年などの顧客属性データ登録されている。属性ファイル116は、顧客ごとに生成されてもよいし、複数の顧客属性をまとめた単一のデータファイルとして生成されてもよい。

0017

図2(b)は、取引ファイル118である。
取引ファイル118は、図2(a)に示した「野村太郎」についての株式取引情報を示すデータファイルである。取引ファイル118も顧客情報の一種である。図2(b)の取引ファイル118によると、2014年3月6日にA社株を100株、単価4,280円で購入し、2014年6月8日にB社株を10株、単価141,000円で購入していることがわかる。

0018

図3(a)は、属性フォーマットファイル120である。
図3(a)の属性フォーマットファイル120は、属性ファイル116のデータフォーマットを定義するフォーマットファイルである。属性フォーマットファイル120は、各データ項目についてタイプと入力条件を定義する。図3(a)の属性フォーマットファイル120では、
(1)名前:仮名文字で自由入力される。2〜15文字の範囲で入力可能。
(2)年収:「0〜100(万円)」から「3000(万円)以上」までの選択式。選択肢は10個。
(3)破産経験:「あり」と「なし」の二者択一
(4)株式取引経験年数:「なし」から「10年以上」までの選択式。選択肢は5個。
のように定義されている。
たとえば、顧客が名前を登録するときに16文字以上を入力しても、基幹システム106はそのような名前を受け付けない。フォーマットファイルは、基幹システム106の仕様書であり、Excel(登録商標)によるドキュメントファイルとしてまとめられる。

0019

図3(b)は、取引フォーマットファイル122である。
図3(b)の取引フォーマットファイル122は、取引ファイル118のデータフォーマットを定義するフォーマットファイルである。取引フォーマットファイル122は、各データ項目についての入力条件が定義される。基幹システム106は、顧客からの入力にしたがって取引ファイル118を生成する。

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

中継サーバ112は、証券会社102や処理サーバ110との通信インタフェースとなる通信部124と、データファイルとフォーマットファイルの整合性をチェックする判定部126と、フォーマットファイルを格納するフォーマット格納部128と、データファイルを格納するデータ格納部130を含む。

0033

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

0034

送信部132は、データファイルを証券会社102に送信するデータ送信部138と、フォーマットファイルを証券会社102に送信するフォーマット送信部140を含む。受信部134は、処理サーバ110からデータファイルを取得するデータ受信部142と処理サーバ110からフォーマットファイルを取得するフォーマット受信部144を含む。

0035

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

0036

図5は、データファイルとフォーマットファイルの整合性チェック過程を示すフローチャートである。
中継サーバ112は、バッチ処理により夜間の決められた時間に図5に示すチェック処理を実行する。データ受信部142は処理サーバ110からデータファイルを受信し(S10)、フォーマット受信部144は処理サーバ110からフォーマットファイルを受信する(S11)。データファイルはデータ格納部130に保存され、フォーマットファイルはフォーマット格納部128に保存される。

0037

回送信対象となるデータファイルのうち、整合性チェックを未実行のデータファイルがあれば(S12のY)、判定部126はデータファイルを1つ選択し(S14)、対応するフォーマットファイルを参照して整合性をチェックする(S16)。すべてのデータの整合性を確認できれば(S18のY)、処理はS12に戻り次のデータファイルについてチェックする。不整合があれば(S18のN)、通知部136は不整合を通知し(S20)、判定部126はデータファイルを隔離する(S22)。隔離されたデータファイルは送信対象から外れる。

0038

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

0039

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

0040

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

0041

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

0042

100プロバイダ、 102証券会社、 104ユーザ端末、 106基幹システム、 108インターネット、 110処理サーバ、 112中継サーバ、 114拡張システム、 116属性ファイル、 118取引ファイル、 120属性フォーマットファイル、 122取引フォーマットファイル、 124通信部、 126 判定部、 128フォーマット格納部、 130データ格納部、 132 送信部、 134 受信部、 136通知部、 138データ送信部、 140 フォーマット送信部、 142データ受信部、 144 フォーマット受信部。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ