【事件の表示】
　特願２０００−６１２８６３「多数の電気通信ネットワーク取引および電子商取引を統合した証券取引システム」拒絶査定不服審判事件〔平成１２年１０月２６日国際公開、ＷＯ００／６３８１４、平成１４年１２月１０日国内公表、特表２００２−５４２５４３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１２年４月２０日（パリ条約による優先権主張外国庁受理１９９９年４月２１日、アメリカ合衆国）を国際出願日とする出願であって、平成１６年１１月１１日付で拒絶査定がなされ、これに対し、平成１７年２月１０日に拒絶査定に対する審判請求がなされるとともに、同年３月１１日付で手続補正がなされ、さらに、平成２０年３月３１日付で審尋がなされ、これに対して同年７月２日付で回答書が提出されたものである。
　
２．平成１７年３月１１日付の手続補正についての補正却下の決定
［補正却下の決定の結論］
　　平成１７年３月１１日付の手続補正を却下する。
　
［理由］
（１）本件補正の内容
　平成１７年３月１１日付の手続補正（以下「本件補正」という。）により、特許請求の範囲は、
「　【請求項１】　二つかそれ以上のオルターナティブ取引システムから注文情報を統合する取引者のための証券や商品の金融データ処理システムにおいて、
　それぞれ参加しているオルターナティブ取引システムから注文情報の受け取りを許可するために会員の情報を受け取るデータ通信手段と、
　そのようなデータ通信手段のプロトコルを共通のシステムプロトコルに変換する変換手段と、
　それぞれのオルタ−ナティブ取引システムのデータ通信手段から入力された注文情報を統合し単一の注文控えをデータとして蓄積する統合手段と、
　結果として統合された注文控えを取引者に配布する手段と、
　前記注文控えを取引者に表示する表示手段と、
を備える金融データ処理システム。
　　【請求項２】　取引者に配布されるデータから取引者が受け取る権利のないデータを取り除くために、蓄積された注文控えデータと、注文データ及びその他のデータとを比較し、所定の関連づけに基づいて蓄積されたデータに関連しないデータを選別する手段をさらに備える請求項１に記載の金融データ処理システム。
　　【請求項３】　参加している電子商取引の注文情報がオルターナティブ取引システムの注文情報と一体化されている請求項１に記載の金融データ処理システムにおいて、
　それぞれ参加している電子商取引から注文情報の受け取りを許可するために会員の情報を受け取るデータ通信手段と、
　電子商取引のそれぞれのデータの流れのプロトコルを共通のシステムプロトコルに変換する変換手段と、
　オルターナティブ取引システムから入力された注文情報と、一つ以上の電子商取引から入力された注文情報とを一体化してデータとして蓄積する統合手段と、
を備える金融データ処理システム。
　　【請求項４】　取引者に発注、買値の入札、売り値の入札、実行の承認の受け取りをさせる手段を有する請求項３に記載の金融データ処理システム。
　　【請求項５】　オルターナティブ取引システムと電子商取引から受け取った情報と、
すでに蓄積されている顧客データとを比較して、所定の関連づけにより取引者に売買の注文に役立つ情報を送る分析手段を有する請求項４に記載の金融データ処理システム。
　　【請求項６】　分析手段がオルターナティブ取引システムおよび電子商取引から受け取る情報を再確認し、分析手段によりＣＣＳが発注をするのに役立つことを特徴とする請求項４に記載の金融データ処理システム。
　　【請求項７】　取引者によって選択された変数により注文控え情報を選別する手段を有する請求項３に記載の金融データ処理システム。
　　【請求項８】　蓄積されているデータから、それぞれ参加しているオルターナティブ取引システムおよび電子商取引の全ての発注の特別な特性を利用して、取引者に発注、買値の入札、売値の入札、実行の承認の受け取りをさせる手段を有することを特徴とする請求項４に記載の金融データ処理システム。
　　【請求項９】　注文控え情報を証券、売値と買値、それから価格、量、そして取引者が選択した他の要素で整理する分類手段を有する請求項１に記載の金融データ処理システム。
　　【請求項１０】　一つかそれ以上のオルターナティブ取引システムから証券や商品の取引情報を取引者に供給するデータ処理方法において、
　それぞれ参加するオルターナティブ取引システムから注文情報を受け取り、
　情報を共通のプロトコルに変換し、
　それぞれのオルターナティブ取引システムから入力された注文情報を統合し単一の注文控えをデータとして蓄積し、
　統合された注文控えを配布し、
　前記注文控えを取引者に表示する、
というステップを含むデータ処理方法。
　　【請求項１１】　取引者に配布されるデータから取引者が受け取る権利がない情報を取り除くために、蓄積された注文控えデータと、注文データ及びその他のデータとを比較し、所定の関連づけに基づいて蓄積されたデータに関連しないデータを選別して取引者に送ることを特徴とする請求項１０に記載の方法。
　　【請求項１２】　オルターナティブ取引システムの注文控えは、一つかそれ以上の電子商取引の情報と一体化されることを特徴とする請求項１０に記載の方法。
　　【請求項１３】　オルターナティブ取引システムおよび電子商取引から受け取った情報はすでに蓄積されている顧客データと所定の関連づけにより比較して分析され、分析情報は取引者が売買の発注をするのに役立つよう使用されることを特徴とする請求項１２に記載の方法。
　　【請求項１４】　分析情報は発注をするのに役立つよう取引者に供給されることを特徴とする請求項１３に記載の方法。
　　【請求項１５】　分析情報は自動的に発注をコントロールすることを特徴とする請求項１４に記載の方法。
　　【請求項１６】　注文控え情報は取引者によって選択された変数によって選別されることを特徴とする請求項１２に記載の方法。
　　【請求項１７】　取引者が発注、買値の入札、売値の入札、実行の承認の受け取りを単一の端末を使用した単一の申し込みで行うことを特徴とする請求項１４に記載の方法。
　　【請求項１８】　蓄積されているデータから取引者がそれぞれの参加するオルターナティブ取引システムおよび電子商取引の全ての発注の特別な特性を利用することを特徴とする請求項１７に記載の方法。
　　【請求項１９】　情報が証券および売値と買値により統合され、それから価格によって分類されることを特徴とする請求項１２に記載の方法。」
から
「　【請求項１】　二つかそれ以上のオルターナティブ取引システムから
注文控え情報
　異なる注文控え情報プロトコルを有する少なくとも二つのオルターナティブ取引システムと、
　本来の注文控え情報プロトコルによる注文控え情報の受け取りを許可するために、
控え
の少なくとも一部を受け取るための
　前記データ通信手段を介してそれぞれ参加しているオルターナティブ取引システムから受け取った注文控え情報の少なくとも一部を、共通の注文控え情報プロトコルに変換する変換手段と、
　
前記
を介してそれぞれ参加しているオルターナティブ取引システムから受け取った注文控え情報の少なくとも一部を、共通のプロトコル
　それぞれの
オルターナティブ取引システムから
注文控え情報
証券や商品ごとに整理された統合
　結果として統合された注文控えを
一つ又はそれ以上の証券や商品のための共通の注文控え情報プロトコルによって
　
一つ又はそれ以上の証券や商品に関して
統合
を備える金融データ処理システム。
　　【請求項２】　
前記取引者が会員であるそれらのオルターナティブ取引システムだけからの注文控え情報を個々の取引者に提供するために、前記注文控え情報を限定する手段がある
　　【請求項
３
個々の前記オルターナティブ取引システムや電子商取引があったとしても、前記個々のオルターナティブ取引システムと、電子商取引の注文のためのプロトコルと、共通のシステムのためのプロトコルとの間における相互の変換をすることによって、
させる相互変換
請求項１に
　　【請求項
４
前記相互変換手段は、前記個々の
、
と、前記共通システムのためのプロトコルとの間において、
対し、それぞれ参加しているオルターナティブ取引システム又は電子商取引の発注、買値の入札、売値の入札、実行の承認をさせる
３
　　【請求項
５
　　【請求項
６
　　【請求項
７
　　【請求項
８
一つかそれ以上の
　
異なる注文控え情報プロトコルを有する少なくとも二つのオルターナティブ取引システムのうち、
控え
の少なくとも一部
　
オルターナティブ取引システムのいずれかから受け取った注文控え
少なくとも一部
注文控え情報プロトコル
　それぞれのオルターナティブ取引システムから入力された注文
控え
証券や商品ごとに整理された統合
　統合された注文控えを
一つ又はそれ以上の証券や商品のための共通の注文控え情報プロトコルによって取引者に
　
一つ又はそれ以上の証券や商品に関して
というステップを含むデータ処理方法。
　　【請求項
９
８
　　【請求項
１０
８
　　【請求項
１１
１０
　　【請求項
１２
１１
　　【請求項
１３
８
　　【請求項
１４
１１
　　【請求項
１５
１４
へと補正された。
　なお、下線は、補正箇所を示すために審判請求人が付記したものである。
　
（２）補正に対する審判請求人の主張の概要
　平成１７年２月１０日付の審判請求書における補正に対する審判請求人の主張の概要は以下のとおりである。
「１．補正の説明
　本願は、本意見書と同日付け提出の手続補正書により、下記の補正を行った。
　（１）請求項１、８では、「異なる注文控え情報プロトコルを有する少なくとも二つのオルターナティブ取引システムと、」と減縮する補正を行った。
　この補正は、拒絶査定における原審審査官の「本願請求項には、・・・二以上の取引システムが『異なるプロトコルにしたがう』ことは何ら規定されていない」との指摘に対応するものである。
　（２）また、請求項１では、データ通信手段が「本来の注文控え情報プロトコルによる注文控え情報の受け取りを許可するために、それぞれ参加しているオルターナティブ取引システムから注文控え情報の少なくとも一部を受け取る」という点、及び変換手段が「前記データ通信手段を介してそれぞれ参加しているオルターナティブ取引システムから受け取った注文控え情報の少なくとも一部を、共通の注文控え情報プロトコルに変換する」という点をさらに減縮している。
　（３）上記の請求項１と同様に、請求項８においても、「オルターナティブ取引システムのいずれかから受け取った注文控え情報の少なくとも一部を共通の注文控え情報プロトコルに変換」するという点、及び「統合された注文控えを一つ又はそれ以上の証券や商品のための共通の注文控え情報プロトコルによって取引者に配布」するという点をさらに減縮している。
　上記の以外にも、請求項において、本願発明の特徴を明確にするために、発明特定事項を限定する補正を行った。
　これらの補正は、いずれも出願時の明細書に記載された事項から自明な範囲でなされたものであるとともに、請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正の前後において産業上の利用分野及び解決しようとする課題が同一である。
　したがって、上記の補正は、いずれも特許法第１７条の２第３項及び第４項に規定する要件を満たすものである。」
　
（３）補正の目的について
　補正後の上記請求項１及び２に係る本件補正の目的について以下に検討する。
（３−１）補正後の請求項１に係る本件補正の目的について
　補正前の請求項１又は請求項３には「変換手段」が一つしか記載されていないのに対し、補正後の請求項１の「前記データ通信手段を介してそれぞれ参加しているオルターナティブ取引システムから受け取った注文控え情報の少なくとも一部を、共通の注文控え情報プロトコルに変換する変換手段と、前記データ通信手段を介してそれぞれ参加しているオルターナティブ取引システムから受け取った注文控え情報の少なくとも一部を、共通のプロトコルに変換する変換手段と」の記載からみて、補正後の請求項１には２つの変換手段が記載されており、本件補正により新たに一つの変換手段が追加され、その追加された変換手段は、補正前の特許請求の範囲に記載された「それぞれ参加しているオルターナティブ取引システムから注文情報の受け取りを許可するために会員の情報を受け取るデータ通信手段」、「そのようなデータ通信手段のプロトコルを共通のシステムプロトコルに変換する変換手段」、「それぞれのオルタ−ナティブ取引システムのデータ通信手段から入力された注文情報を統合し単一の注文控えをデータとして蓄積する統合手段」、「結果として統合された注文控えを取引者に配布する手段」、「前記注文控えを取引者に表示する表示手段」、「取引者に配布されるデータから取引者が受け取る権利のないデータを取り除くために、蓄積された注文控えデータと、注文データ及びその他のデータとを比較し、所定の関連づけに基づいて蓄積されたデータに関連しないデータを選別する手段」等の手段の下位概念とは認められず、同位の概念であると認められるので、補正前の請求項のいずれかを限定的に減縮したものとは認められず、請求項１に係る本件補正は、特許法第１７条の２第４項第２号に掲げられた「特許請求の範囲の減縮」を目的とするものに該当するとは認められない。
　また、追加された「変換手段」は新たな手段であるので、補正前の各請求項に記載された各手段について明りょうでない記載を釈明したものとは認められないので、請求項１に係る本件補正が、特許法第１７条の２第４項第４号に掲げられた「明りょうでない記載の釈明」を目的とするものに該当するとは認められない。なお、審判請求人は、補正後の請求項１に係る本件補正が「明りょうでない記載の釈明」を目的とするものに該当するとは主張していない。
　さらに、補正後の請求項１に係る本件補正が、特許法第１７条の２第４項第１号に掲げられた「請求項の削除」、又は同項第３号に掲げられた「誤記の訂正」を目的とするものに該当するとは認められない。
　したがって、補正後の請求項１に係る本件補正は、特許法第１７条の２第４項に規定する要件を満たしていない。
　
（３−２）補正後の請求項２に係る本件補正の目的について
　補正後の請求項２に記載された「前記取引者が会員であるそれらのオルターナティブ取引システムだけからの注文控え情報を個々の取引者に提供するために、前記注文控え情報を限定する手段」は、補正前の特許請求の範囲に記載された「それぞれ参加しているオルターナティブ取引システムから注文情報の受け取りを許可するために会員の情報を受け取るデータ通信手段」、「そのようなデータ通信手段のプロトコルを共通のシステムプロトコルに変換する変換手段」、「それぞれのオルタ−ナティブ取引システムのデータ通信手段から入力された注文情報を統合し単一の注文控えをデータとして蓄積する統合手段」、「結果として統合された注文控えを取引者に配布する手段」、「前記注文控えを取引者に表示する表示手段」、「取引者に配布されるデータから取引者が受け取る権利のないデータを取り除くために、蓄積された注文控えデータと、注文データ及びその他のデータとを比較し、所定の関連づけに基づいて蓄積されたデータに関連しないデータを選別する手段」等の手段の下位概念とは認められず、同位の概念であると認められるので、補正前の請求項のいずれかを限定的に減縮したものとは認められず、請求項２に係る本件補正は、特許法第１７条の２第４項第２号に掲げられた「特許請求の範囲の減縮」を目的とするものに該当するとは認められない。
　また、「前記取引者が会員であるそれらのオルターナティブ取引システムだけからの注文控え情報を個々の取引者に提供するために、前記注文控え情報を限定する手段」は新たに追加された手段であるので、補正前の各請求項に記載された各手段について明りょうでない記載を釈明したものとは認められないので、補正後の請求項２に係る本件補正が、特許法第１７条の２第４項第４号に掲げられた「明りょうでない記載の釈明」を目的とするものに該当するとは認められない。なお、審判請求人は、補正後の請求項２に係る本件補正が「明りょうでない記載の釈明」を目的とするものに該当するとは主張していない。
　さらに、補正後の請求項２に係る本件補正が、特許法第１７条の２第４項第１号に掲げられた「請求項の削除」、又は同項第３号に掲げられた「誤記の訂正」を目的とするものに該当するとは認められない。
　したがって、補正後の請求項２に係る本件補正は、特許法第１７条の２第４項に規定する要件を満たしていない。
　
（３−３）補正の適否の判断
　上記（３−１）及び（３−２）の検討によれば、本件補正は、特許法第１７条の２第４項の規定に違反するものであり、特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下されるべきものである。
　
３．本願発明
　以上のとおり、平成１７年３月１１日付の手続補正は上記のとおり却下されたので、本願の請求項１０に係る発明（以下「本願発明」という。）は、平成１６年１０月１９日付手続補正書の特許請求の範囲の請求項１０に記載された事項により特定される、以下のとおりのものである。
「一つかそれ以上のオルターナティブ取引システムから証券や商品の取引情報を取引者に供給するデータ処理方法において、
　それぞれ参加するオルターナティブ取引システムから注文情報を受け取り、
　情報を共通のプロトコルに変換し、
　それぞれのオルターナティブ取引システムから入力された注文情報を統合し単一の注文控えをデータとして蓄積し、
　統合された注文控えを配布し、
　前記注文控えを取引者に表示する、
というステップを含むデータ処理方法。」
　
４．引用例
　原査定の拒絶の理由に引用された国際公開第９９／００７５３号パンフレット（以下「引用例１」という。）には、図面とともに、以下の事項が記載されている。
（ア）「Detailed Description
　
Referring now to the drawings, and initially Figure 1, there is 
illustrated a system diagram according to a first embodiment of 
the present invention. A gateway1 which may be located, for example,
at a broker's facility, can be implemented using, for example, 
server class PC, a mainframe computer, a microcomputer, or some 
other type of processing system. The gateway 1 is coupled to one 
or more customer system 2, which may be, for example, a 
microcomputer, mainframe computer or some other type of 
processing system where a customer may place orders or transact 
business, via a customer/gateway interface 8 which may include 
some form of communications link using, for example, electronic 
or optical transmission of data, and which may be, for example, 
a modem connection over a telephone line, LAN, WAN, Intranet,
Internet, dedicated line, satellite link, optical link or some other
type of connection. The gateway 1 may additionally be coupled to 
other customer system (s) 4 via additional customer/gateway 
interfaces 10, and/or to broker system (s) 6, e. g., terminal (s) 
and/or computers, which may be located, for example, at the broker's
facility or affiliated facilities, via other customer/gateway 
interfaces 12, e. g., modem connection over a telephone line, 
LAN, WAN, dedicated line, satellite link, optical link or some 
other type of connection. The broker system (s) can be used, 
for example, on trading desks or by sales people at the broker's 
facility for placing customer telephone orders or trades for 
in-house accounts such as mutual funds or hedge funds or for 
the broker's own account.
 All communications between the gateway 1 and the customer systems 
