【事件の表示】
　平成１１年特許願第２４３７５７号「データ受け渡し方法、仲介システム、記録媒体」拒絶査定不服審判事件〔平成１３年　３月１６日出願公開、特開２００１−　６７２３６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成１１年８月３０日の出願であって、平成１３年１１月１２日付け手続補正書で補正された特許請求の範囲の請求項１（実質的には、補正前の請求項４と同じもの）には次のとおりに記載されている。
　
「第１機能実現体及び第２機能実現体が稼働する空間に、引数を解読する機能を具備する仲介システムを介在させ、
　第１機能実現体側で、少なくとも受け渡し対象となるデータの送信要求、第２機能実現体の宛先、及びそのデータの格納領域を引数で表現し、この引数を前記仲介システムへ送信するとともに、
　前記引数を受信した仲介システムが当該引数の内容に基づいて第２機能実現体と前記データの格納領域とを特定し、特定した第２機能実現体宛に前記格納領域内のデータを引き渡すデータ受け渡し方法であって、
　前記第１機能実現体及び前記第２機能実現体は所定のＯＳ空間で稼働するアプリケーションプログラムであり、前記仲介システムは、前記ＯＳ空間で各アプリケーションプログラムの稼働空間とは別の空間で稼働するプログラムであることを特徴とする、データ受け渡し方法。」
　
　ここで、本願請求項１に記載のものにおいて、「ＯＳ空間」及び「アプリケーションプログラム」とは、技術的にどのような意味であるのかについて検討する。
　本願明細書には、次の事項が記載されている。
（ア）この明細書において、「空間」という場合は、プログラムが動作する領域をいうものとする。（段落【０００１】）
（イ）メインフレームを使用したシステムでは、一つのＯＳ空間内で様々なアプリケーションが稼動し、所要の機能を実現している。（段落【０００２】）
（ウ）メインフレームにおいてＯＳが稼働する空間に仲介システムを設け、このＯＳ内のあるアプリケーションが仲介システムを介して他のアプリケーションにデータを受け渡す場合の例を挙げる。（段落【００１２】
　
　上記の事項、特に上記（ウ）のうち「ＯＳが稼働する空間」及び「ＯＳ内のあるアプリケーション」からすると、「仲介システム」及び「アプリケーション」は、「ＯＳ」の一部として構成されているとも解釈し得るが、技術常識からすると、アプリケーションプログラムは、ＯＳの管理下にあり、ＯＳが管理するメモリ領域内で稼働し、ＯＳを構成するプログラムとは別のものである。よって、請求項１に記載された事項において、「ＯＳ空間」とは、「ＯＳが管理するメモリ領域」であり、「アプリケーションプログラム」は、当該「ＯＳが管理するメモリ領域」で稼働するアプリケーションプログラムであり、「仲介システム」は、当該「ＯＳが管理するメモリ領域」であって、各アプリケーションプログラムが稼働するメモリ領域とは別のメモリ領域で稼働するプログラムであると解釈することが合理的である。
　よって、本願請求項１に係る発明は、次のとおりのものと認定される（以下「本願発明」という。）。
　
「第１機能実現体及び第２機能実現体が稼働するメモリ領域に、引数を解読する機能を具備する仲介システムを介在させ、
　第１機能実現体側で、少なくとも受け渡し対象となるデータの送信要求、第２機能実現体の宛先、及びそのデータの格納領域を引数で表現し、この引数を前記仲介システムへ送信するとともに、
　前記引数を受信した仲介システムが当該引数の内容に基づいて第２機能実現体と前記データの格納領域とを特定し、特定した第２機能実現体宛に前記格納領域内のデータを引き渡すデータ受け渡し方法であって、
　前記第１機能実現体及び前記第２機能実現体は所定のＯＳが管理するメモリ領域で稼働するアプリケーションプログラムであり、前記仲介システムは、前記ＯＳが管理するメモリ領域であって、各アプリケーションプログラムが稼働するメモリ領域とは別のメモリ領域で稼働するプログラムであることを特徴とする、データ受け渡し方法。」
　
２．引用文献
　これに対して、原査定の拒絶の理由に引用された、本願の出願の日前である昭和５９年８月２２日に頒布された刊行物である特開昭５９−１４６３４７号公報（以下「引用文献」という。）には、次の事項が記載されている。
　
（ア）「例えばプロセスＡがプロセスＢにパケットを送信する場合にはプロセスＡはデータ・アドレス、データ長および宛先プロセスを指定してメッセージ送信マクロを発行し、プロセスＡが他プロセスからのパケットを受信する場合にはプロセスＡはデータ・アドレスを指定してメッセージ受信マクロを発行する。メッセージ送信マクロを機械語に翻訳すると、所定のＳＶＣ番号を持つＳＶＣ命令となる。このＳＶＣ命令が発行されると、ＳＶＣ割込みが生じ、ＳＶＣ割込ハンドラによってＳＶＣ番号が解析され、メッセージ送信処理ルーチンは、送り元プロセスによって指定されたデータ・アドレスおよびデータ長を基にして送り元プロセスのデータ域からデータ（パケットと同義）を取出し、これを宛先プロセスに送るための処理を行う。送信パケットはパケット格納域に格納され、このパケット格納域は宛先プロセスのプロセス制御ブロックにリンクされる。」（第１頁右下欄第１５行−第２頁左上欄第１３行）
　
（イ）「メッセージ受信マクロを機械語に翻訳すると、他の所定のＳＶＣ番号を持つＳＶＣ命令となる。このＳＶＣ命令が発行されると、ＳＶＣ割込みが生じ、ＳＶＣ割込ハンドラによってＳＶＣ番号が解析され、メッセージ受信処理ルーチンが起動される。メッセージ受信処理ルーチンは、メッセージ受信マクロ発行元プロセスのプロセス制御ブロックにパケットがキューイングされているか否かを調べ、キューイングされている場合にはそのパケットをメッセージ受信マクロ発行元プロセスによって指定されたデータ・アドレスに書込み」（第２頁左上欄第１３行−右上蘭第４行）
　
（ウ）「（略）…プロセス間通信方式において、プロセスＡが宛先プロセスおよびパケットを指定してパケットを送信するための所定の命令を発行した時プロセスＡによって指定された送信パケットをプロセスＡによって指定された他のプロセスに送信するための処理を行うと共に…（中略）…当該パケットをプロセスＡに渡す処理を行うメッセージ送信命令処理手段を設けたことを特徴とするプロセス間通信方式。」（特許請求の範囲）
　
（エ）「送信プロセスは、例えばデータの加工などの処理を行った後、データ・アドレス、データ長および宛先プロセスを所定のレジスタにセットしてメッセージ送信マクロを発行する。」（第３頁右上蘭第１−４行）
　
　上記（ア）からすると、「メッセージ送信処理ルーチン」は、送り元プロセスによって指定されたデータ・アドレスおよび宛先プロセスを解読する機能を有していることは自明である。
　上記（ア）の「ＳＶＣ番号を持つＳＶＣ命令」からすると、「ＳＶＣ番号」は、ＳＶＣ命令の引数として割込ハンドラに送信されていることは自明である。また、上記（エ）からすると、「データ・アドレス」及び「宛先プロセス」は、所定のレジスタを介して宛先のプロセスに送信されている。
　上記（ウ）において、「メッセージ送信命令処理手段」は、メッセージの送り元であるプロセスＡと、宛先であるプロセスＢとの間に介在し、メッセージを送信する機能と受信する機能を併せ持った手段であるから、上記（ア）及び（イ）からして、「ＳＶＣ割込ハンドラ」、「メッセージ送信処理ルーチン」及び「メッセージ受信処理ルーチン」から構成されたものである。また、技術常識からして、「ハンドラ」及び「ルーチン」は、プログラムで構成されているから、結果として、「メッセージ送信命令処理手段」もプログラムであるといえる。
　また、プロセスＡ及びプロセスＢは、独立して動作している以上、別のメモリ領域で稼働するプログラムであり、かつ、「メッセージ送信命令処理手段」は、プロセスＡとプロセスＢとの間に介在したものであるから、各プロセスとは独立したメモリ領域で稼働するプログラムであることは自明である。
　
　よって、上記（ア）乃至（エ）からすると、引用文献１には次の発明（以下「引用発明」という。）が記載されている。
　
「プロセスＡ及びプロセスＢが稼働するメモリ領域に、ＳＶＣ番号、データ・アドレスおよび宛先プロセスを解読する機能を有するメッセージ送信命令処理手段を介在させ、
　プロセスＡ側で、少なくとも受け渡し対象となるデータの宛先プロセスおよびデータ域を所定のレジスタにセットし、並びに、ＳＶＣ番号をＳＶＣ命令の引数で表現して、宛先プロセスおよびデータ域並びにＳＶＣ番号を前記メッセージ送信命令処理手段へ送信すると共に、
　前記ＳＶＣ番号及び宛先プロセス並びにデータ・アドレスを受信したメッセージ送信命令処理手段が受信した宛先プロセス及びデータ・アドレスに基づいてプロセスＢと前記データを格納したデータ・アドレスを特定し、当該データ・アドレスに格納されたデータをパケット格納域に書込み、当該パケット格納域をプロセスＢに対応するプロセス制御ブロックにリンクすることにより、特定したプロセスＢ宛に前記データ域内のデータを送信するプロセス間通信方式であって、
　前記プロセスＡ及び前記プロセスＢは所定のメモリ領域で稼働するプログラムであり、前記メッセージ送信命令処理手段は、各プロセスが稼働するメモリ領域とは別のメモリ領域で稼働するプログラムであることを特徴とする、プロセス間通信方式。」
　
３．本願発明と引用文献との対比
　本願発明と引用発明とを対比すると、本願発明の「第１機能実現体」、「第２機能実現体」、「仲介システム」、「データの送信要求」、「第２機能実現体の宛先」、「データの格納領域」、及び、「データ受け渡し方法」は、引用発明の「プロセスＡ」、「プロセスＢ」、「メッセージ送信命令処理手段」、「ＳＶＣ番号」、「宛先プロセス」、「データ・アドレス」、及び、「プロセス間通信方式」に対応し、両者は以下の点で相違する。
　
［相違点１］
　本願発明は、データの送信要求、第２機能実現体の宛先及びデータの格納領域を引数で表現して仲介システムへ送信しているのに対し、引用発明では、ＳＶＣ番号は引数としてメッセージ送信命令処理手段へ送信されているが、宛先プロセス及びデータ・アドレスは、所定のレジスタを介して送信されている点。
［相違点２］
　本願発明は、第１機能実現体、第２機能実現体及び仲介システムのいずれもＯＳが管理するメモリ領域で稼働するのに対し、引用発明では、ＯＳが管理するメモリ領域について言及していない点。
　
４．当審の判断
　上記相違点について、検討する。
　以下、上記相違点について検討する。
［相違点１について］
　複数のデータを一つの命令又はメッセージに含め、まとめて送信することは周知技術であるから、引用発明において、ＳＶＣ命令を、ＳＶＣ番号のみならず、宛先プロセス及びデータ・アドレスをもまとめて送信するような命令に変更することに格別な困難性はない。
［相違点２について］
　アプリケーション及びプログラムを、ＯＳが管理するメモリ領域で稼働させ、プロセス管理ブロック等により管理することは周知技術（例えば、特開平６―１６１８６１号公報の段落【０００２】、段落【００２６】−【００２８】、特開平９−６９０１７号公報の段落【００１４】−【００１７】及び図２を参照のこと。）であり、引用発明において、各プロセスがプロセス制御ブロック（ＰＣＢ）により管理されていることからして、各プロセス及びプログラムが、ＯＳが管理するメモリ領域で稼働していることは当業者ならば容易に推測し得た範囲内のものである。よって、引用発明において、各プロセス及びメッセージ送信命令処理手段が、ＯＳが管理するメモリ領域で稼働するという事項を付加することは単なる設計変更にすぎない。
　
５．請求人の主張について
　請求人は、平成１３年１１月１２日付けの手続補正により補正した請求の理由において、「この補正によって、本願各請求項に記載された発明において、「仲介システム」は「ＯＳ」ではなく、ＯＳ空間で稼働するアプリケーションプログラムであることを明確にしました。」と主張しているが、本願の請求項１乃至６のいずれにも、「前記仲介システムは、前記ＯＳ空間で各アプリケーションプログラムの稼働空間とは別の空間で稼働するプログラムである」としか記載がなく、この記載からは、「仲介システム」が「アプリケーションプログラム」であると限定的に解釈することはできないから、当該請求人の主張は、請求項の記載に基づいたものではないので採用できない。
　また、請求人は、上記請求の理由において、「従って、本願発明においては、ＯＳに直接依存していない」とも主張しているが、ＯＳ空間内の別の空間でそれぞれ稼働している各アプリケーションと仲介システムとの間のインタフェース（例えば、空間Ａで稼働するアプリケーションと空間Ｘで稼働する仲介システムとの間のデータ受け渡し）を、ＯＳの機能を用いることなくどのように実現しているのかについて、発明の詳細な説明及び各請求項のいずれにも何ら記載されていない。また、ＯＳの管理下で稼働する複数のアプリケーションプログラムの間の通信、スケジューリングなどをＯＳが制御することは技術常識であり、請求人が主張するようなＯＳに依存しない手法が本願の出願時において自明であったともいえない。よって、当該請求人の主張も採用できない。
　
６．むすび
　したがって、本願発明は、引用発明に基づいて当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。