【事件の表示】
　特願２０００−２４９２５７「ユーザ指向処理実行装置、記録媒体及びユーザ指向処理実行方法」拒絶査定不服審判事件〔平成１３年１２月１４日出願公開、特開２００１−３４４４１９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１２年８月２１日（国内優先権主張平成１２年３月３１日）の出願であって、平成１５年３月２５日付けで拒絶査定がされ、これに対し、同年４月２８日に拒絶査定に対する審判請求がなされた。その後、当審において、平成１８年９月２８日付けで拒絶の理由が通知され、これに対し、平成１８年１１月２７日付けで、手続補正がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下「本願発明」という。）は、平成１８年１１月２７日付けの手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された次のとおりのものである。
　
「　ユーザエントリに対し、ユーザ毎の属性決定を行うユーザエントリ手段と、
　上記ユーザ属性毎に処理可能な１乃至複数のジョブの実行シーケンスを記憶しているジョブシーケンス記憶手段と、
　上記各ジョブの実行モジュールを登録しておく実行モジュール記憶手段と、
　上記実行シーケンスに基づいて、対応する実行モジュールを処理する実行処理手段とを少なくとも有するユーザ指向処理実行装置において、
　ユーザエントリの際、そのユーザから受け取った分類識別番号又は新たに設定された分類識別番号に基づいて、上記ユーザエントリ手段により、ユーザ毎の属性決定がなされ、また、上記実行処理手段により、読み出された実行シーケンスに基づいて対応する実行モジュールが実行される際に、決定されたユーザ属性に応じて、実行シーケンスが決定されることを特徴とするユーザ指向処理実行装置。」
　
３．当審の拒絶の理由
　当審において平成１８年９月２８日付けで通知した拒絶の理由（以下「先の拒絶理由」という。）のうち、理由Ａは「本件出願の下記の請求項に係る発明は、その出願前日本国内または外国において頒布された下記の刊行物に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。」というものであり、引用例として、国際公開第９９／２８８４２号パンフレット及びバーンスタイン，ニューカマー，トランザクション処理システム入門，日経ＢＰ社，１９９８年３月２３日を引用するものである。
　
４．引用例
［引用例１］
　上記拒絶の理由において引用した国際公開第９９／２８８４２号パンフレット（以下「引用例１」という。）には、図面とともに、以下の事項が記載されている。
　
（１）Accordingly, the present invention provides a method of processing an extended transaction in a client-server data processing system, including a server and one or more clients, the or each client being capable of establishing communication with said server for processing end-user initiated transactions; the method comprising the steps in the server of: receiving an end-user identifier from a client; receiving a transaction type identification; commencing processing of said identified transaction; storing state information indicative of the progress of said identified transaction; associating said end-user identifier with said state information for said identified transaction; ceasing processing of said transaction following cessation of communication with said client; receiving said end-user identifier from a client for a second time; and resuming processing of said transaction in accordance with the stored state information associated with said identified end-user. 
（第２頁第３２行−同頁第４５行） 
　 
（２）Where the extended transaction involves multiple interactions between server and client and the client has no ability to store state information, it is a preferred feature of the invention that a token is generated, uniquely identifying the transaction and also being identified with its state information. This token is passed back from server to client with a response requiring end-user interaction and then passed back to the server with the end-user response so that processing of the transaction is resumed from its current state, as defined by the respective state information. 
（第３頁第４３行−第４頁第６行） 
　 
（３）The basic function of the catchers 20, on receiving an input from a client, is to extract the generic request name and any additional data from the client input and to pass this to a queue in the listener 26. If the client has also provided an Application Interaction Token (AIT), one of which is associated uniquely with every extended transaction, this is also passed to the listener. 
　 
In the case of a web browser client, the client input is sent via a web server (not shown for the generalised clients 5 of Figure 1) which recognises a URL (Uniform Resource Locator) in the browser input as a request name and passes the data over a Common Gateway interface (CGI) to one of the catchers 20 which is specific to a web browser client. The catcher converts the web based data, such as the URL, to a generic form of request and data and passes it to the listener 26.
　 
The listener 26 processes its queue to route work requests to the appropriate server process. It does this by passing the generic request name, any associated data and the AIT, if any, to the mapper 27. The mapper looks up the request name and returns a 'type' to the listener indicating whether this is a business service request (BSR) or a request for page delivery to provide a response to the client. If an AIT is supplied with the request, the mapper validates it. If no AIT is supplied and the request name is recognised as the first of a new extended transaction, the mapper generates an AIT. 
（第５頁第４０行−第６頁第１７行） 
　 
（４）Initially, when a user wishes to initiate a new business transaction, he identifies himself to the server via the appropriate client by supplying his name (ID) and optionally a password. As described above, the work initiation portion of the server returns a canvas presenting a menu of possible extended transactions to the user. The user then selects one of the transactions and this selection is converted by the work initiation portion of the server first to a generic request name and then to a business service request to a business logic manager (BLM) 29. 
　 
The business logic manager 29 determines what action to take according to predefined rules for processing this type of extended transaction. It divides the BSR into a set of component business logic tasks (BLTs) which it then schedules to be carried out by a back-end transaction processing system 30, coordinating the tasks and the handling of their responses according to criteria defined by the rules. The system 30 may be a conventional transaction processing system, such as the CICS system from IBM (CICS is a trademark of International Business Machines  Corporation), to which has been added a mirror function 31 for scheduling the tasks. The BLTs, such as BLT 32, run as applications in the CICS system and can call CICS functions over the CICS API. 
　 
The BLTs may obtain information from CICS resources and put the data into an application scratchpad 40, over a special API for the extended transaction manager. This information may include state data for the transaction, generated as it progresses through various stages. 
（第６頁第３５行−第７頁第１４行） 
　 
（５）The operation of the system will now be described in more detail with reference to the flow diagram of Figure 4. 
　 
When a user accesses the server through any client, in step 99, he will be given the opportunity (step 100) to register (step 101), if a new user. A user who is already registered identifies himself, in step 102, by supplying a name and password, customer number or similar identification. 
（第９頁第１２行−同頁第１８行） 
　 
（６）In step 103, the home base is checked, to see if the known user has any in-flight extended transactions, that is, existing but incomplete transactions which are currently suspended. If not, in step 104,a menu of available business transactions is presented to the user. The same menu is also presented to a newly registered user. The user selects one of these transactions and fills in any data fields which are then required and the corresponding opening request ID and data are sent to the appropriate catcher. After the request ID and data are converted to generic form and passed to the listener and mapper, the unique AIT for the newly started transaction is then generated by the mapper and stored in the home base, together with the associated request ID and any data (step 105). 
　 
If the user did have in-flight transactions, the system would instead, in step 106, display a menu of these transactions and give the user the option of starting a new transaction (step 107), resuming an existing transaction (step 108) or cancelling an existing transaction (step 109). 
Selecting the option of starting a new transaction, leads the user through steps 104 and 105 as described above. 
（第９頁第２０行−同頁第３７行） 
　 
（７）In step 111, after generation of the AIT and of a home base entry in step 105, the initial request is passed, via the listener and mapper, as a business service request to the business logic manager 29 and the business logic tasks 32 are started. These normally involve further interaction with the user via the client. The AIT is passed to the client from the server via the responder and catcher so that the client can continue the interaction from the current point in the transaction without having to retain any information itself as to the current state of the transaction. The AIT is resent by the client to the catcher in the next response which forms part of the same interaction. 
（第９頁第３９行−第１０頁第３行） 
　 
（８）If, in step 108, the user selects an existing transaction to resume, the homebase entries for that user are scanned, in step 110, and the AIT for the selected existing transaction is provided. Processing then resumes, in step 111, from the state stored in the homebase 41 and/or scratchpad 40. 
（略） 
When an extended transaction is completed (step 113) or a decision is made to cancel an existing transaction (step 109), the record of the transaction is deleted from the home base, together with its AIT (step 114). If the transaction is not completed, the client either proceeds with further processing from step 115 by returning to step 111 or terminates its interaction by disconnecting at step 116 to interrupt the transaction at an intermediate state. Disconnection also takes place, in step 117, if, in step 109, the user decides not to cancel the existing transaction. Processing can be resumed from step 100 at a later time by the user providing his user ID via any client. 
（第１０頁第５行−同頁第４０行） 
　 
［引用例１発明］ 
　引用例１の摘記事項（１）より、引用例１は、クライアントサーバシステムにおいて、継続的で、適宜再開が可能なトランザクションを実現するシステムにおける継続するトランザクションを管理するサーバシステムについて記載されたものである。また、引用例１は、クライアントからend-user identifierを受けつけるものであるから、ユーザのエントリを行う手段を有していることは明らかである。 
　引用例１の特に摘記事項（３）及びFIG.4には、ユーザから受けとったApplication Interaction Token（以下AITという。）又は新たに設定されたAITより、Business Service Request（以下BSRという。）を求める手段であるmapperが記載されている。 
　次に、引用例１の特に摘記事項（４）及びFIG1, 4には、ユーザのBSRが求まると、Business Logic Manager (以下BLMという。）が、当該BSRのタイプのトランザクションを処理するために予め定義されたルールに従って、当該BSRを対応するBusiness Logic Tasks（以下BLTという。）の集合とし、この一連のBLTをCICS systemであるBack-end transaction processing systemに当該ルールに従って実行させる旨が記載されている。
　ここで、BSRは、ユーザが要求するトランザクションを構成するBLTの実行をBLMに要求するものであることから、求められるBSRは、個々のユーザと対応づけられたユーザ毎のBSRであることは明らかである。また、技術常識を勘案すると、引用例１には明示はないものの、BSRに対応するBLTには単数及び複数の場合があること、BSRのタイプ毎にその単数及び複数のBLTを実行するためのルールが予め定義され記憶されていること、CICS applicationである個々のBLTが記憶されていることはそれぞれ明らかであるから、引用例１のサーバシステムにおいて、BSRに対応する１乃至複数のBLTを実行するためのルールを記憶する手段及び個々のBLTを記憶する手段を備えることは明らかであり、さらに、Back-end transaction processing systemにより、１乃至複数のBLTを実行するためのルールに従って当該BLTが実行される際には、１乃至複数のBLTを実行するため採用すべきルールが決定され、記憶手段から読み出されて利用されることも明らかである。 
　
　してみれば、引用例１には、 
「　ユーザのエントリを行う手段と、 
　ユーザ毎のBSRを求める手段と、 
　BSRに対応する１乃至複数のBLTを実行するためのルールを記憶した記憶手段と、 
　個々のBLTのプログラムを記憶した記憶手段と、 
　前記ルールに基づいて、１乃至複数のBLTを実行するBack-end transaction processing systemとを有する継続するトランザクションを管理するサーバシステムにおいて、
　ユーザから受けとったAIT又は新たに設定されたAITより、上記BSRを求める手段により、ユーザ毎のBSRが求められ、また、上記Back-end transaction processing systemにより、読み出された、１乃至複数のBLTを実行するためのルールに従ってBLTが実行される際に、１乃至複数のBLTを実行するためのルールが決定される、
継続するトランザクションを管理するサーバシステム。　」 
　の発明（以下「引用例１発明」と言う）が開示されている。 
　 
［本願発明と引用例１発明との比較］ 
　そこで、本願発明と引用例１発明とを比較する。 
　まず、所謂トークンである引用例１発明のAITはある種の識別符号であることは明らかである。また、本願発明の「ユーザ属性」について、本願明細書では「本装置によって実行される定型的なジョブ群の対象者として細かく分類するための概念である」（段落【０００８】）と説明されていることから、本願発明の「ユーザ毎の属性」または「ユーザ属性」とは、個々のユーザが求める定型ジョブ群の種類のことであると解することができる。一方、引用例１発明のBLTは本願発明の「ジョブ」に相当し、先に検討したように引用例１発明のBSRは、ユーザが要求するトランザクションを構成するところの、一連のBLTの実行をBLMに要求するものであるから、引用例１発明のBSRは、本願発明における上記ユーザが求める定型ジョブ群の種類と同義であるといえる。してみれば、引用例１発明のBSRは、本願発明の「ユーザ毎の属性」または「ユーザ属性」に相当する。 
　よって、引用例１発明の「ユーザ毎のBSRを求める手段」及び「ユーザから受けとったAIT又は新たに設定されたAITより、上記BSRを求める手段により、ユーザ毎のBSRが求められ」ることと、本願発明の「ユーザエントリに対し、ユーザ毎の属性決定を行うユーザエントリ手段」及び「ユーザエントリの際、そのユーザから受け取った分類識別番号又は新たに設定された分類識別番号に基づいて、上記ユーザエントリ手段により、ユーザ毎の属性決定がなされ」ることとでは、後記する相違点はあるものの、それぞれ、「ユーザ毎の属性決定を行う手段」及び「ユーザから受け取った識別符号又は新たに設定された識別符号に基づいて、ユーザ毎の属性決定がなされ」るという概念で共通する。 
　次に、引用例１発明の「BSRに対応する１乃至複数のBLTを実行するためのルール」は、BSRのタイプ毎に１乃至複数のBLTの処理を実行するためのルールであり、また、一般に、何らかのジョブ又は処理を実行するための「実行シーケンス」は、当該何らかのジョブ又は処理を実行するための「ルール」の一つの形態といえる。よって、引用例１発明の「BSRに対応する１乃至複数のBLTを実行するためのルール」と、本願発明の「ユーザ属性毎に処理可能な１乃至複数のジョブの実行シーケンス」とでは、後記する相違点があるものの、「ユーザ属性毎に処理可能な１乃至複数のジョブの実行ルール」との概念で共通し、引用例１発明の「BSRに対応する１乃至複数のBLTを実行するためのルールを記憶した記憶手段」と、本願発明の「上記ユーザ属性毎に処理可能な１乃至複数のジョブの実行シーケンスを記憶しているジョブシーケンス記憶手段」とでは、「ユーザ属性毎に処理可能な１乃至複数のジョブの実行ルールを記憶している記憶手段」という概念で共通する。 
　次に、引用例１発明の「個々のBLTを実行するためのプログラムを記憶した記憶手段」は、本願発明の「上記各ジョブの実行モジュールを登録しておく実行モジュール記憶手段」に相当する。 
　次に、上記の検討を踏まえれば、引用例１発明の「前記ルールに基づいて、１乃至複数のBLTを実行するBack-end transaction processing system」及び「上記Back-end transaction processing systemにより、読み出された、１乃至複数のBLTを実行するためのルールに従ってBLTが実行される際に、１乃至複数のBLTを実行するためのルールが決定される」ことと、本願発明の「上記実行シーケンスに基づいて、対応する実行モジュールを処理する実行処理手段」及び「上記実行処理手段により、読み出された実行シーケンスに基づいて対応する実行モジュールが実行される際に、決定されたユーザ属性に応じて、実行シーケンスが決定される」こととは、後記する相違点があるものの、「上記実行ルールに基づいて、対応する実行モジュールを処理する実行処理手段」及び「上記実行処理手段により、読み出された実行ルールに基づいて対応する実行モジュールが実行される際に、実行ルールが決定される」という概念で共通する。 
　次に、引用例１発明の「継続するトランザクションを管理するサーバーシステム」は、ユーザの利便性を従来技術より向上させる処理を行うシステムという意味で「ユーザ指向処理実行装置」といえるものである。よって、後記する相違点はあるものの、引用例１発明の「継続するトランザクションを管理するサーバシステム」は、本願発明の「ユーザ指向処理実行装置」に対応する。 
　よって、引用例１発明と本願発明とでは、 
　「ユーザ毎の属性決定を行う手段と、 
　上記ユーザ属性毎に処理可能な１乃至複数のジョブの実行ルールを記憶している記憶手段と、 
　上記各ジョブの実行モジュールを登録しておく実行モジュール記憶手段と、 
　上記実行ルールに基づいて、対応する実行モジュールを処理する実行処理手段と を少なくとも有することを特徴とするユーザ指向処理実行装置において、
　ユーザから受け取った識別符号又は新たに設定された識別符号に基づいて、ユーザ毎の属性決定がなされ、また、上記実行処理手段により、読み出された実行ルールに基づいて対応する実行モジュールが実行される際に、実行ルールが決定されることを特徴とするユーザ指向処理実行装置。」 
との点で一致し、以下の点で相違する。 
　 
［相違点１］ 
　本願発明は「ユーザエントリに対し、そのユーザから受け取った分類識別番号又は新たに設定された分類識別番号に基づき、ユーザ毎の属性決定を行うユーザエントリ手段」を有するものであり、上記一致点における「ユーザ毎の属性決定を行う手段」はユーザエントリ手段であって、「ユーザエントリの際」「ユーザエントリ手段により」ユーザ毎の属性決定がなされるのに対し、引用例１発明では、ユーザエントリ手段とは別に、「ユーザから受け取った識別符号又は新たに設定された識別符号に基づき、ユーザ毎の属性決定を行う手段」を有し、ユーザ毎の属性決定は「ユーザエントリの際」「ユーザエントリ手段により」なされるものではない点。 
　
［相違点２］
　上記相違点１に関連し、本願発明では「分類識別番号」に基づいて、ユーザ毎の属性決定が行われるのに対し、引用例１発明では「識別符号」に基づいて、ユーザ毎の属性決定が行われる点。
　
［相違点３］
　本願発明は、ジョブの「実行シーケンス」に基づいて実行モジュールを処理するものであって、「決定されたユーザ属性に応じて」当該実行シーケンスが決定されるのに対し、引用例１発明では、BLTを実行するための「ルール」に基づいて処理されるものであって、「決定されたユーザ属性に応じて」当該ルールが決定されるものではない点。
　
６．当審の判断
　以下上記相違点について検討する。 
　
［相違点１及び２について］
　上記相違点１及び２について検討する。
　まず、一般に、符号として番号を用いることは周知である。また、識別符号である、引用例１発明のAITはトランザクションを分類する意味を持つものといえる。よって、引用例１発明における「識別符号」を「分類識別番号」と変更することに格別の困難はない。
　次に、情報処理技術一般において、ある情報処理の処理手順を省略及び変更することは、当該変更が技術的に格別の困難がなく、かつ、論理的に整合している限りにおいては、当業者が適宜設計的に変更可能な事項である。ここで、引用例１発明は、end-user identifierを受けつけエントリを行う手段を有し、さらに、該エントリを行う手段とは別の手段により「ユーザから受け取った識別符号又は新たに設定された識別符号に基づいて、ユーザ毎の属性決定がなされ」るものであるが、当該処理をエントリを受け付ける段階で同時的に行い、エントリ手段の機能に含めるよう変更し、「ユーザエントリの際」「ユーザエントリ手段により」ユーザ毎の属性決定がなされるようにすることは、実質的に単なる処理手順の変更にあたり、さらに、当該変更には技術的に格別の困難も認められず、かつ、処理の論理上何ら矛盾を生じさせないものである。
　よって、本願発明の相違点１及び２に係る事項は当業者が容易に想到できた事項である。
　
［相違点３について］
　一般に、ジョブ等の処理の実行ルールとして種々のものが知られているところ、いわゆる「実行シーケンス」もジョブ等の処理の実行ルールとして周知の形態である。
　そして、引用例１発明におけるルールも、BSRに対応した１乃至複数のBLTの実行処理を規定するものであるから、実行ルールとして実行シーケンスを採用すること、並びに、BSR即ちユーザ属性に応じて、実行ルールとしての実行シーケンスを決定されるようにすることは、当業者が容易に想到し得た事項である。
　してみれば、本願発明の相違点３に係る事項は当業者が容易に想到できた事項である。。
　
　なお、請求人は意見書において、以下のように主張している。
（ａ）引用例１について、「ユーザがアクセスしてきた場合に、そのユーザのアクション（ＩＤやパスワードを使った認証処理など）を伴わずに、最初に該ユーザ属性を自動的に判断し、判断された属性に基づいて、その属性に対応づけられて最初から用意されている実行シーケンスの決定がなされ、該実行シーケンス（処理実行指示書のようなもの）に基づき、そこに指示されている１乃至複数のジョブの実行モジュールを、該実行シーケンスの通りに実行して処理を行うというものであります。」
　
（ｂ）「しかし、該引用例の構成には、ユーザがアクセスしてきた場合に、最初にそのユーザの属性を自動的に装置側で判断し、判断された属性に基づいて、その属性に対応づけられて最初から用意されている実行シーケンスの決定がなされる本願に特有な構成は、全く開示されていません（引用例１は、中断前後のユーザが同じか否かを確認しているだけで、アクセスしてきたユーザの属性判断を行った後、その属性に適した実行シーケンスを適用しようとする発想の構成ではない）。従って、手続きに不慣れなユーザがアクセスしてきた時に（ここでは、引用例１の第３頁第２１頁以下に示されるような名前やパスワードなどのエンドユーザ識別子がユーザに求められることはありません）、夫々のユーザ毎に行うべきジョブが装置側で自動的に判断されて（ユーザの属性決定による）実行される本願に規定される処理（本願【００５６】〜【００６０】参照）は実施されておりませんので、引用例１の構成では、上述した本発明により達成される効果は実現できません。」
　
（ｃ）「以上のように、引用例２にも引用例１にも、本発明の上記主要構成は規定されておりません。そればかりか、本願がねらいとしていた、本装置側にアクセスしてきて手続きを行おうとする者が、そのような手続きに不慣れな場合を想定し、そのアクセスに対して本装置側で自動的にできるあらゆる処理を、実行シーケンスとして予め登録しておくことで、手続を行う金融商品などについて、予め十分な知識を有していないような者でも、必要な場合にだけ他の者のアシストを受けながら、ネット上で必要な処理を行うことができるようになるという作用・効果については、両引用例のどこにも、そのような記載がなく、ましてやそのような目的、或いはそのような作用効果を達成できる構成についても、開示されておりません。」
　
　そこで、上記請求人の主張について検討する。
　まず、（ａ）に関し、本願請求項１には、「ユーザエントリに対し、ユーザ毎の属性決定を行う」と記載されているだけであって、「ユーザがアクセスしてきた場合に、そのユーザのアクション（ＩＤやパスワードを使った認証処理など）を伴わずに、最初に該ユーザ属性を自動的に判断」する旨の記載はないため、本願発明は、「ユーザがアクセスしてきた場合に、そのユーザのアクション（ＩＤやパスワードを使った認証処理など）を伴わずに、最初に該ユーザ属性を自動的に判断」するものと限定的に解釈すべきものではなく、ユーザがアクセスしてきた場合に、そのユーザの前記アクションを伴うものを排除するものではない。してみれば、上記（ａ）を前提とした請求人の主張は、そもそもが本願請求項１の記載に基づくものではない。
　仮に、本願発明を、「ユーザがアクセスしてきた場合に、そのユーザのアクション（ＩＤやパスワードを使った認証処理など）を伴わずに、最初に該ユーザ属性を自動的に判断」するものと限定的に解釈するとしても、引用例１発明において、ユーザのアクションを伴う認証処理を省略し、引用例１発明のAITを用いて、ユーザのアクションを伴わずに、最初に該ユーザ属性を自動的に判断するように変更することは、AITが特定のユーザのトランザクションと一対一対応していることから、当業者であれば容易に想到できた範囲内のものである。すなわち、「ユーザがアクセスしてきた場合に、そのユーザのアクション（ＩＤやパスワードを使った認証処理など）を伴わずに、最初に該ユーザ属性を自動的に判断」することは、当業者が容易に想到できた事項である。
　
　また、請求人は上記（ｂ）において、「引用例１は、中断前後のユーザが同じか否かを確認しているだけで、アクセスしてきたユーザの属性判断を行った後、その属性に適した実行シーケンスを適用しようとする発想の構成ではない」と指摘しているが、引用例１発明では、「中断前後のユーザが同じか否かを確認しているだけ」ではなく、クライアントがサーバにアクセスする際、end-user identifierを送信するだけでなく、AITも送られており、クライアントから送信されたAITに基づいてBSRを決定し、さらにBSRに対応するルールに基づいてトランザクションを実行している。（上記［引用例１発明］、引用例１の摘記事項（３）及び（４）を参照されたい。）すなわち、AITに基づきアクセスしてきたユーザの属性であるBSRの判断を行い、その属性に適したルールに基づき処理を行うものである。そして、判断されたユーザ属性であるBSRに応じて、実行シーケンスの形態のルールが決定がなされるようにすることの容易想到性は、上記相違点３についての検討のとおりである。
　
　さらに、上記（ｃ）で指摘している本願発明の効果について検討するに、引用例１発明においても、ユーザが要求する様々なトランザクションを構成するところの一連のBLTをシステムが自動的に実行処理するためのルールが予め登録されているわけであるから、上記（ｃ）で請求人が主張する効果も、当業者であれば予想の範囲内のものである。
　
　してみれば、請求人の上記（ａ）ないし（ｃ）の主張は、採用できない。　
　このように検討してくると、上記相違点１−３に係る本願発明の構成は、引用例１発明及び周知技術に基づいて、当業者が容易に想到できた事項である。
　よって、本願発明は、引用例１発明、及び、周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
７．むすび
　以上のとおり、本願の請求項１に係る発明は、引用例に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　したがって、本願は拒絶されるべきものである。
　
　よって、結論のとおり審決する。