2,4 and/or the broker system (s) 6 occur using a common protocol 
(format and/or language), for example, Financial Information 
Exchange (FIX) protocol, which is in the public domain, 
commonly known and used as a universal trader protocol, and is 
described in detail in, for example, the FIX 4.0 specification and 
release notes issued by the FIX Technical Committee on January 
13,1996, and available at www. fixprotocol. org., which is 
incorporated herein by reference.
 The gateway 1 is also coupled to one or more financial exchanges 
16,18,20,22, for example, NYSE 16, NASDAQ 18, TSE 20,CBOE 22, 
which may be, for example, a microcomputer, mainframe computer 
or some other type of processing system, where the exchange may 
receive and process orders, via an exchange/gateway interface 24,26,
28,30 which may include some form of communications link using, 
for example, electronic or optical transmission of data, and which 
may be, for example, a modem connection over a telephone line, 
LAN, WAN, dedicated line, satellite link, optical link or some other
type of connection. 
The communications between the gateway 1 and each exchange 16,18,20,
22 occurs using a proprietary protocol (format and/or language) 
specific for the relevant exchange. For example, the NYSE 16 uses 
CMS protocol, and TSE 20 uses STAMP protocol. Thus, any 
information transmitted from the gateway1 to the NYSE 16 must be in 
CMS protocol, while any information transmitted from the gatewayI to
the TSE 20 must be in STAMP protocol.
　
The gateway 1 serves as the link or interface between the customer 
systems 2, 4 and/or broker system (s) 6, and the exchanges 16,18,
20,22.
　
Referring now to Figure 2, there is shown a block diagram of the 
internal structure of the gateway 1 according to a first embodiment 
of the present invention. The gateway 1 includes a processor 50, 
which may be, for example, a microprocessor, a microprocessor array,
or a microcomputer. The processor 50 is coupled to a memory 52, for 
example a RAM, which is used to store information received from the 
customer system (s) 2,4 and/or broker system (s), and from the 
exchanges 16,18,20,22. The information stored in the memory 52 may 
include, for example, transaction information, information relating 
to an order placed by a customer or broker, e.g., stock symbol, 
quantity, price, exchange, etc., acknowledgment information, and 
confirmation information. The information stored in memory52 may be 
stored, for example, in or as a data base or in any format desired.
　
The gateway 1 may also include a storage device 54, for example, a 
RAM, a hard drive, tape drive, ZIP drive, optical drive, holographic
storage device, or any other type of storage device, coupled to the 
processor 50. The storage device 54 may be internal to or physically
located within the gateway system or may housed at a remote 
location. 
Alternatively, the memory 52 and the storage device 54 may be 
comprised of a single device. The storage device 54 may be used to 
store, for example, transaction information, information relating to
an order placed by a customer or broker, e. g., financial instrument
symbol, quantity, price, exchange, etc., acknowledgment information,
and confirmation information. The storage device54 may be used, 
for example, as a backup for the memory 52 and/or to archive 
historical information.
　
Referring now to Figure 3, there is shown a diagram of a format for 
tracking data stored in memory 52 as or in a data base according to 
a first embodiment of the present invention. The tracking data data 
base may include a number of lists or fields of information relating
to the transactions transmitted to the gateway 1 by a customer 
system. Column 70 includes a list of the transaction number for 
each transaction transmitted to the gateway 1. Column 72 includes 
a list of the symbols for the financial instruments comprising each 
transaction.Column 74 includes a list of the type of transaction 
to be implemented, i. e., buy, sell, sell short, etc. Column 76 
includes a list of the quantity of the respective financial 
instrument to be traded. Column 78 includes a list of the price at 
which the financial instrument should be traded. Column 80 
includes a list of the exchange on which the relevant financial 
instrument is listed.
Column 82 includes a list indicating for each transaction whether 
an acknowledgment has been received. Column 84 includes a list 
indicating for each transaction whether a confirmation has been 
received. Column 86 includes a list indicating status of the order, 
i. e., rejected, accepted, filled, partially filled, etc. Column 88 
includes a list indicating the quantity of the financial instrument 
traded for each transaction. Column 90 includes a list indicating 
the number of financial instruments outstanding or remaining for 
eachrequested transaction. Column 92 includes a list indicating 
the price at which each unit was traded.
　
Alternatively, the data base may include fewer or more columns than 
those indicated and various columns may be combined or divided as 
desired.
Additionally, the information may be stored in some other manner 
besides as a data base, including but not limited to being coded, 
stored as a data word, as compressed data, etc. 
The data rates at the customer/gateway interfaces 8,10 and/or 12 
(as shown in Figure1) are approximately the same since they use a 
common protocol. The data rate between customer system (s) 2,4 
and/or broker system (s) 6, and the gateway 1 can be, for example, 
56 Kbps. Alternatively, the data rates at customer/gateway 
interfaces 8,10 and/or 12 may vary. The data rates between the 
gateway I and the exchanges at exchange/gateway interface 24,26,
28,30 may be similar or may vary, and can be, for example, 9600 bps.
Whatever data rates are used, the memory 52 should be of sufficient 
capacity to store all received information without losing or 
over-writing any data.
　
Because of the differences in data rates between the 
customer/gateway interfaces and the exchange/gateway interface, 
the memory 52 may also be used as a buffer to store any transaction 
information that may accumulate while waiting to be transmitted to 
the exchanges, or to customers/brokers.
Alternatively, a separate memory may be used to buffer this 
transaction information.
　
Communications between the gateway 1 and customer system (s) 2,4 and
broker system (s) 6 may also include some form of security such as, 
for example, coding of information, time offsets and password 
protection, to insure the integrity and secrecy of the information 
being transmitted.
　
The gateway 1 processes information, for example, by using one or 
moreprograms running one or more threads of execution (i. e.,
sharing vesources) or by using multiple programs, such that multiple
pieces of information may be processed at the same time. The gateway
1 is, therefore, able to communicate with multiple customer system 
(s) 2,4 and/or broker system (s) 6, and with multiple exchanges 
16,18,20,22 simultaneously. Each customer system and/or broker 
system that transmits information, i. e., an order, to the gateway I
is allocated a separatethread, i. e., a separate flag is set, and a 
separate program is invoked to process the information from that 
customer system and/or broker system.
　
The operation of the gateway, including processing of information 
can be understood more readily by referring to Figure 4, which is 
a flow diagram of the gateway operation according to a first 
embodiment of the present invention. In step 100 transaction 
information, e. g., an order, is received from a customer system 2 
by the gatewayI in an common protocol such as, for example, 
FIX protocol. The order is processed in steps 102,104,106 and 108.
Because an order may include one or more transactions such as, for 
example, buying and/or selling equities, buying and/or selling 
futures, buying and/or selling bonds, buying and/or selling options, 
etc., the processing should include a counting step 102 where the 
number of transactions is determined.
The processing also includes a step 104 where flags are set for each
separate transaction. There may be an additional step (not shown) 
where the information is provided with some form of coding or 
identification so that the processor can identify and match the 
information transmitted to the exchange system (i. e., transaction 
information) with the information received from the exchange 
system (i. e., acknowledgment and confirmation information).
　
The processing further includes a step 106 where tracking data 
relating to each transaction is written to a location, for example, 
in memory 52 so that the gateway may keep track of each 
transaction. The tracking data may be written, for example, in 
the form of a data base, and may include information such as, 
for example, described above in relation to Figure 3. Each 
transaction is then translated in step 108 from FIX protocol into 
the proper protocol for the exchange to which it is to be 
transmitted. 
　
For example, if the gateway 1 receives an order from a customer 
system 2 containing three transactions (as shown in Figure 3), 
i. e., (1) purchase 100,000 shares of XYZ stock on the NYSE 
at $17/share, (2) sell 200,000 shares of ABC stock on the TSE 
at $42/share, and (3) buy 1000 July put options for LMN stock 
at last asking price, the gateway 1 will count the number of 
transactions and set flags foreach, i. e., three flags. The gateway 
I will also write tracking data relating to each of the three 
transactions into memory. The gateway 1 will then begin 
translating the first transaction from FIX protocol into CMS 
protocol, the second transaction from FIX protocol into STAMP 
protocol, and the third transaction from FIX protocol into the 
proper protocol for the relevant options exchange.
　
The gateway 1 may run a separate sub-program for processing 
(including translation) for each customer, or may otherwise 
process transactions for each customer individually. The processing 
of transactions for each customer may occur simultaneously or 
consecutively since the gateway 1 is capable of parallel processing,
i. e., processing for each customer simultaneously.
　
Alternatively, the processing may include only some of the steps 
discussed above or it may include additional steps such as, for 
example, error correction, data compression, etc.
　
When the processing of a transaction received from a customer system
iscompleted, in step 110 the gateway I transmits the translated 
(reformatted)transaction information to the properexchange.-The 
gatewayI then receives an acknowledgment from the exchange, in step 
112, indicating that the transaction information has been received. 
The gateway processes the acknowledgment in steps 114, 116 and118. 
In step 114 the gateway 1 translates the acknowledgment from the 
exchange's protocol into a common protocol such as, for example, FIX
protocol. In step 116 the gateway locates the tracking data in 
memory 52 relating to the relevant transaction and updates the 
tracking data in memory 52. In step118 the gateway 1 transmits 
the acknowledgment information to the customer system 2.
　
Some time after the acknowledgment is received by the gateway1, in 
step 120 the gateway 1 receives a transaction confirmation from the 
relevant exchange. The transaction confirmation indicates the status
of the transaction and may include information such as, for example,
financial instrument symbol, order accepted and filled/partially 
filled or rejected, quantity, price, etc.
　
The gateway processes the transaction confirmation in steps 122,124 
and 126.In step 122 the gateway I translates the transaction 
confirmation from the exchange's protocol into a common protocol 
such as, for example, FIX protocol. In step 124 the gateway locates 
the tracking data in memory 52 relating to the relevant transaction 
and updates the tracking data in memory 52. In step 126 the gateway 
1 transmits the transaction confirmation to the customer system 2.
　
In step 128 the gateway transfers the contents of memory 52 relating
to transactions for which transaction confirmations have been 
received into storage device 54. The storage device 54 may be 
accessed by the customer system (s) 2,4 and the broker system (s) 
6, and by the broker. Safety features in the gateway 1 only allow 
a customer system/broker system access to the transactions placed 
by that customer system/broker system.
　
The system can accommodateand support any number of customers and/or
brokers as well as any number of financial markets (exchanges). 」
（明細書第６頁第２２行−第１３頁第２２行）
 
