【事件の表示】
　特願２００２−　１９８６８「自動車情報を交換するコンピュータ・システム及び方法」拒絶査定不服審判事件〔平成１４年１２月　６日出願公開、特開２００２−３５２０９０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は，平成１４年１月２９日（パリ条約による優先権主張２００１年１月３０日，米国）の出願であって，平成１６年１０月２２日付けで拒絶査定がなされ，これに対して平成１７年１月１１日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされ，さらに平成２１年４月１日付けの拒絶理由通知に対して同年６月３日付けで手続補正がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下，「本願発明」という。）は，平成２１年６月３日付けの手続補正により補正された特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものである。
　
「　【請求項１】
　自動車取引に携わる少なくとも２つの自動車取引先のコンピュータ・システム間で、自動車情報を交換するコンピュータ・システムであって、該コンピュータ・システムは、中央処理装置、Ｉ／Ｏインタフェース及びメモリーを含み、該メモリーは前記中央処理装置によって実行される下記プログラムを記憶し、
　該プログラムは、
　取引要素をマッピングするマッピング・プログラムであって、前記取引要素を読出して、前記取引要素の発信元と、前記取引要素が関連する自動車取引と、前記取引要素が経路指定されるべき受信側とを決定する、前記マッピング・プログラムと、
　前記取引要素をマッピング後に、第１の取引先のコンピュータ・システムの専用スキーマから汎用スキーマにそして該汎用スキーマから第２の取引先のコンピュータ・システムの専用スキーマに、前記第１の取引先のコンピュータ・システムから受信した取引要素を変換する変換プログラムであって、前記取引要素の変換は、前記第１の取引先のコンピュータ・システムの取引要素のデータ形式及びアプリケーション形式を、前記第２の取引先のコンピュータ・システムにおいて利用できる形式に変換することを含む、前記変換プログラムと、
　前記取引要素を変換後に、第１の通信プロトコルを使用する前記第１の取引先のコンピュータ・システムから第２の通信プロトコルを使用する前記第２の取引先のコンピュータ・システムへ前記変換された取引要素を前記第２の通信プロトコルで経路指定するルーティング・プログラムと、
　前記取引要素を追跡して前記第１の取引先のコンピュータ・システムにステータス情報を提供する取引管理プログラムであって、前記ステータス情報は、前記変換プログラムによる受信、前記変換プログラムによる変換処理又は前記第２の取引先のコンピュータ・システムへの経路指定を含む、前記取引管理プログラムと
　を含む、前記コンピュータ・システム。　」 
　
３．引用例 
（１）引用例
　これに対して，当審において，平成２１年４月１日付けで通知した拒絶の理由に引用した本願の優先権主張の日前の平成１２年１２月３１日に頒布された「Brian E. Travis「XMLとSOAPによるBizTalk Server設計入門」，2000年12月31日初版発行（株式会社アスキー）」（以下，「引用例」という。）には，図面とともに，次の（ア）乃至（サ）の事項が記載されている。
　
（ア）「 第１０章
　ＢｉｚＴａｌｋシステムの条件
　ＢｉｚＴａｌｋサーバーは、ＢｉｚＴａｌｋドキュメントを読み取って処理するソフトウェアである。ＢｉｚＴａｌｋ Ｆｒａｍｅｗｏｒｋは、ＸＭＬ構文を使用する自己記述型の構造であるため、ＢｉｚＴａｌｋサーバーとして動作するアプリケーションはＸＭＬを理解しなければならない。つまり、ＸＭＬドキュメントをロードして、そのコンテンツにアクセスできなければならない。こうした能力は、ＢｉｚＴａｌｋサーバーの基本条件にすぎない。当然ながら、ＸＭＬドキュメントをロードして、それにアクセスするだけのサーバーでは、エンタープライズコンピューティング環境ではほとんど使いものにならない。「ＢｉｚＴａｌｋ Ｆｒａｍｅｗｏｒｋ ２．０ Ｄｏｃｕｍｅｎｔ ａｎｄ Ｍｅｓｓａｇｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」は、こうした基本的なタスクを実行するソフトウェアを、ＢＦＣサーバーと呼んでいる。
　この章では、自分の環境で使用するＢｉｚＴａｌｋサーバーの選択や構築にあたって、検討すべき条件について説明する。本書の基本的な定義でいうＢｉｚＴａｌｋサーバーとは、ＢｉｚＴａｌｋドキュメントを読み取って、パッケージの特定の情報を検索し、その情報（ドキュメントの一部または全体）を適切なアプリケーションに送信する、フィルタのような単純なものかもしれない。あるいは、統合サプライチェーン管理システムに欠かせない、高度なコンポーネントかもしれない。ＢｉｚＴａｌｋサーバーは、エンタープライズ全体がビジネスパートナーと取り引きするためのアプリケーションとみなすことができる。
　ＸＭＬ処理アプリケーションを呼び出すことができるコンピュータ言語を利用すれば、任意のオペレーティングシステムプラットフォームで動作するＢｉｚＴａｌｋサーバーを開発することができる。ＢｉｚＴａｌｋサーバーは、ＷｉｎｄｏｗｓやＵＮＩＸをはじめとする、任意のオペレーティングシステムで動作する。また、Ｊａｖａや、Ｐｙｔｈｏｎ、ＯｍｎｉＭａｒｋといった、プラットフォームに依存しない言語で開発することができる。
　ＢｉｚＴａｌｋサーバーは、動的なビジネス環境の変化に対応できるほど柔軟でなければならず、レガシーアプリケーションと共存し、それを操作できるような高度なインターフェイスを備えていなければならない。ＢｉｚＴａｌｋサーバーの所有者は、それを毎日運用するビジネスユーザーでなければならない。誰もが同じシステムを使っているとは限らないため、ＢｉｚＴａｌｋサーバーはクロスプラットフォームとクロス言語のやり取りを可能にしなければならない。この章では、ＢｉｚＴａｌｋサーバーに要求される機能について説明しよう。これらの機能のサンプルについては、第１１章で紹介する。　」（第２０１頁第１行−第２０２頁第４行）
　
（イ）「　１０．ｌ  任意のトランスポートによる確実な伝送
　孤高を保つＢｉｚＴａｌｋドキュメントは、何と美しいことか。だが、ＢｉｚＴａｌｋドキュメントは使うためのものであって、賞賛したり鑑賞したりするためのものではない。ＢｉｚＴａｌｋ ドキュメントがその目的を果たすためには、伝送されなければならない。ビジネスパートナーどうしがＢｉｚＴａｌｋドキュメントをやり取りするためには、何らかの配送システムが必要である。この場合は電子情報を扱うため、この配送を実現するには、場所から場所ヘビット情報を伝送するプロセスを使用する。
　ＨＴＴＰは、こうしたビットを伝送する、もっとも簡単な手段である。ＨＴＴＰは普遍的であり、実質的には世界のすべてのファイアウォールが、ＨＴＴＰ呼び出しの自由な通過を認めている。だが、すべてのべンダーがＨＴＴＰ経由でリクエストを受信できるとは限らない。中には、ＨＴＴＰ経由のテキスト伝送に異議を唱えるベンダーもあるだろう。ＨＴＴＰに代わるプロトコルの１つは、ＦＴＰである。ＦＴＰは、ユーザーＩＤとパスワードを要求する。このログインレイヤによって、偽装メッセージを受信する危険は少なくなる。ビジネスパートナーがＦＴＰサーバーを持っていないとしても、電子メールなら持っているはずだ。この場合のＢｉｚＴａｌｋサーバーは、ＳＭＴＰ経由でメッセージを送信できなければならない。ＳＭＴＰサーバーは、電子メールメッセージをインターネットに転送するように設計されている。
　ビジネスパートナーが２０世紀に取り残されたままで、電子メールすら持っていない場合もあるだろう。このような場合は、ＢｉｚＴａｌｋドキュメントをもっと原始的な方法で伝送する必要がある。ＢｉｚＴａｌｋサーバーの柔軟性を最大にするには、メッセージをファックスに送信する能力や、それらを郵便で配送できるように印刷する能力を備えなければならない。これらのプロトコルは人間が読むドキュメントを伝送するように設計されているため、ＢｉｚＴａｌｋサーバーは、人間が読むのに適した方法で、ビジネスドキュメントをレンダリングする能力も備えていなければならない。
　ＨＨＴＰや、ＦＴＰ、ＳＭＴＰの最大の問題は、デフォルトでは暗号化されないことだ。こうしたトランスポートプロトコルが一般にインターネットに依存するという事実が、この問題をますます悪化させている。インターネットは、ＴＣＰパケットをかぎわける能力を持つユーザーに、あなたのリクエストを暴露する。これにより、次のセキュリティという条件が浮上する。　」（第２０２頁第５−３３行）
　
（ウ）「　ｌ０．３    ルーティング
　ＢｉｚＴａｌｋサーバーのもっとも重要な機能は、あなたのシステムからほかのシステムヘドキュメントを移動することである。この機能は、ＨＴＴＰ経由でＷｅｂサーバーにリクエストをポストするだけの単純なものかもしれないし、ファイアウォールといったセキュリティ手段をすり抜ける、複雑なルーティング手続きを要求するものかもしれない。また、ビジネスパートナーから応答を受け取ったら、応答を社内の適切な部署に転送する必要があるだろう。
　市役所の職員について考えてみよう。市役所では、窓口に書類を提出する。その書類は、駐車違反や交通違反の罰金を支払うためのものかもしれないし、家を増築するためのものかもしれない。あるいは、州に婚姻を承認してもらうための用紙かもしれない。窓口の職員は、書類を適切な部署に転送する。この通例化された事務的なフロントエンドは、市役所のどの部署に行って書類を提出すればいいのかという悩みを解消する。
　ＢｉｚＴａｌｋサーバーは、この職員のように振る舞う。すなわち、提出されたドキュメントの種類を識別し、ドキュメントを処理する適切な部署に転送する。一般に、こうしたルーティングは、それぞれのトランザクションに適したワークフロープロセスを開始する。
　　１０．４    ワークフロー
　ＢｉｚＴａｌｋドキュメントを受信したら、決まった行動を起こさなければならない。まず、アプリケーションがドキュメントの種類を突き止めることができるように、ドキュメントを複数の部分に分割しなければならない。たとえば、アプリケーションがドキュメントの送信元やドキュメントに適用しなければならない処理を突き止めるには、ａｄｄｒｅｓｓ フィールドとｓｔａｔｅフィールドの情報にアクセスする必要がある。このａｄｄｒｅｓｓフィールドは、受信したＢｉｚＴａｌｋドキュメントが開始する、ワークフローを決定する要因の１つとなる。
　ドキュメントの身元と目的が判明したら、その目的を達成するために必要な作業に移る。これには、ワークフローが必要だ。たとえば、発注書を処理するには、まず、製品をリクエストしてきた会社がパートナーで、その会社の支払いが滞っていないことを確認するだろう。次に、リクエストされた製品の在庫があるかどうか、あるいは、リクエストを満たすために、製品の購入や、組み立て、製造が必要かどうかを確認する。
　ＢｉｚＴａｌｋサーバーは、ドキュメントの到着に応じて、適切なワークフローを開始する手段を備えていなければならない。高度なＢｉｚＴａｌｋサーバーは、アプリケーションからワークフローへのアクセスを支援し、システムの効率的な運用を担当するユーザーがワークフローを管理できるように、ワークフローを作成して管理する何らかの手段を持つことになるだろう。　」（第２０４頁第１−３３行）
　
（エ）「　１０．８   ドキュメントの追跡と状況
　キューを使用する環境では、何か問題が起きた場合に、サーバーに情報を返すことが重要となる。たとえば、データの伝送が完了しなかった場合、サーバーがデータを再送したり、トランザクションを中止するためには、そのことを知っていなければならない。また、オペレータがメッセージのステータスを問い合わせたり、処理全体の統計を取り出すことができる、何らかの手段があるのが理想的だ。
　ＢｉｚＴａｌｋサーバーは、次のような特徴を持つ、高度なトランザクション追跡情報を持つべきだろう。
●ドキュメントをそれぞれごとに、または一括して追跡する。
●ドキュメントが正常に転送されたかどうかを判断する。
●ドキュメント、ビジネスパートナー、または操作に基づいて、追跡データベースを照会する。
●ドキュメントのすべての活動にタイムスタンプを付ける。
●パートナーごとにアカウント活動を簡単に報告できるように、発注書の合計といった、ユーザー定義のデータを保存する。
　トランザクション後にレポートを作成したり、トランザクション後の問い合わせに応じる必要がある場合は、ドキュメントが無効になるまで、あるいはドキュメントが無効になった後も、こうしたすべてのデータを利用できるようにしておく必要があるだろう。　」（第２０５頁第２５行−第２０６頁第１３行）
　
（オ）「　１０．１１  ドキュメントの変換
　どの産業にも、その産業のメンバーどうしがやり取りするためのスキーマがあるはずだ。たとえば、ＡＣＯＲＤという保険産業連合（ｈｔｔｐ：／／ＷＷＷ．ａｃｏｒｄ．ｃｏｍ）は、保険の申込書や払い戻し申請書といった保険関連のドキュメントを交換するためのスキーマを開発している。旅行産業は、ホテルの空室状況やフライトスケジュールをやり取りする規格に取り組んでいる。これらの産業に携わっているとすれば、ＢｉｚＴａｌｋエンベロープの本文から、ビジネスドキュメントを直接読み取らなければならない。
　本書のテーマの１つは、業界にまたがってビジネスを行うことだ。たとえば、自動車産業から受け取る発注書は、その産業のメンバーによって定義された構造を持つだろう。発注書の構造は、輸送産業や航空機製造産業の発注書の構造とは、まったく異なるかもしれない。どの発注書も、おそらく基本的な情報は同じだが、構造は違っている。こうしたアプローチは、従来のＥＤＩとはまったく異なっている。ＥＤＩは、ビジネスパートナーどうしがトランザクションを成立させるために必要とする情報とは無関係に、請求書が１つの構造に準拠していることを要求する。ＢｉｚＴａｌｋサーバーは、これらのドキュメントの情報にアクセスする能力を備えていなければならない。自動車産業の発注書を自分が使用している発注書に変換するプログラムを開発したり、あるいはもっと簡単に、ＸＳＬＴを利用することが考えられる。
　第６章で説明したように、ドキュメントを変換するとしたら、Ｃのプログラムを開発するより、ＸＳＬＴスタイルシートを作成するほうがずつと簡単である。ＸＳＬＴはＸＭＬ入力に直接作用し、必要な構造を持つＸＭＬ出力ドキュメントを生成する。ＸＳＬＴについては、入力の特定のエレメントを出力のエレメントにマッピングする機能と考えればいいだろう。
　また、ＢｉｚＴａｌｋサーバーは、受信したドキュメントを適切な変換マップに照合しなければならない。このマップは、ＢｉｚＴａｌｋサーバーが管理する、ビジネスパートナー協定の一部として定義することができる。
　また、高度なＢｉｚＴａｌｋサーバーは、こうしたＸＳＬＴ変換を簡単に実現し、必要に応じてテストや更新を行う能力を備えていなければならない。　」（第２０７頁第１１行−第２０８頁第３行）
　
（カ）「　ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００は、ビジネスデータを交換するための、データ翻訳／アプリケーション統合サーバーである。ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００はＸＭＬを利用することで、プラットフォームや、オペレーティングシステム、基本技術とは無関係に、業界やビジネスシステムにまたがって、ビジネスパートナーどうしが交渉できるようにする。ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ２０００は、インターネットを介してドキュメントを送受信するための標準ゲートウェイを提供し、データの整合性や、配送、セキュリティを満たすための、幅広いサービスを提供する。                      
　ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００の機能には、着信ドキュメントを受け取って、ドキュメントを解析してそのフォーマットを突き止め、重要な識別情報を抽出し、特定の処理ルールを洗い出し、指定された目的地にドキュメントを配信する能力が含まれている。また、データをマッピングするサービスや、データの整合性、配送、セキュリティを満たすためのサービスも含まれている。
　ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００は、ビジネスドキュメントの構造（スキーマ）を定義するためのツールと、ＸＳＬＴを使ってドキュメントのデータを変換するためのツールを備えている。ＢｉｚＴａｌｋ Ｓｅｒｖｅｒのドキュメントは、こうした変換をマッピングと呼んでいる。
　システムはすべてのデータ伝送にＸＭＬを使用するが、ほかのフォーマットの受理や作成にも対応している。その筆頭にあげられるのは、ＥＤＩである。アプリケーション統合サーバーが要求するデータ変換は、ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００のツールが提供する。
　この章では、ＸＭＬドキュメントの作成や変換に利用できるツールを調べるため、２つの実習を行う。最初の実習ではＢｉｚＴａｌｋエディタを、次の実習ではＢｉｚＴａｌｋマッパーを調べてみよう。　」（第２５７頁第１２行−第２５８頁第８行）
　
（キ）「　１２．２  ＢｉｚＴａｌｋマッパー
　第６章では、あるＸＭＬドキュメントをほかのＸＭＬドキュメントに変換する、ＸＳＬＴプログラムを開発した。この種のドキュメント変換は、ビジネスパートナーが異なるスキーマを使用する場合に、ＢｉｚＴａｌｋプロセスに欠かせない部分となる。
　個人的にはＸＳＬＴを使って直接作業するのが気に入っているが、誰でもそうとは限らない。また、企業にＸＳＬＴのエキスパートを雇う余裕があるとも限らない。ＢｉｚＴａｌｋマッパーを利用すれば、２つの異なるスキーマのレコードとフィールドをマッピングすることができる。ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００は、このマッピングを利用して、社内で共有できるフォーマットや、ビジネスパートナーと共有できるフォーマットに、データを変換する。　」（第２６２頁第１１−２０行）
　
（ク）「　ｌ２．４  ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００のデータ処理
　ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００は、インターネットでＸＭＬドキュメントを移動するほかにも、さまざまな機能を備えている。ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００は、ビジネスパートナー間での契約を管理する、中心基地となるように設計されている。これを実現するために、ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００はパートナーシップ協定を定義するための充実したツールを提供する。
　次のシナリオでは、３つの会社の注文処理の統合に、ＢｉｚＴａｌｋサーバーを使用する方法について調べてみよう。このシナリオに登場する会社は、次のとおりだ。
●Ｔｏｉ Ｃａｒｚ Ｃｏｒｐ．　おもちゃの車の製造メーカー。インターネットの管理にＭｉｃｒｏｓｏｆｔＣｏｍｍｅｒｃｅ Ｓｅｒｖｅｒ ２０００を、勘定システムとしてＧｒｅａｔ Ｐｌａｉｎｓソフトウェアを使用している。ビジネスパートナーとの関係を、ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００ で管理している。
●Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．　おもちゃの流通／輸入業者。Ｔｏｉ Ｃａｒｚのサプライヤの１つ。近年の買収のせいで、Ｔｏｙ Ｃａｒ Ｐａｒｔｓにはレガシーアプリケーションが溢れている。その一部は、１０年以上に渡って使用されている。ＥＲＰ （Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）環境を管理するため、ＳＡＰ Ｒ／３システムを運用している。また、ビジネスパートナーとの関係を、ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００で管理している。
●Ｍｅｈｔａｐ Ｅｎｔｅｒｐｒｉｓｅｓ　おもちゃの車のモーター製造メーカー。Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．が取り引きしている製造メーカーの１つ。１９８０年代にＥＤＩシステムを導入し、それ以来アップグレードしていない、昔気質の製造メーカー。Ｍｅｈｔａｐ Ｅｎｔｅｒｐｒｉｓｅｓとの取り引きを成立させるためには、特定のＥＤＩドキュメントの作成および読み取りに対応できなければならない。
　　１２．４．ｌ   発注
　このサンプルでは、Ｔｏｉ Ｃａｒｚの社員がＭｅｈｔａｐ Ｅｎｔｅｒｐｒｉｓｅｓのエンジンを１０台注文する。そのサプライヤであるＴｏｙ Ｃａｒ Ｐａｒｔｓ， Ｉｎｃ．には、それらの在庫が少しある。図１２−９は、このトランザクションを示している。トランザクションの流れは、表１２−１で説明しよう。　」（第２７１頁第１−２６行）
　
（ケ）「　表１２−１  ＢｉｚＴａｌｋサーバーを使用する２つの会社でのデータの流れを示す、図１２−９の説明
(1)Ｔｏｉ Ｃａｒｚの社員が製品を注文する。注文はＣｏｍｍｅｒｃｅ Ｓｅｒｖｅｒ ２０００によって処理される。
(2)Ｃｏｍｍｅｒｃｅ Ｓｅｒｖｅｒ ２０００がＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００にリクエストを送信する。
(3)ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００がＧｒｅａｔ Ｐｌａｉｎｓ勘定システムにメッセージを送信する。
(4)Ｇｒｅａｔ Ｐｌａｉｎｓ勘定システムがＧｒｅａｔ ＰｌａｉｎｓフォーマットでＰＯを作成し、ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００に送信する。
(5)ＢｉｚＴａｌｋ Ｓｅｖｅｒ ２０００がＧｒｅａｔ ＰｌａｉｎｓのＰＯをＢｉｚＴａｌｋドキュメントに変換する。次に、ＨＴＴＰを使って、Ｔｏｙ Ｃａｒ ＰａｒｔｓのＢｉｚＴａｌｋサーバーにインターネット経由でドキュメントを送信する。
(6)Ｔｏｙ Ｃａｒ ＰａｒｔｓはＳＡＰ Ｒ／３を使用している。ＳＡＰ Ｒ／３はＩＤｏｃフォーマットのドキュメントを要求する。ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００がＢｉｚＴａｌｋメッセージをＩＤｏｃ ＰＯフォーマットに変換し、ＳＡＰシステムに送信する。
(7)ＳＡＰシステムがＩＤｏｃ ＰＯ確認応答（ａｃｋ）でＢｉｚＴａｌｋサーバーに応答する。
(8)Ｔｏｙ Ｃａｒ ＰａｒｔｓのＢｉｚＴａｌｋサーバーがａｃｋをＢｉｚＴａｌｋドキュメントに変換し、ドキュメントをＴｏｉ ＣａｒｚのＢｉｚＴａｌｋサーバーに返送する。
(9)Ｔｏｉ ＣａｒｚのＢｉｚＴａｌｋサーバーが社内システム経由でＣｏｍｍｅｒｃｅ Ｓｅｒｖｅｒ ２０００にａｃｋを送信する。
(10)Ｃｏｍｍｅｒｃｅ Ｓｅｒｖｅｒ ２０００が申請者に対し、サプライヤが注文を受信し、それを処理していることを通知する。　」（第２７２頁表１２−１の記載）
　
（コ）「　１２．４．２   インベントリの確認と製造メーカーへの注文
　Ｔｏｙ Ｃａｒ Ｐａｒｔｓは、注文を処理するのに十分な在庫があることを確認しなければならない。図１２−１０は、Ｔｏｙ Ｃａｒ Ｐａｒｔｓとそのサプライヤとのやり取りを示している。図１２−１０の処理の流れは、表１２−２で説明しよう。　」（第２７３頁第１−４行）
　
（サ）「　表１２−２   図１２−１０の説明
(1)ＳＡＰシステムがリクエストをＩＤｏｃドキュメントとしてＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００に送信し、レガシーインベントリシステムに在庫量を問い合わせるよう要求する。
(2)ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００は、このＩＤｏｃファイルをレガシーインベントリシステムとの通信に使用するフラットファイルに変換する。ＳＡＰシステムがフラットファイルフオーマットを「話さない」こと、インベントリシステムがＩＤｏｃを話さないことに注意してほしい。ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００は、２つのシステムのマッピングを実現する。
(3)レガシーインベントリシステムが、部品の在庫が３台しかないことを報告する。
(4)ここでも、ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００が応答を変換し、ＳＡＰシステムにＩＤｏｃドキュメントを送信する。
(5)ＳＡＰシステムは、リクエストが１０台で在庫が３台であるという知識に基づき、注文を調整して７台のＩＤｏｃ注文を作成し、ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００にこの注文を送信する。
(6)Ｍｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓはＥＤＩ ８５０のＰＯを要求するため、ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００はＳＡＰ ＩＤｏｃリクエストをＥＤＩ ８５０ドキュメントに変換する。次に、Ｍｅｈｔａｐ Ｅｎｔｅｒｐｒｉｓｅｓが接続されているＶＡＮ （Ｖａｌｕｅ Ａｄｄｅｄ Ｎｅｔｗｏｒｋ）を通じて、それを送信する。
(7)Ｍｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓのＥＤＩベースシステムがリクエストを処理し、ＥＤＩ ８５５ Ａｃｋｎｏｗ１ ｅｄｇｅｍｅｎｔドキュメントで応答を返す。Ｐ０を処理するために必要となる作業は、Ｍｅｈｔａｐ Ｅｎｔｅｒｐｒｉｓｅｓのシステムが受け持つ。Ｍｅｈｔａｐ Ｅｎｔｅｒｐｒｉｓｅｓは、１０年以上に渡ってＥＤＩ ８５０ ドキュメントを受信しているため、これは問題にならないだろう。変換はすべてＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００が処理するため、Ｍｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓにはＢｉｚＴａｌｋとのやり取りを知る余地すらない。
(8)ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００がＥＤＩ ８５０ ＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔをＩＤｏｃに変換し、ＳＡＰシステムに送信する。　」（第２７３−２７４頁表１２−２の記載）
　
　上記摘記事項（ア）乃至（サ）の記載によれば，引用例のＢｉｚＴａｌｋサーバーは，「商取引に携わる少なくとも２つのビジネスパートナーのコンピュータ・システム間で，情報を交換する」ものであることが明らかである。
　
　上記摘記事項（ア）の記載によれば，ＢｉｚＴａｌｋサーバーは，コンピュータ言語で開発されるソフトウェアによって実現されるものである。
　
　上記摘記事項（ウ）によれば，ＢｉｚＴａｌｋサーバーは，ドキュメントの種類を識別し，ドキュメントを処理する適切な部署に転送するためのルーティング機能を有しているものである。
　
  上記摘記事項（ウ）によれば，ＢｉｚＴａｌｋサーバーは，ドキュメントの送信元や種類を突き止め，さらにドキュメントに適用しなければならない処理を突き止めて適切なワークフローを開始するワークフロー機能を有しているものである。
　
