ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G06F 審判 査定不服 5項独立特許用件 特許、登録しない。 G06F |
|---|---|
| 管理番号 | 1125717 |
| 審判番号 | 不服2003-25024 |
| 総通号数 | 72 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 1996-05-31 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2003-12-25 |
| 確定日 | 2005-11-04 |
| 事件の表示 | 平成 6年特許願第270842号「トランザクション処理方法、記録媒体および分散処理システム」拒絶査定不服審判事件〔平成 8年 5月31日出願公開、特開平 8-137808〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
1.手続の経緯 本願は、平成6年11月4日の出願であって、平成15年4月7日付で手続補正がなされ、同年11月17日付で拒絶査定がなされ、これに対し、同年12月25日に拒絶査定に対する審判請求がなされるとともに、平成16年1月26日付で手続補正がなされたものである。 2.平成16年1月26日付の手続補正についての補正却下の決定 [補正却下の決定の結論] 平成16年1月26日付の手続補正を却下する。 [理由] (1)補正後の本願発明 平成16年1月26日付の手続補正(以下、「本件補正」という。)により、特許請求の範囲は次のとおり補正された。 「 【請求項1】 複数の計算機をネットワーク接続し、クライアント計算機で稼動するプログラムからサーバ計算機で稼動するプログラムを呼び出して処理を実行するクライアント・サーバ型の分散処理システムにおけるトランザクション処理方法であって、 前記クライアント計算機は、該クライアント計算機上のプログラムからの処理要求をサーバ計算機に転送し、 前記サーバ計算機は、該サーバ計算機で稼動する受け付けプロセスが前記クライアント計算機からの最初の処理要求を受け付けてスケジュールキューに登録して、クライアント計算機からの処理要求を代行的に処理する代行プロセスを起動し、該起動された代行プロセスは、前記スケジュールキューから処理要求を取り出して、前記クライアント計算機からの処理要求を代行処理して、処理結果を前記クライアント計算機に通知し、 前記クライアント計算機は、同じトランザクションの2回目以降の処理要求については、前記サーバ計算機の前記代行プロセスへ該処理要求を送信し、 前記サーバ計算機の前記代行プロセスは、前記クライアント計算機からの2回目以降の処理要求を、前記受け付けプロセスを介することなく、直接、受信し、代行処理して、処理結果を前記クライアント計算機に通知し、前記代行処理した処理要求が前記クライアント計算機からの同じトランザクションの最後の処理要求であれば、前記スケジュールキューから新たな処理要求の取り出しを行う、 ことを特徴とするトランザクション処理方法。」 本件補正は、請求項1と請求項3を削除し、請求項2を請求項1に繰り上げるとともに、請求項2に係る発明を特定するために必要な事項である「分散処理システム」、「第1の計算機」、「第2の計算機」、「第1のプロセス」及び「第2のプロセス」を、それぞれ「クライアント・サーバ型の分散処理システム」、「クライアント計算機」、「サーバ計算機」、「受け付けプロセス」及び「代行プロセス」に限定し、さらに、「第2のプロセス」(本件補正後における「代行プロセス」)がスケジュールキューから処理要求を取り出す動作について「前記代行処理した処理要求が前記クライアント計算機からの同じトランザクションの最後の処理要求であれば、前記スケジュールキューから新たな処理要求の取り出しを行う」との限定を付加するものである。 これらの限定により解決しようとする課題は、本件補正前の請求項1または請求項2に係る発明が解決しようとする課題である、「第2の計算機」(本件補正後における「サーバ計算機」)の「第2のプロセス」(本件補正後における「代行プロセス」)に処理要求群(最初の処理要求、2回目の処理要求、・・・、最後の処理要求からなる「第1の計算機」(本件補正後における「クライアント計算機」)から「第2の計算機」(本件補正後における「サーバ計算機」)への同じトランザクション内の一連の処理要求の集合のこと。)単位に割り当てを行う課題、及び、「第2の計算機」(本件補正後における「サーバ計算機」)の「第1のプロセス」(本件補正後における「受け付けプロセス」)に処理が集中しないようにする課題と同一のものである。よって、平成6年12月14日法律第116号施行前の特許法第17条の2第3項第2号の特許請求の範囲の減縮を目的とするものに該当する。 そこで、本件補正後の請求項1に係る発明が特許出願の際独立して特許を受けることができるものであるか(平成6年12月14日法律第116号施行前の特許法第17条の2第4項で読み替えて準用する同法第126条第3項の規定に適合するのか)について以下に検討する。 (2)判断 本件補正後の請求項1には、「該サーバ計算機で稼動する受け付けプロセスが前記クライアント計算機からの最初の処理要求を受け付けてスケジュールキューに登録して、クライアント計算機からの処理要求を代行的に処理する代行プロセスを起動し、」と記載されていることから、本件補正後の請求項1に係る発明は、受け付けプロセスがクライアント計算機からの最初の処理要求を受け付けてスケジュールキューに当該最初の処理要求を登録するたびに、代行プロセスを起動するものである。 ところで、スケジュールキューから処理要求を取り出して代行処理を行う代行プロセスについて、本件補正後の請求項1には「該起動された代行プロセスは、前記スケジュールキューから処理要求を取り出して、前記クライアント計算機からの処理要求を代行処理し」と記載される一方、本件補正後の請求項1には「前記代行処理した処理要求が前記クライアント計算機からの同じトランザクションの最後の処理要求であれば、前記スケジュールキューから新たな処理要求の取り出しを行う」とも記載されている。これらの記載によれば、本件補正後の請求項1に係る発明では、スケジュールキューに格納された1つの最初の処理要求を取り出す主体となる代行プロセスとして、当該最初の処理要求をスケジュールキューに格納する際に受け付けプロセスが起動した代行プロセスと、当該最初の処理要求とは直接の関係はない最後の処理要求の代行処理を済ませた代行プロセスという2種類の代行プロセスが存在することになる。このように、本件補正後の請求項1の記載は、受け付けプロセスの動作、代行プロセスの起動と動作、及び、処理要求の代行プロセスへの割当について明確なものとはいえない。 したがって、本件補正後の請求項1に係る発明は、平成6年12月14日法律第116号施行前の特許法第36条第5項第2号及び第6項に規定する要件を満たさないので、特許出願の際独立して特許を受けることができないものである。 (3)むすび 以上のとおり、本件補正は、平成6年12月14日法律第116号施行前の特許法第17条の2第4項で読み替えて準用する同法第126条第3項の規定に違反するものであり、同法第159条第1項で読み替えて準用する同法第53条第1項の規定により却下されるべきものである。 3.本願発明 平成16年1月26日付の手続補正は上記のとおり却下されたので、本願の請求項1に係る発明(以下、「本願発明」という。)は、平成15年4月7日付手続補正書の特許請求の範囲の請求項1に記載された事項により特定される、以下のとおりのものである。 「複数の計算機を有し、第1の計算機からの処理要求を第2の計算機で処理する分散処理システムにおけるトランザクション処理方法であって、 前記第2の計算機は、前記第1の計算機からのトランザクションの処理要求を受信して第1のプロセスを動作し、前記第1のプロセスが前記処理要求を処理する第2のプロセスを起動し、前記第2のプロセスが前記処理要求を処理して処理結果を前記第1の計算機へ通知し、 前記第1の計算機は、同じトランザクションの2回目以降の処理要求については、前記第2の計算機の前記第2のプロセスへ処理要求を送信し、前記第2のプロセスが前記処理要求を処理して処理結果を前記第1の計算機へ通知することを特徴とするトランザクション処理方法。」 4.引用例 これに対し、原査定の拒絶の理由に引用された特開平6-243077号公報(平成6年9月2日公開。以下、引用例1という。)には、以下の事項が図面とともに記載されている。 (ア)「【産業上の利用分野】本発明は、クライアント・サーバ型の分散トランザクション処理方式に関し、特に複数の処理プロセスを有するサーバシステムの処理プロセスの割り当て方式に関するものである。」(公報第【0001】段落) (イ)「【課題を解決するための手段】上記目的を達成するために、本発明は、1つのグローバルトランザクション内で複数の処理プロセスを有するサーバシステムが1回目に呼び出されていずれかの処理プロセスを割り当てた時点で当該グローバルトランザクションと当該処理プロセスとを対応付ける手段を設け、同一グローバルトランザクション内での当該サーバシステムの2回目以降の呼出し時には1回目の呼出し時に割り当てた処理プロセスを再度割り当てるようにしたものである。」(公報第【0008】段落) (ウ)「図において、複数のクライアントコンピュータ10a〜10dと、サーバコンピュータ11とは、ネットワーク12で接続されており、クライアントコンピュータ10a〜10dにはクライアントシステム制御プログラム13とクライアントプログラム14とが、またサーバコンピュータ11にはサーバシステム制御プログラム15と複数のサービス処理プロセス16a〜16dがそれぞれ設けられている。」(公報第【0013】段落) (エ)「図2は分散トランザクション処理の手順を示すフローチャートであり、クライアントプログラム14からのサービス要求を受けたクライアントシステム制御プログラム13は要求されたサービス名称からサーバシステム11を決定する(ステップ21,21)。 その後、当該サーバシステム11へのサービス要求が当該グローバルトランザクション内で初めてか否かを判定し(ステップ22)、初めてでなければ、初回要求時に当該サーバシステム11のサーバシステム制御プログラム15から通知されたサービス処理プロセスのID(例えば16aのID)を送信メッセージ中の特定のフィールドにセットする(ステップ23)。 初めての要求ならば、当該フィールドはヌル値のままとする。 クライアントシステム制御プログラム13は送信メッセージを組み立てた後、それを該当するサーバシステム制御プログラム15に送信する(ステップ24)。」(公報第【0018】段落〜第【0021】段落) (オ)「サーバシステム制御プログラム15は、クライアントシステム制御プログラム13からのメッセージを受信すると(ステップ28)、受信メッセージ中に処理プロセスIDがセット済か否かを判定する(ステップ29)。 もしセット済ならば、それは同一グローバルトランザクション内での2回目以降のサービス要求であり、次のサービス処理要求か同期点処理要求に対し待機中の当該処理プロセスIDを持つサービス処理プロセス16aを選択する(ステップ30)。 もしセット済でなければ、それはグローバルトランザクション内での当該サーバシステム11に対する最初のサービス処理要求であり、任意の空きサービス処理プロセス、例えば16bを選択する(ステップ31)。 サーバシステム制御プログラム15は選択したサービス処理プロセス16aをスケジュールする(ステップ32)。」(公報第【0022】段落〜第【0025】段落) (カ)「スケジュールされたサービス処理プロセス16aはサービス実行後(ステップ35)、結果をサーバシステム制御プログラム15に送信し(ステップ36)、同一グローバルトランザクション内からの次のサービス処理要求または同期点処理要求を待つ(ステップ34,37)。」(公報第【0026】段落) (キ)「サービス実行結果を受けたサーバシステム制御プログラム15は、サービスを実行したサービス処理プロセス16aの処理プロセスIDを送信メッセージ中の特定のフィールドにセットし(ステップ38)、サービス実行結果メッセージをクライアントシステム制御プログラム13に返却する(ステップ39)。」(公報第【0027】段落) (ク)「クライアントシステム制御プログラム13は、同一グローバルトランザクション内からの同一サーバシステムへの次のサービス要求に備え、サーバシステム制御プログラム15が結果送信メッセージ中にセットした処理プロセスIDを記憶し、サービス実行結果をクライアントプログラム14に返す(ステップ26,27)。」(公報第【0028】段落) (ケ)「図3はクライアントシステム制御プログラム13とサーバシステム制御プログラム15の間でやり取りされる送受信メッセージ40の一例を示すもので、サービス名称フィールド41、処理プロセスIDフィールド42、デ-タフィールド43が設けられ、サービスを実行すべき、または実行したサービス処理プロセス16の処理プロセスIDがメッセージ40中の特定フィールド42にセットされる。」(公報第【0029】段落) 以上の記載において、クライアントコンピュータ10a〜10dからサーバコンピュータ11への同一グローバルトランザクション内における複数の要求について、「サービス処理要求」、「サービス要求」及び「呼出し」という用語を用いられているが、これらは同種のものを示すものであることは明らかである。 これらの(ア)〜(ケ)の記載及び考察によれば、引用例1には、次の発明が記載されているものと認められる(以下「引用例1発明」という。)。 複数のコンピュータを有し、クライアントコンピュータ10a〜10dからのサービス処理要求をサーバコンピュータ11で処理する分散処理システムにおけるグローバルトランザクション処理方法であって、 前記サーバコンピュータ11は、前記クライアントコンピュータ10a〜10dからのグローバルトランザクション内のサービス処理要求を受信してサーバシステム制御プログラム15を動作し、前記サーバシステム制御プログラム15が、前記サービス処理要求がグローバルトランザクション内の最初のサービス処理要求である場合には、当該サービス処理要求を処理するサービス処理プロセス16a〜16dを選択してスケジュールし、前記サービス処理プロセス16a〜16dが前記サービス処理要求を処理して、処理結果を、前記サーバシステム制御プログラム15を介して、前記クライアントコンピュータ10a〜10dへ通知し、 前記クライアントコンピュータ10a〜10dは、同じグローバルトランザクション内の2回目以降のサービス処理要求については、前記サーバコンピュータ11の前記サービス処理プロセス16a〜16dを、サービス処理要求に伴う送受信メッセージ40内の処理プロセスIDフィールド42にて指定して、前記サーバシステム制御プログラム15を介して、サービス処理要求を送信し、前記サービス処理プロセス16a〜16dが前記サービス処理要求を処理して、処理結果を、前記サーバシステム制御プログラム15を介して、前記クライアントコンピュータ10a〜10dへ通知することを特徴とするグローバルトランザクション処理方法 同じく、原査定の拒絶の理由に引用されたW. Richard Stevens,"UNIX Network Programming",Prentice-Hall, Inc.,1991年,p.692-719(以下、引用例2という。)には、特に第713頁-第715頁に、以下の事項が記載されている。 (コ)引用例2の第714頁の図18.6(Figure 18.6)に、ローカルシステム(local system)とリモートシステム(remote system)があり、ローカルシステム内にrdate(client)というプロセスが図示され、リモートシステム内にxnscourierd(child)というプロセスとdateserver(server)というプロセスが図示され、rdate(client)プロセスからxnscourierd(child)プロセスへの情報伝達やxnscourierd(child)プロセスからdateserver(server)プロセスへの情報伝達が行われるのみならず、rdate(client)プロセスとdateserver(server)プロセスの間の双方向の情報伝達が行われることが図示されている。 (サ)「3. When the client calls the BinDate function, the client stub writes the desired program number, version number and procedure number to the connection.」(引用例2の第714頁第3行目-第4行目(訳)クライアント(client)はBinDate機能を呼び出し、クライアントスタブはプログラム番号、バージョン番号、プロシジャー番号を通信回線に出力する。) (シ)「4.(略)The child then does an exec of the appropriate sever program. (略)」(引用例2の第714頁第5行目-第12行目(訳)チャイルド(child)は適切なサーバプログラム(server program)を実行する。) (ス)「5. Our datesearver program is started(略). It then calls our BinDate function. When our function returns, the server stub converts the results into the Courier standard format and sends them back to the client.」(引用例2の第714頁第13行目-第17行目(訳)デートサーバ(datesearver)プログラムの処理が開始される。(略)BinDateが実行される。BinDateの実行が済んだ時、サーバスタブは結果をCourierの基準フォーマットに変換しクライアントに通知する。) (セ)「6.Our client then calls the StrDate function. The client stub sends the corresponding program, version, and procedure numbers across the connection where they are read by the server stub. The server stub in our dateserver process recognizes that the program and version haven't changed, so it calls our StrDate function. (略) If the server stub receives a request for a different program or a different version, it has to exec the appropriate program to handle the new request. As long as the program and version don't change, a single process on the remote system handles the client requests.」(引用例2の第714頁第18行目-第715頁第8行目(訳)クライアントは次にStrDate機能を呼び出す。クライアントスタブは対応するプログラム番号、バージョン番号及びプロシジャー番号を通信回線に出力する。デートサーバ(dateserver)プロセス内のサーバスタブはそれらの番号を読み取り、プログラム番号とバージョン番号が変更されていないことを判定し、StrDateを実行する。(略)もしサーバスタブが異なるプログラム番号または異なるバージョン番号を持つ要求を受け取る場合には、その新たな要求を処理するために適切なプログラムを実行しなければならない。プログラム番号とバージョン番号が変わらない限り、クライアントからの要求を、リモートシステム内のひとつのプロセスが処理する。) (ソ)「7. When our function returns to the server stub, the stub converts the return value and sends it back to the client.」(第715頁第9行目-第10行目(訳)実行が済んだ後、サーバスタブは返り値を変換し、クライアントに通知する。) 以上の(サ)〜(ソ)の記載におけるクライアントは(コ)の記載におけるrdate(client)プロセスのことであり、以下同様に、チャイルドはxnscourierd(child)プロセスのことであり、サーバプログラム、デートサーバプログラム、デートサーバプロセスはいずれもdateserver(server)プロセスのことである。 これらの(コ)〜(ソ)の記載及び考察によれば、要するに、引用例2には、複数のシステムを有し、ローカルシステムからの処理要求をリモートシステムで処理する分散処理システムにおける処理方法であって、前記リモートシステムは、前記ローカルシステムからの最初の処理要求を受信してチャイルドプロセスを動作し、前記チャイルドプロセスが前記最初の処理要求を処理するデートサーバプロセスを起動し、前記デートサーバプロセスが前記最初の処理要求を処理して処理結果を、チャイルドプロセスを介さずに、前記ローカルシステムへ通知し、前記ローカルシステムは、プログラム番号とバージョン番号が同じでプロシジャー番号が異なるだけの2回目の処理要求については、チャイルドプロセスを介さずに、前記リモートシステムの前記デートサーバプロセスへ、2回目の処理要求を送信し、前記デートサーバプロセスが前記2回目の処理要求を処理して処理結果を、チャイルドプロセスを介さずに、前記ローカルシステムへ通知することを特徴とする処理方法が記載されている。 5.対比 本願発明と引用例1発明とを比較する。 引用例1発明の「コンピュータ」は本願発明の「計算機」に相当し、以下同様に、「クライアントコンピュータ10a〜10d」は「第1の計算機」に、「サービス処理要求」は「処理要求」に、「サーバコンピュータ11」は「第2の計算機」に、「グローバルトランザクション」は「トランザクション」に、「サービス処理プロセス16a〜16d」は「第2のプロセス」に、それぞれ相当する。 また、引用例1発明における「前記サービス処理要求がグローバルトランザクション内の最初のサービス処理要求である場合には、当該サービス処理要求を処理するサービス処理プロセス16a〜16dを選択してスケジュールし、」における「選択してスケジュール」することは、技術常識を考慮すると、プロセスを休眠状態ではない状態すなわち起動状態におくことであるから、本願発明における「前記第1のプロセスが前記処理要求を処理する第2のプロセスを起動し、」における「起動」することに相当する。 引用例1発明における「サーバシステム制御プログラム15」は、処理要求受信時に動作し第2のプロセスを起動する点で、本願発明の「第1のプロセス」に対応している。 引用例1発明においては最初の処理要求と2回目以降の処理要求とで場合分けをするものであるが、本願発明においては、2回目以降の処理要求については「前記第1の計算機は、同じトランザクションの2回目以降の処理要求については、前記第2の計算機の前記第2のプロセスへ処理要求を送信し、前記第2のプロセスが前記処理要求を処理して処理結果を前記第1の計算機へ通知する」としているものの、「前記第2の計算機は、前記第1の計算機からのトランザクションの処理要求を受信して第1のプロセスを動作し、前記第1のプロセスが前記処理要求を処理する第2のプロセスを起動し、前記第2のプロセスが前記処理要求を処理して処理結果を前記第1の計算機へ通知」することがどのような処理要求についてのものなのか文言上明示されていない。しかしながら、2回目以降の処理要求についての処理との対比上、本願発明において「前記第2の計算機は、前記第1の計算機からのトランザクションの処理要求を受信して第1のプロセスを動作し、前記第1のプロセスが前記処理要求を処理する第2のプロセスを起動し、前記第2のプロセスが前記処理要求を処理して処理結果を前記第1の計算機へ通知」することは第2回目以降の処理要求ではない処理要求すなわち最初の処理要求についてのものであることは明らかであるから、結局のところ、本願発明と引用例1発明は、最初の処理要求と2回目以降の処理要求とで場合分けをするものである点で同様である。 したがって、両者は、 複数の計算機を有し、第1の計算機からの処理要求を第2の計算機で処理する分散処理システムにおけるトランザクション処理方法であって、 前記第2の計算機は、前記第1の計算機からのトランザクションの処理要求を受信して第1のプロセスを動作し、前記第1のプロセスが前記処理要求を処理する第2のプロセスを起動し、前記第2のプロセスが前記処理要求を処理し、 前記第1の計算機は、同じトランザクションの2回目以降の処理要求については、前記第2のプロセスが前記処理要求を処理することを特徴とするトランザクション処理方法 である点で一致する。 一方、両者は、以下の点で相違している。 [相違点1]本願発明は、第2のプロセスが処理結果を第1の計算機に通知するのに対し、引用例1発明は、第2のプロセスが第1の計算機に通知する際に第1のプロセスを介する点。 [相違点2]同じトランザクションの2回目以降の処理要求に関し、本願発明は、第1の計算機から第2のプロセスに送信するのに対し、引用例1発明は、第1の計算機が処理要求を発信する際に、その処理要求の送受信メッセージにて第2のプロセスを明示的に指定するものではあるものの、第1のプロセスを介する点。 6.当審の判断 [相違点1]について 引用例2には、複数のシステムを有し、ローカルシステムからの処理要求をリモートシステムで処理する分散処理システムにおいて、前記リモートシステムは、前記ローカルシステムからの処理要求を受信してチャイルドプロセスを動作し、前記チャイルドプロセスが前記処理要求を処理するデートサーバプロセスを起動し、前記デートサーバプロセスが前記処理要求を処理する処理方法であって、処理結果を、前記チャイルドプロセスを介さずに、前記ローカルシステムへ通知する発明が記載されている。 引用例1発明と引用例2に記載された発明は、複数の計算機を有し、第1の計算機からの処理要求を第2の計算機で処理する分散処理システムにおいて、前記第2の計算機は、前記第1の計算機からの処理要求を受信して第1のプロセスを動作し、前記第1のプロセスが前記処理要求を処理する第2のプロセスを起動し、前記第2のプロセスが前記処理要求を処理する処理方法に関するものであり、かつ、前記第2のプロセスが処理結果を前記第1の計算機に通知するものである点で共通するうえ、あるプロセス等から別のプロセス等にデータ等を通信するに際しその通信を仲介するプロセスの数を減らすことは当業者であれば当然検討することであるから、引用例2に記載された発明における、処理結果を、処理要求を受け付けるプロセスを介さずに通知することを、引用例1発明に適用することは、当業者が想到し得たことである。 [相違点2]について 引用例2には、複数のシステムを有し、ローカルシステムからの処理要求をリモートシステムで処理する分散処理システムにおいて、前記リモートシステムは、前記ローカルシステムからの処理要求を受信してチャイルドプロセスを動作し、前記チャイルドプロセスが前記処理要求を処理するデートサーバプロセスを起動し、前記デートサーバプロセスが前記処理要求を処理する処理方法であって、前記ローカルシステムは、2回目の処理要求については、前記リモートシステムの前記チャイルドプロセスを介さずに、前記リモートシステムの前記デートサーバプロセスへ処理要求を送信する発明が記載されている。 引用例1発明と引用例2に記載された発明は、複数の計算機を有し、第1の計算機からの処理要求を第2の計算機で処理する分散処理システムにおいて、前記第2の計算機は、前記第1の計算機からの処理要求を受信して第1のプロセスを動作し、前記第1のプロセスが前記処理要求を処理する第2のプロセスを起動し、前記第2のプロセスが前記処理要求を処理する処理方法に関するものであり、かつ、2回目の処理要求の処理を行うプロセスが最初の処理要求の際に既に定まっているものである点で共通するうえ、あるプロセス等から別のプロセス等にデータ等を通信するに際しその通信を仲介するプロセスの数を減らすことは当業者であれば当然検討することであるから、引用例2に記載された発明における、既に実行するプロセスが定まっている2回目の処理要求を、処理要求を受け付けるプロセスを介さずに送信することを、引用例1発明に適用することは、当業者が想到し得たことである。 そして、本願発明の作用効果も、引用例1発明及び引用例2に記載された発明から当業者が予測できる範囲のものである。 したがって、本願発明は、引用例1発明、及び、引用例2に記載された発明に基いて、当業者が容易に発明をすることができたものである。 7.むすび 以上のとおり、本願の請求項1に係る発明は、引用例1に記載された発明及び引用例2に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 よって、結論の通り審決する。 |
| 審理終結日 | 2005-09-01 |
| 結審通知日 | 2005-09-06 |
| 審決日 | 2005-09-20 |
| 出願番号 | 特願平6-270842 |
| 審決分類 |
P
1
8・
121-
Z
(G06F)
P 1 8・ 575- Z (G06F) |
| 最終処分 | 不成立 |
| 前審関与審査官 | ▲はま▼中 信行、鳥居 稔 |
| 特許庁審判長 |
吉岡 浩 |
| 特許庁審判官 |
堀江 義隆 林 毅 |
| 発明の名称 | トランザクション処理方法、記録媒体および分散処理システム |
| 代理人 | 鈴木 誠 |
| 代理人 | 鈴木 誠 |