（仮訳：詳細な説明
　図を参照し、まず図１には、本発明の第一の実施例によるシステム図が示される。例えばブローカーの施設に位置するゲートウェイ１は、例えばサーバクラスＰＣ、メインフレームコンピュータ、マイクロコンピュータ、またはその他のタイプの処理システムを使って実装することができる。ゲートウェイ１は、例えばマイクロコンピュータ、メインフレームコンピュータまたはその他タイプの処理システムでよい一つ以上の顧客システム２に接続され、ここでは、例えば電子的または光学的データ転送を使う一定形式の通信リンクを含み、例えば電話回線によるモデム接続、ＬＡＮ、ＷＡＮ、イントラネット、インターネット、専用回線、衛星リンク、光学リンクその他のタイプの接続でよい顧客／ゲートウェイインターフェース８を介して顧客が発注または取引を行う。ゲートウェイ１はさらに、追加顧客／ゲートウェイインターフェース１０を介して、他の顧客システム４、および／または、電話回線によるモデム接続、ＬＡＮ、ＷＡＮ、専用回線、衛星リンク、光学リンクその他タイプの接続などの他の顧客／ゲートウェイインターフェース１２を介して、例えばブローカーの施設または関連施設にある端末および／またはコンピュータなどのブローカーシステム６に接続することができる。ブローカーシステムは、例えばトレーディングデスクで、またはブローカーの施設の販売員が顧客の電話注文またはミューチュアルファンドまたはヘッジファンドなどの社内勘定またはブローカー自身の勘定の取引に用いることができる。
　ゲートウェイ１および顧客システム２，４および／またはブローカーシステム６との間の通信はすべて、例えば、パブリックドメイン内にあり、よく知られており、汎用のトレーダープロトコルとして使われ、例えばＦＩＸ４．０仕様および1996年1月13日にFIX技術委員会が発行したリリースノートに詳細に記述され、参照により本書に組み込むwww.fixprotocol.orgで利用可能なFinancial Informa tion Exchange（FIX）プロトコルなどの共通プロトコル（フォーマットおよび／または言語）を使って発生する。
　ゲートウェイ１はまた、例えばマイクロコンピュータ、メインフレームコンピュータその他のタイプの処理システムでよい例えばＮＹＳＥ１６、ＮＡＳＤＡＱ１８、ＴＳＥ２０、ＣＢＯＥ２２などの１以上の金融取引所１６、１８、２０、２２に接続され、ここでは取引所が例えば電話回線によるモデム接続、ＬＡＮ、ＷＡＮ、専用回線、衛星リンク、光学リンクその他タイプの接続でよいデータの電子または光学転送を使う一定形式の通信リンクを含む取引所／ゲートウェイインターフェース２４、２６、２８、３０を介して注文の受け取りと処理を行う。
　ゲートウェイ１と各取引所１６、１８、２０、２２との間の通信は、関連取引所固有の独自のプロトコル（フォーマットおよび／または言語）を使って発生する。例えば、ＮＹＳＥ１６はＣＭＳプロトコル、ＴＳＥ２０はＳＴＡＭＰプロトコルを使う。そのため、ゲートウェイ１からＮＹＳＥ１６に転送される情報はＣＭＳプロトコルでなければならず、ゲートウェイ１からＴＳＥ２０に転送される情報はＳＴＡＭＰプロトコルでなければならない。
　ゲートウェイ１は、顧客システム２，４および／またはブローカーシステム６と取引所１６、１８、２０、２２との間のリンクまたはインターフェースとして働く。
　図２を参照すると、本発明の第１の実施例によるゲートウェイ１の内部構造のブロック図が示される。ゲートウェイ１は、例えばマイクロプロセッサ、マイクロプロセッサアレイ、またはマイクロコンピュータでよいプロセッサ５０を含む。プロセッサ５０は、顧客システム２，４および／またはブローカーシステム、および取引所１６、１８、２０、２２から受け取った情報の保存に用いるＲＡＭなどのメモリ５２に接続される。メモリ５２に保存される情報は、例えば取引情報、顧客またはブローカーによる注文に関連する株式銘柄、数量、価格、為替などの情報、受け取り承認情報、確認情報などを含むことができる。メモリ５２に保存される情報は、例えばデータベース内またはデータベースとして、あるいは所望のあらゆるフォーマットで保存することができる。
　ゲートウェイ１は、プロセッサ５０に接続された、例えばＲＡＭ、ハードドライブ、テープドライブ、ＺＩＰドライブ、光学ドライブ、ホログラフ記憶装置またはあらゆるタイプの記憶装置等の記憶装置５４を含むことができる。記憶装置５４は、ゲートウェイシステム内部または物理的にその中に配置でき、または遠隔地に収納することができる。あるいは、メモリ５２および記憶装置５４は１つの装置からなることができる。記憶装置５４は、例えば取引情報、金融商品銘柄、数量、価格、為替など顧客またはブローカーによる注文に関連する情報、受け取り承認情報および確認情報の保存に用いることができる。記憶装置５４は、例えばメモリ５２のバックアップとして、および/または履歴情報のアーカイブに用いることができる。
　図３を参照すると、本発明の第１実施例によるデータベースとして、あるいはデータベース内のメモリ５２に保存された追跡データのフォーマットの図を示す。追跡データデータベースは、顧客システムからゲートウェイ１に転送される取引に関連する情報のリストまたはフィールドを多数含むことができる。列７０は、ゲートウェイ１に転送される各取引の取引番号のリストを含む。列７２は、各取引を構成する金融商品の銘柄のリストを含む。列７４は、実施される取引のタイプのリスト、すなわち、買い、売り、空売りなどを含む。列７６は、トレードする各金融商品の数量のリストを含む。列７８は、金融商品をトレードしなければならない価格のリストを含む。列８０は、関連金融商品を売る取引所のリストを含む。列８２は、各取引について受け取り承認を受け取ったか否かを示すリストを含む。列８４は、各取引について確認を受け取ったか否かを示すリストを含む。列８６は、注文の状態、すなわち、拒絶、受理、履行、部分履行などを示すリストを含む。列８８は、各取引でトレードする金融商品の数量を示すリストを含む。列９０は、各要求取引について未済または残っている金融商品の数を示すリストを含む。列９２は、各単位をトレードする価格を示すリストを含む。
　あるいは、データベースはここに示す以上あるいは以下の列を含み、所望により各種列を組み合わせまたは分割することができる。さらに、情報は、コード化、データワードとしての保存、圧縮データとしての保存などを限定せずに含むデータベースとして以外の他の方法で保存することができる。
　顧客／ゲートウェイインターフェース８，１０および／または１２での（図１に示す）データレートは、共通プロトコルを用いているためほぼ同じである。顧客システム２、４および／またはブローカーシステム６、およびゲートウェイ１との間のデータレートは、例えば５６Ｋｂｐｓとすることができる。あるいは、顧客／ゲートウェイインターフェース８，１０および／または１２のデータレートは可変にできる。ゲートウェイ１及び取引所／ゲートウェイインターフェース２４、２６、２８、３０の取引所との間のデータレートは、同様または可変であることができ、例えば９６００ｂｐｓとすることができる。どのようなデータレートを使っても、メモリ５２はデータを失ったり上書きすることなくすべての受信情報を保存できるだけの容量でなければならない。
　顧客／ゲートウェイインターフェースと取引所／ゲートウェイインターフェースとの間のデータレートの相違のため、メモリ５２はまた、取引所または顧客／ブローカーへの転送を待ちながら累積する取引情報を保存するためのバッファとして用いることができる。あるいは、別個メモリを使ってこの取引情報をバッファすることができる。
　ゲートウェイ１と顧客システム２，４およびブローカーシステム６との間の通信はまた、例えば情報のコーディング、タイムオフセットおよびパスワード保護等一定形式のセキュリティを含んで、転送する情報の整合性と機密性を確保することができる。
　ゲートウェイ１は、複数の情報を同時に処理できるよう、例えば１以上の実行スレッド（すなわち資源共有）で動く１以上のプログラムを使って、または複数のプログラムを使って情報を処理することができる。そのため、ゲートウェイ１は複数の顧客システム２，４および／またはブローカーシステム６および複数の取引所１６、１８、２０、２２と同時に通信できる。情報、すなわち注文をゲートウェイ１に転送する各顧客システムおよび／またはブローカーシステムには、別スレッドを割り当て、すなわち別フラッグを設定し、別プログラムを呼び出して、その顧客システムおよび／またはブローカーシステムからの情報を処理する。
　情報の処理を含むゲートウェイの動作は、本発明の第１実施例によるゲートウェイの動作のフロー図である図４を参照することによって容易に理解される。ステップ１００では、注文などの取引情報が、例えばＦＩＸプロトコルなどの共通プロトコルでゲートウェイ１によって顧客システム２から受け取られる。その注文は、ステップ１０２、１０４、１０６及び１０８で処理される。注文には、例えばエクイティの売りおよび／または買い、先物の売りおよび／または買い、債券の売りおよび／または買い、オプションの売りおよび／または買い等の１以上の取引が含まれることがあるため、処理には、取引数を決定するカウントステップ１０２を含まなければならない。処理はまたステップ１０４を含み、別個取引それぞれについてフラッグが設定される。情報に一定形式のコーディングまたは識別を与えてプロセッサが取引所システムに送られる情報（すなわち取引情報）を識別し、取引所システムから受け取った情報（すなわち、受け取り承認および確認情報）と一致させる追加ステップ（図示せず）を設けることができる。
　処理はさらにステップ１０６を含み、各取引に関連する追跡データが、例えばメモリ５２の位置に書き込まれ、ゲートウェイが各取引を追跡できるようにする。追跡データは、例えばデータベースの形式で書きこみ、例えば図３に関連して上述する情報を含むことができる。そして各取引をステップ１０８でＦＩＸプロトコルからそれを転送する取引所に適したプロトコルに翻訳する。
　例えば、ゲートウェイ１が（図３に示すように）３個の取引、すなわち、（１）ＮＹＳＥで＄１７／株でのＸＹＺ株100,000株の購入、（２）ＴＳＥで＄４２／株でのＡＢＣ株200,000株の売り、および（３）直近の売り呼び値でのＬＭＮ株７月限プット・オプション1,000単位の買い、を含む顧客システム２からの注文を受けると、ゲートウェイ１は取引数をカウントし、それぞれについて、すなわち３個のフラッグを設定する。ゲートウェイ１はまた、３個の取引のそれぞれに関連する追跡データをメモリに書きこむ。ゲートウェイ１はそして第１の取引をＦＩＸプロトコルからＣＭＳプロトコルに、第２の取引をＦＩＸプロトコルからＳＴＡＭＰプロトコルへ、第３の取引をＦＩＸプロトコルから関連オプション取引所に適切なプロトコルへ翻訳し始める。
　ゲートウェイ１は、各顧客について（翻訳を含む）処理のための別個のサブプログラムを走らせるか、各顧客について個々に取引を処理することができる。各顧客のための取引の処理は、ゲートウェイ１が並行処理、すなわち各顧客を同時に処理することができるため、同時または逐次に発生することができる。
　あるいは、処理に上述のステップの一部のみ含むか、例えばエラー是正、データ圧縮などの追加ステップを含むことができる。
　顧客システムから受け取った取引の処理が完了すると、ステップ１１０で、ゲートウェイ１は翻訳（再フォーマット）された取引情報を適切な取引所に転送する。そしてゲートウェイ１は、ステップ１１２で取引所から取引情報を受け取ったことを示す受け取り承認を受け取る。ゲートウェイはステップ１１４、１１６および１１８で受け取り承認を処理する。ステップ１１４では、ゲートウェイ１は受け取り承認を取引所のプロトコルから、例えばＦＩＸプロトコルなどの共通プロトコルに翻訳する。ステップ１１６で、ゲートウェイは関連取引に関連するメモリ５２で追跡データを探し、メモリ５２で追跡データをアップデートする。ステップ１１８で、ゲートウェイ１は、受け取り承認情報を顧客システム２に転送する。
　ゲートウェイが受け取り承認を受け取ってからしばらくして、ステップ１２０で、ゲートウェイ１は関連取引所から取引確認を受け取る。取引確認は、取引の状態を示し、例えば、金融商品銘柄、受理および履行／部分履行または拒絶した注文、数量、価格などの情報を含むことができる。
　ゲートウェイは、ステップ１２２、１２４および１２６で取引確認を処理する。ステップ１２２で、ゲートウェイ１は取引確認を取引所のプロトコルから、例えばＦＩＸプロトコルなどの共通プロトコルに翻訳する。ステップ１２４で、ゲートウェイは関連取引に関連するメモリ５２で追跡データを探し、メモリ５２で追跡データをアップデートする。ステップ１２６で、ゲートウェイ１は取引確認を顧客システム２に転送する。
　ステップ１２８で、ゲートウェイは取引確認を受け取った取引に関連するメモリ５２の内容を記憶装置５４に転送する。記憶装置５４は、顧客システム２，４およびブローカーシステム６、およびブローカーによってアクセスできる。ゲートウェイ１の安全特性により、顧客システム／ブローカーシステムだけがその顧客システム／ブローカーシステムが発した取引にアクセスすることができる。
　このシステムはあらゆる数の顧客および／またはブローカーとあらゆる数の金融市場（取引所）を収容し、サポートすることができる。）
　
　以上の記載からみて、引用例１には、
『４つの「金融取引所（１６，１８，２０，２２）のシステム」から証券等の金融商品を顧客に供給する金融商品データの処理方法において、
　それぞれ参加する「金融取引所（１６，１８，２０，２２）のシステム」から「取引確認」を受取り、
　前記「取引確認」を共通のプロトコルに変換し、
それぞれの「金融取引所（１６，１８，２０，２２）のシステム」から入力された「取引確認」を顧客に転送する、
というステップを含むデータ処理方法。』
との発明（以下「引用例発明」という。）が記載されている。
　
５．対比
　本願発明と引用例発明とを比較すると、引用例発明の「顧客」、「証券等の金融商品」、「共通プロトコル」、「転送する」は、本願発明の「取引者」、「証券や商品」、「共通のプロトコル」、「配布する」に相当する。
　また、引用例発明の「取引確認」は、履行した注文、数量、価格などの情報を含むので、本願発明の「注文情報」及び「情報」に相当する。
　また、引用例発明の転送する「取引確認」と本願発明の「注文控え」とは、注文情報を統合した情報であるかどうかで相違するものの、「注文情報に関する情報」という点で共通する。
　さらに、引用例発明の「金融取引所（１６，１８，２０，２２）のシステム」と本願発明の「オルターナティブ取引システム」とは、以下の相違点１で相違するものの、「取引システム」という点で共通する。
　そうすると、本願発明は、
「一つかそれ以上の取引システムから証券や商品の取引情報を取引者に供給するデータ処理方法において、
　それぞれ参加する取引システムから注文情報を受け取り、
　情報を共通のプロトコルに変換し、
　それぞれの取引システムから入力された注文情報に関する情報を配布する、
というステップを含むデータ処理方法。」
の点で一致し、以下の点で相違する。
（相違点１）
　本願発明では、取引システムが、オルターナティブ取引システムであるのに対し、引用例発明では、取引システムが、オルターナティブ取引システムであることが明記されていない点。
　
（相違点２）
　本願発明では、注文情報を統合し単一の注文控えをデータとして蓄積して配布し、配布された注文控えを取引者に表示するのに対し、引用例発明では、注文情報を統合しておらず、統合した単一の注文控えをデータとして蓄積しておらず、また、配布された注文控えを取引者に表示しているかどうか明記されていない点。
　
６．当審の判断
（相違点１について）
　オルターナティブ取引システムにより取引を行うことは周知事項であるので、引用例発明において、取引システムをオルターナティブ取引システムにすることは当業者が容易に考えられる事項である。
　したがって、相違点１に係る本願発明の構成は、引用例発明及び周知事項に基づいて当業者が容易に想到し得たものである。
　
（相違点２について）
　特定のユーザに対する複数の取引に関する情報を一括して一つにまとめ、当該ユーザに送付することは周知事項であり（例えば、「ＩＮＳネットサービス（第３回）　確かなＩＮＳネット（サービス）の提供に向けて」，ＮＴＴ技術ジャーナル第６巻第５号，社団法人電気通信協会，１９９４年５月１日，第８６−８９頁等参照）、また、処理されたデータを蓄積しておくことは一般的に行われている周知事項であり、さらに、配信された情報を確認するために表示することは一般的に行われている周知事項であるので、引用例発明において、注文情報を統合して単一の注文控えをデータとして蓄積して取引者に配布し、配布した注文控えを取引者に確認させるために当該注文控えを表示することは当業者が容易に考えられる事項である。
　したがって、相違点２に係る本願発明の構成は、引用例発明及び周知事項に基づいて当業者が容易に想到し得たものである。
　
　そして、本願発明の作用効果も、引用例１及び周知事項から当業者が予測できる範囲のものである。
　したがって、本願発明は、引用例１に記載された発明及び周知事項に基づいて、当業者が容易に発明をすることができたものである。
　
７．むすび
　以上のとおり、本願発明は、引用例１に記載された発明及び周知事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。