　上記摘記事項（オ）（カ）の記載を参照すれば，引用例のＢｉｚＴａｌｋサーバーは，ビジネスドキュメントの構造（スキーマ）を変換するものであるから，上記摘記事項（サ）の(5)(6)の記載からみて，Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＢｉｚＴａｌｋＳｅｒｖｅｒ２０００は，Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＳＡＰシステムのＩＤｏｃドキュメントのスキーマをＭｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓのＥＤＩベースシステムのＥＤＩ８５０ドキュメントのスキーマに，前記Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＳＡＰシステムから受信したドキュメントを変換する機能を有していることは明らかである。
　
　また，引用例のＢｉｚＴａｌｋサーバーは，ビジネスドキュメントの構造（スキーマ）を変換するものであるから，ドキュメントの「データ形式」を送信先のコンピュータ・システムにおいて「利用できる形式に変換」していることは明らかである。
　
　上記摘記事項（サ）の(5)(6)の記載によれば，ドキュメントの変換後に，前記Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＳＡＰシステムからＭｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓのＥＤＩベースシステムへ前記変換されたドキュメントを送信していることは明らかである。
　また，Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＢｉｚＴａｌｋＳｅｒｖｅｒ２０００には，レガシーインベントリシステム，ＳＡＰシステムなどが接続され，さらにＶＡＮを介してＭｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓのＥＤＩベースシステムが接続されているものであるから，ドキュメントの送信に際して，「経路指定」をしていることは明らかである。
　
　上記摘記事項（エ）によれば，ＢｉｚＴａｌｋサーバは，ドキュメントを追跡してビジネスパートナーに追跡データベースの情報を提供する機能であって，当該追跡データベースの情報は，ドキュメントが正常に転送されたかどうかを判断することができる情報を含む，ドキュメント追跡機能を有している。
　
　そして，「サーバ」は，実質的に「コンピュータ」であり，ソフトウェアを読み込んで実行することにより，「機能」が実現されることは明らかである。
　
　そうすると，上記摘記事項（ア）乃至（サ）の記載及び図面の記載から，引用例には，次のとおりの発明（以下，「引用例発明」という。）が記載されていると認められる。
　
「　商取引に携わる少なくとも２つのビジネスパートナーのコンピュータ・システム間で，情報を交換するＢｉｚＴａｌｋサーバであって，当該ＢｉｚＴａｌｋサーバの機能はソフトウェアによって実現されるものであり，
　該ＢｉｚＴａｌｋサーバのソフトウェアは，
　ドキュメントの種類を識別し，ドキュメントを処理する適切な部署に転送するためのルーティングソフトウェアと，
　ＢｉｚＴａｌｋドキュメントを受信したら，ドキュメントの送信元や種類を突き止め，ドキュメントに適用しなければならない処理を突き止めて適切なワークフローを開始するためのワークフローソフトウェアと，
　Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＳＡＰシステムのＩＤｏｃドキュメントのスキーマをＭｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓのＥＤＩベースシステムのＥＤＩ８５０ドキュメントのスキーマに，前記Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＳＡＰシステムから受信したドキュメントを変換するソフトウェアであって，前記ドキュメントの変換は，前記Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＳＡＰシステムのＩＤｏｃドキュメントのデータ形式を Ｍｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓのＥＤＩベースシステムにおいて利用できる形式に変換することを含む，ドキュメント変換ソフトウェアと，
　前記ドキュメントを変換後に，前記Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＳＡＰシステムからＭｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓのＥＤＩベースシステムへ前記変換されたドキュメントを経路指定するソフトウェアと，
　前記ドキュメントを追跡してビジネスパートナーに追跡データベースの情報を提供するソフトウェアであって，当該追跡データベースの情報は，ドキュメントが正常に転送されたかどうかを判断することができる情報を含む，ドキュメント追跡ソフトウェアと
を含む，前記ＢｉｚＴａｌｋサーバ。　」
　
（２）周知例１
　また，本願の優先権主張の日前の平成１年１２月１日に頒布された「特開平１−２９７９３６号公報」（以下，「周知例１」という。）には，図面とともに，次の（シ）の事項が記載されている。
　
（シ）「　〔産業上の利用分野〕
　この発明は、様々な種類の複数の通信網に同時に接続され、それらの通信網に収容されている通信手順、即ちプロトコルの異なる各種の計算機あるいは端末装置間の相互接続を可能にするためのプロトコル変換を実行するプロトコル変換方式に関するものである。
　〔従来の技術〕
　第５図及び第６図は、例えば社団法人情報処理学会マルチメディア通信と分散処理研究会で発表されている「プロトコル変換プログラムの変換処理共通化法の検討」中などで述べられている従来のプロトコル変換方式を示す図である。第５図（Ａ）、（Ｂ）は直接変換方式と呼ばれるプロトコル変換方式を示す直接変換態様図、第６図（Ａ）、（Ｂ）は間接変換方式と呼ばれるプロトコル変換方式を示す間接変換態様図である。上記各図において、（１）はプロトコル変換装置、（４ａ）、（４ｂ）はそれぞれ通信回線、（７ａ）、（７ｂ）、（７ｃ）はそれぞれ全階層プロトコル変換機能、（７１ａ）、（７１ｂ）、（７１ｃ）、（７１ｄ）、（７１ｅ）、（７１ｆ）　はそれぞれ全階層プロトコル変換機能中に含まれるプロトコル処理機能、（７３ａ）、（７３ｂ）、（７３ｃ）はそれぞれ全階層プロトコル変換機能中に含まれる変換制御機能である。
　第５図（Ａ）、（Ｂ）に示す直接変換方式において、プロトコル処理機能（７１ａ）、（７１ｂ）はそれぞれ通信回線（４ａ）あるいは通信回線（４ｂ）を介して通信を行っている相手との間のプロトコル全階層の処理を行う。変換制御機能（７３ａ）は、プロトコル処理機能（７１ａ）、（７１ｂ）の間で両プロトコル間の変換を行うべく制御情報・転送データの変換・中継を行う。これらの動作により、全階層プロトコル変換機能（７ａ）全体としては、相互接続を行う対象の２つのプロトコル間の全階層について直接に変換を行う。この直接変換方式では相互接続を行う２種類のプロトコルの組毎に全階層プロトコル変換機能が用意される。
　第６図（Ａ）、（Ｂ）に示す間接変換方式では、プロトコル処理機能（７１ｃ）、（７１ｆ）は、第５図におけるプロトコル処理機能（７１ａ）、（７１ｂ）と同様にそれぞれ通信回線（４ａ）あるいは通信回線（４ｂ）を介して通信を行っている相手との間のプロトコル全階層の処理を行う。プロトコル処理機能（７１ｄ）、（７１ｅ）は、プロトコル変換装置（１）内における標準の中間プロトコル全階層における処理を行う。プロトコル処理機能（７１ｄ）、（７１ｅ）の間には、標準中間プロトコルの規約に従った情報の交換・相互作用がある。変換制御機能（７３ｂ）、（７３ｃ）の動作は第５図における変換制御機能（７３ａ）と同様である。
　これらの動作により、全階層プロトコル変換機能（７ｂ）、（７ｃ）全体としては、それぞれ相互接続を行う対象の２つのプロトコルの片方について、全階層をプロトコル変換装置（１）内における標準の中間プロトコルに変換する機能を有しており、更に、それらが組合わされることにより全体として相互接続対象の２種類のプロトコル間全階層についてのプロトコル変換が標準中間プロトコルを仲介として間接的に実行される。この間接変換方式では、プロトコル変換の対象である各種のプロトコル毎に、それを標準の中間プロトコルに変換する全階層プロトコル変換機能が用意される。
　（発明が解決しようとする課題）
　従来のプロトコル変換方式は以上のように構成されているので、直接変換方式では、処理性能の面では優れているものの相互接続対象である２種類のプロトコルの組毎にプロトコル変換機能を用意しなければならないため、取り扱うプロトコルの種類が増えると用意すべきプロトコル変換機能の数が極めて大きくなってしまうという課題がある。一方、間接変換方式では、用意すべきプロトコル変換機能は少なくて済むものの、仲介となる中間プロトコルに各種のプロトコル機能を充分に伝達する能力が無ければ、全体としてのプロトコル変換が不完全になってしまうという課題がある。　」（第１頁右下欄第２行−第２頁左下欄第１６行）
　
（３）周知例２
　また，本願の優先権主張の日前の平成１１年１２月９日に頒布された「国際公開第９９／６３４６６号」（以下，「周知例２」という。）には，図面とともに，次の（ス）の事項が記載されている。
　
（ス）「　With respect to transformations, in one embodiment, two fundamental transformation types can be supported: 12- CDM based transformations and direct transformations. 12- CDM based transformations are based on I2 TECHNOLOGIES' COMMON DATA MODEL (CDM). The CDM is an abstract schema that is available in both relational and object forms. 
　　FIGURE 15 is a block diagram of one embodiment of an I2-CDM based transformation model. As shown, transformers and accessors can be coupled to transform a application data into a CDM data object 110 and vice versa. For example, a SUPPLY CHAIN PLANNER (SCP) object 112 can be created by an SCP accessor from SCP data 114. SCP object 112 can then be transformed by an SCP-CDM transformer into a CDM object 110. Analogously, an SAP object 116 can be created by an SAP accessor from SAP data 118. SAP object 116 can then be transformed by an SAP-CDM transformer into a CDM object 110. The SAP accessor and transformer, as with other accessors and transformers, can be combined into a standard SAP-CDM adapter 120 that can be used for CDM-based transformations other components. As another example, a BAAN object 122 can be created by a BAAN accessor from BAAN data 124. BAAN object 122 can then be transformed into a CDM object 110 by a BAAN-CDM transformer. These transforms work in the other direction as well. 
　　FIGURE 16 is a diagram of one embodiment of a direct transformation. In direct transformers, objects are converted from one form to another without passing through an intermediate format. For example, as shown in FIGURE 16, SUPPLY CHAIN PLANNER (SCP) data 130 can be accessed by an SCP accessor to create an SCP object 132. SCP object 132 can then be directly transformed to a FACTORY PLANNER (FP) object 134. FP object 134 can then become FP data 136 through an FP accessor. This data flow can operate in the other direction as well. 」（第３２頁第１行−第３３頁第３行）
　
　なお，上記周知例２として公開された国際出願の日本での国内段階への移行のために提出された翻訳を公表した特表２００２−５１７８２８号公報には，図面とともに，上記摘記事項（ス）と対応する以下の事項が記載されているので，下記を上記摘記事項（ス）の仮訳とする。
　
（仮訳）
「 【００７４】
  変換について述べると、一実施形態において、Ｉ２  ＣＤＭを使用した変換と直接変換との２種類の基本変換タイプがサポートされる。Ｉ２  ＣＤＭを使用した変換は、アイ・ツー・テクノロジー社のＣＯＭＭＯＮ  ＤＡＴＡ  ＭＯＤＥＬ（ＣＤＭ）に基づくものである。ＣＤＭは、リレーショナル形にもオブジェクト形にも利用可能な抽象スキーマである。
      【００７５】
  図１５は、Ｉ２−ＣＤＭをベースにした変換モデルの一実施形態のブロック図である。図示されているように、トランスフォーマとアクセッサを結合して、アプリケーション・データをＣＤＭデータ・オブジェクト１１０に変換したり、その逆を行ったりすることができる。例えば、ＳＣＰアクセッサによってＳＣＰデータ１１４からＳＵＰＰＬＹ  ＣＨＡＩＮ  ＰＬＡＮＮＥＲ  （ＳＣＰ）オブジェクト１１２を作成できる。その後、ＳＣＰオブジェクト１１２は、ＳＣＰ−ＣＤＭトランスフォーマによってＣＤＭオブジェクト１１０に変換できる。同様に、ＳＡＰアクセッサによってＳＡＰデータ１１８からＳＡＰオブジェクト１１６を作成できる。その後、ＳＡＰオブジェクト１１６は、ＳＡＰ−ＣＤＭトランスフォーマによってＣＤＭオブジェクト１１０に変換できる。他のアクセッサおよびトランスフォーマでそうであるように、ＳＡＰアクセッサおよびトランスフォーマを組み合わせて、ＣＤＭベースの変換に利用できる標準的なＳＡＰ−ＣＤＭアダプタ１２０にすることができる。別の例として、ＢＡＡＮアクセッサによって、ＢＡＡＮデータ１２４からＢＡＡＮオブジェクト１２２を作成できる。その後、ＢＡＡＮオブジェクト１２２は、ＢＡＡＮ−ＣＤＭトランスフォーマによってＣＤＭオブジェクト１１０に変換できる。これらの変換は別の方向にも働く。
      【００７６】
  図１６は、直接変換の一実施形態の図である。直接トランスフォーマの場合、オブジェクトは、中間形式を通らずに一つの形態から別の形態に変換される。例えば、図１６に示されているように、ＳＵＰＰＬＹ  ＣＨＡＩＮ  ＰＬＡＮＮＥＲ  （ＳＣＰ）アクセッサがＳＣＰデータ１３０にアクセスしてＳＣＰオブジェクト１３２が作成される。ＳＣＰオブジェクト１３２は、ＦＡＣＴＯＲＹ  ＰＬＡＮＮＥＲ  （ＦＰ）オブジェクト１３４に直接に変換される。ＦＰオブジェクト１３４は、その後、ＦＰアクセッサを通じてＦＰデータ１３６となりうる。このデータフローは、別の方向にも作用しうる。」
　
４．対比
　
　引用例発明の「ビジネスパートナー」と本願発明の「自動車取引先」とは「取引先」である点で共通する。
　引用例発明のＢｉｚＴａｌｋサーバがコンピュータ・システムであることは明らかである。
　
　引用例発明のＢｉｚＴａｌｋサーバのソフトウェアが，「コンピュータ・システムにおいて動作するプログラム」であることは自明のことである。
　
　引用例発明の「ドキュメント」「ドキュメントを処理する適切な部署」「送信元」が本願発明の「取引要素」「取引要素が経路指定されるべき受信側」「発信元」に相当する。
　引用例発明の「ルーティングソフトウェア」及び「ワークフローソフトウェア」は，受信したドキュメントを「読み出して」分析していることは自明のことであるから，引用例発明の「ルーティングソフトウェア」及び「ワークフローソフトウェア」と，本願発明の「マッピング・プログラム」とは，「取引要素の発信元」と「取引要素が経路指定されるべき受信側」を決定するプログラムである点で共通している。
　
　引用例発明の「Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＳＡＰシステム」「ＩＤｏｃドキュメントのスキーマ」「Ｍｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓのＥＤＩベースシステム」「ＥＤＩ８５０ドキュメントのスキーマ」が本願発明の「第１の取引先のコンピュータ・システム」「第１の取引先のコンピュータ・システムの専用スキーマ」「第２の取引先のコンピュータ・システム」「第２の取引先のコンピュータ・システムの専用スキーマ」にそれぞれ相当する。
　引用例発明の「ドキュメント変換ソフトウェア」が本願発明の「変換プログラム」に相当する。
　
　引用例発明の「前記ドキュメントを変換後に，前記Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＳＡＰシステムからＭｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓのＥＤＩベースシステムへ前記変換されたドキュメントを経路指定するソフトウェア」と本願発明の「前記取引要素を変換後に、第１の通信プロトコルを使用する前記第１の取引先のコンピュータ・システムから第２の通信プロトコルを使用する前記第２の取引先のコンピュータ・システムへ前記変換された取引要素を前記第２の通信プロトコルで経路指定するルーティング・プログラム」とは，「前記取引要素を変換後に、前記第１の取引先のコンピュータ・システムから前記第２の取引先のコンピュータ・システムへ前記変換された取引要素を経路指定するルーティング・プログラム」である点で共通している。
　
　引用例発明の「追跡データベースの情報」「ドキュメント追跡ソフトウェア」が本願発明の「ステータス情報」「取引管理プログラム」に相当する。
　引用例発明の「ドキュメントが正常に転送されたかどうかを判断することができる情報」は，「ドキュメントの転送状態を示す情報」である点で，本願発明の「前記変換プログラムによる受信、前記変換プログラムによる変換処理又は前記第２の取引先のコンピュータ・システムへの経路指定」の情報と共通している。
　
　そうすると，本願発明と引用例発明とは，
　
「　商取引に携わる少なくとも２つの取引先のコンピュータ・システム間で情報を交換するコンピュータ・システムであって，
　当該コンピュータ・システムにおいて動作するプログラムは，
　取引要素をマッピングするマッピング・プログラムであって，前記取引要素を読出して，前記取引要素の発信元と，前記取引要素が経路指定されるべき受信側とを決定する，前記マッピング・プログラムと，
　第１の取引先のコンピュータ・システムの専用スキーマから第２の取引先のコンピュータ・システムの専用スキーマに，前記第１の取引先のコンピュータ・システムから受信した取引要素を変換する変換プログラムであって，前記取引要素の変換は，前記第１の取引先のコンピュータ・システムの取引要素のデータ形式を，前記第２の取引先のコンピュータ・システムにおいて利用できる形式に変換することを含む，前記変換プログラムと，
　前記取引要素を変換後に，前記第１の取引先のコンピュータ・システムから前記第２の取引先のコンピュータ・システムへ前記変換された取引要素を経路指定するルーティング・プログラムと，
　前記取引要素を追跡して取引先にステータス情報を提供する取引管理プログラムであって，前記ステータス情報は，ドキュメントの転送状態を示す情報を含む，前記取引管理プログラムと
　を含む，前記コンピュータ・システム。　」
　
の点で一致し，次の点で相違する。
　
［相違点１］
　本願発明は自動車取引に係る発明であるのに対して，引用例発明は自動車取引に係る発明でない点。
　
［相違点２］
　本願発明が，中央処理装置，Ｉ／Ｏインタフェース及びメモリーを含み，メモリーが中央処理装置によって実行されるプログラムを記憶するコンピュータ・システムとして記載されているのに対して，引用例発明には，これらのハードウェア構成が明示されていない点。
　
［相違点３］
　本願発明のマッピング・プログラムは，「取引要素が関連する自動車取引」を決定しているのに対して，引用例発明のルーティングソフトウェアとワークフローソフトウェアでは，ドキュメントの種類を識別して「ドキュメントを処理する適切な部署」に転送し，「適切なワークフローを開始」している点。
　
［相違点４］
　本願発明では，取引要素をマッピング後に取引要素を変換しているのに対して，引用例発明では，マッピングと変換の前後関係が明示されていない点。
　
［相違点５］
　本願発明では，第１の取引先のコンピュータ・システムから受信した取引要素を，第１の取引先のコンピュータ・システムの専用スキーマから汎用スキーマにそして該汎用スキーマから第２の取引先のコンピュータ・システムの専用スキーマに変換しているのに対して，引用例発明では，Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＳＡＰシステムのＩＤｏｃドキュメントのスキーマをＭｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓのＥＤＩベースシステムのＥＤＩ８５０ドキュメントのスキーマに直接変換している点。
　
［相違点６］
　本願発明では，取引要素のアプリケーション形式を変換しているのに対して，引用例発明では，「アプリケーション形式」を変換することが明示されていない点。
　
［相違点７］
　本願発明では，変換された取引要素を第２の取引先の第２の通信プロトコルで経路指定しているのに対して，引用例発明では，通信プロトコルに関する明示的な記載が無い点。
　
［相違点８］
　ステータス情報を，本願発明では，第１の取引先のコンピュータ・システムに提供しているのに対して，引用例発明では，ビジネスパートナーに提供している点。
　
［相違点９］
　本願発明のステータス情報は，変換プログラムによる受信，変換プログラムによる変換処理又は第２の取引先のコンピュータ・システムへの経路指定を含んでいるのに対して，引用例発明の「追跡データベースの情報」は，ドキュメントが正常に転送されたかどうかを判断することができる情報を含んでいる点。
　
　
５．当審の判断
　上記各相違点について，以下に検討する。
　
［相違点１］について
　引用例の上記摘記事項（オ）には，複数の産業について記載され，「自動車産業から受け取る発注書」についても記載されていることから，引用例発明を「自動車取引」の分野に適用することに格別の困難性があるものとは認められない。
　
　したがって，相違点１に係る本願発明の構成は，引用例発明に基づいて当業者が容易に想到し得たものである。
　
［相違点２］について
　引用例発明のＢｉｚＴａｌｋサーバは，コンピュータ・システムにおいて動作するソフトウェアであり，また，コンピュータ・システムが中央処理装置，Ｉ／Ｏインタフェース及びメモリーを含むことは自明のことであるから，引用例発明のＢｉｚＴａｌｋサーバのソフトウェアを，中央処理装置，Ｉ／Ｏインタフェース及びメモリーを含むコンピュータ・システムのメモリに記憶させることに格別の困難性があるものとは認められない。
　
　したがって，相違点２に係る本願発明の構成は，引用例発明に基づいて当業者が容易に想到し得たものである。
　
［相違点３］について
　引用例発明では，ドキュメントの種類を識別して，「ドキュメントを処理する適切な部署」や「適切なワークフロー」を決定しているものであるから，ドキュメントが関連する「取引」を決定するように構成することに格別の困難性があるものとは認められない。
　そして，上記「［相違点１］について」で記載したように，引用例発明を「自動車取引」の分野に適用することに格別の困難性があるものとは認められないことから，引用例発明を「自動車取引」の分野に適用した場合に，ドキュメントが関連する「自動車取引」を決定するように構成することに格別の困難性があるものとは認められない。
　
　なお，この点に関して審判請求人は平成２１年６月３日付けの意見書において以下のとおり主張している。
　
「  次に、本願発明では、取引要素をマッピングするマッピング・プログラムを含み、該マッピング・プログラムは、取引要素を読出して、取引要素の発信元と、取引要素が経路指定されるべき受信側とに加えて、取引要素が関連する自動車取引を決定します。
　引用刊行物は、ルーティングについて、「市役所の職員について考えてみよう、市役所では、窓口に書類を提出する。その種類は、駐車違反や交通違反の罰金を支払うためのものかもしれないし、家を増築するためのものかもしれない。あるいは、州に婚姻を承認してもらうための用紙かもしれない。窓口の職員は、書類を適切な部署に転送する。」及び「提出されたドキュメントの種類を識別し、ドキュメントを処理する適切な部署に転送する」（第２０４頁、項「１０．３　ルーティング」）ことを記載する。すなわち、ドキュメントの種類は、駐車違反、交通違反、家の増築、婚姻などのドキュメントの内容です。一方、本願発明では、マッピング・プログラムは、取引要素が関連する自動車取引を決定します。引用刊行物のドキュメントの内容と本願発明の取引要素が関連する自動車取引とは何ら関係なく、引用刊行物は、本願発明のマッピングにおいて取引要素が関連する自動車取引を決定することを記載も示唆もしていません。」（第２頁下から４行−第３頁第１０行）
　
　しかしながら，上記で検討したとおり，引用例発明を「自動車取引」の分野に適用した場合に，ドキュメントが関連する「自動車取引」を決定するように構成することに格別の困難性があるものとは認められないことから，審判請求人の上記主張は採用することができない。
　
　したがって，相違点３に係る本願発明の構成は，引用例発明に基づいて当業者が容易に想到し得たものである。
　
［相違点４］について
　引用例発明の「ルーティングソフトウェア」や「ワークフローソフトウェア」は，ドキュメントを受信した際に処理を実行するものであるから，当該処理を実行した「後に」ドキュメントの変換を実行することは自明のことである。
　
　したがって，相違点４に係る本願発明の構成は，引用例発明に基づいて当業者が容易に想到し得たものである。
　
［相違点５］について
　例えば上記摘記事項（シ）及び（ス）に記載されているように，データ形式を変換する方式として，「直接変換方式」及び「中間形式を介した２段階変換方式」はいずれも周知技術であるものと認められる。
　そして，２段階変換方式は，変換するデータ形式の種類が増えても直接変換方式に比べて用意すべき変換機能の種類が少なくて済むという有利な点があること，また，引用例発明のＢｉｚＴａｌｋサーバが複数のデータ形式のドキュメントを変換する必要があること，を考慮すれば，引用例発明のＢｉｚＴａｌｋサーバにおけるドキュメント変換に上記２段階変換方式を採用することに格別の困難性があるものとは認められない。
　
　したがって，相違点５に係る本願発明の構成は，引用例発明及び周知技術に基づいて当業者が容易に想到し得たものである。
　
［相違点６］について
　上記摘記事項（ク）の記載によれば，ＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００がデータを送受信する各システムがそれぞれ異なるアプリケーションを有していることは自明のことであり，これらのアプリケーションと通信を行う際に，「アプリケーション形式」を，送信先のシステムにおいて「利用できる形式に変換する」ように構成することは当業者であれば容易に想到し得うることである。
　
　したがって，相違点６に係る本願発明の構成は，引用例発明に基づいて当業者が容易に想到し得たものである。
　
［相違点７］について
　上記摘記事項（イ）には，ＢｉｚＴａｌｋサーバがサポートすべき複数の通信プロトコルについて記載されている。
　また，上記摘記事項（ク）乃至（サ）の記載によれば，Ｔｏｙ Ｃａｒ Ｐａｒｔｓ，Ｉｎｃ．のＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００は，インターネットを介してＴｏｉ Ｃａｒｚ Ｃｏｒｐ．のＢｉｚＴａｌｋ Ｓｅｒｖｅｒ ２０００と通信するとともに，Ｍｅｈｔａｐ ＥｎｔｅｒｐｒｉｓｅｓのＥＤＩシステムとも通信しており，それぞれのネットワークに応じた通信プロトコルで通信しているものと認められる。
　してみれば，引用例発明において，通信相手が使用する通信プロトコルでドキュメントを送信するように経路指定することに格別の困難性があるものとは認められない。
　
　なお，この点に関して審判請求人は平成２１年６月３日付けの意見書において以下のとおり主張している。
　
「　補正後の請求項１〜９に係る発明（以下、本願発明）のコンピュータ・システムはルーティング・プログラムを含み、該ルーティング・プログラムは、第１の通信プロトコルを使用する第１の取引先のコンピュータ・システムから第２の通信プロトコルを使用する第２の取引先のコンピュータ・システムへ変換された取引要素を第２の通信プロトコルで経路指定します。すなわち、相手先の通信プロトコルで経路指定します。よって、各取引先は取引要素を自身が理解できるプロトコルで受信できます（第００２１段落）。
　引用刊行物では、第２７２頁の図１２−９に示されるように２つの企業（Toi Carz Corp.及びToy Car Parts, Inc.）それぞれが、BizTalkServer2000を有し、その間でデータのやりとりが行われます。すなわち、Toi CarzのBizTalkServer2000がHTTPを使ってToy Car PartsのBizTalk Server2000にインターネット経由でドキュメントを送付します（第２７２頁、表１２−１、番号５）。一方、本願発明では、上記に述べたように、相手先の通信プロトコルで経路指定されます。引用刊行物は、本願発明の上記構成を記載も示唆もしていません。」（第２頁下から１７行−同頁下から５行）
　
　しかしながら，上記で検討したとおり，通信相手が使用する通信プロトコルでドキュメントを送信するように経路指定することに格別の困難性があるものとは認められないことから，審判請求人の上記主張は採用することができない。
　
　したがって，相違点７に係る本願発明の構成は，引用例発明に基づいて当業者が容易に想到し得たものである。
　
［相違点８］について
　引用例のＢｉｚＴａｌｋサーバは，ビジネスパートナーのコンピュータシステムとネットワークで接続されており，また，ドキュメント送信側のオペレータからステータスを問合わせることはごく普通に考えられることであるから，「ドキュメント送信側のビジネスパートナーのコンピュータシステム」，すなわち「第１の取引先のコンピュータ・システム」に追跡データベースの情報（ステータス情報）を提供するように構成することに格別の困難性があるものとは認められない。
　
　したがって，相違点８に係る本願発明の構成は，引用例発明に基づいて当業者が容易に想到し得たものである。
　
［相違点９］について
　「ドキュメントが正常に転送されたかどうかを判断することができる」ようにするための具体的な情報としてどのような情報を用いるかは，当業者が必要に応じて適宜選択しうる設計的事項であるものと認められることから，引用例発明において，ドキュメントが「受信」「変換処理」「経路指定」のいずれの状態であるかの情報を用いて「ドキュメントが正常に転送されたかどうかを判断することができる」ようにすることは。当業者であれば容易に想到し得たことと認められる。
　
　したがって，相違点９に係る本願発明の構成は，引用例発明に基づいて当業者が容易に想到し得たものである。
　
　以上より，本願発明の構成は，引用例発明及び周知技術に基づき，当業者が容易に想到し得たものである。
　
　そして，本願発明の作用効果も，引用例及び周知技術から当業者が予測できる範囲のものである。
　
　ゆえに，本願発明は，引用例発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
６．むすび 
　したがって，本願発明は，引用例発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 
　
　よって，結論のとおり審決する。