【事件の表示】
　平成　９年特許願第２６５６９６号「ネットワーク・サービスへのアクセス提供方法」拒絶査定に対する審判事件［平成１０年　６月　９日出願公開、特開平１０−１５４０７８］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．経緯
１）出願日　　　　　　　：平成 9年 9月30日
　　　　　（パリ条約による優先権主張　1996年10月 7日，米国）
２）拒絶査定（起案日）　：平成14年 9月11日
３）審判請求書　　　　　：平成14年11月19日
４）手続補正書　　　　　：平成14年11月19日
５）拒絶理由（起案日）　：平成15年 5月27日
６）意見書　　　　　　　：平成15年 9月26日
７）手続補正書　　　　　：平成15年 9月26日
　
２．本願発明
　本願発明は、平成15年 9月26日付で補正された、特許請求の範囲の請求項１に記載の次のとおりのもの（以下、本願発明という。）である。
　
「　ネットワーク・クライアント上で実行されるアプリケーションに、複数の遠隔ネットワーク・サービスへのアクセスを提供する方法であって、
（イ）前記ネットワーク・クライアントのユーザからの要求に応答して、前記ネットワーク・クライアントが、前記複数の遠隔ネットワーク・サービスへのアクセスを提供するための実行可能コードから成る仮想環境マネージャを遠隔サービス・プロバイダから前記ネットワーク・クライアントのメモリにダウンロードするステップと、
（ロ）前記仮想環境マネージャが、前記アプリケーションが前記複数の遠隔ネットワーク・サービスのうち少なくとも１つの遠隔ネットワーク・サービスへのアクセスを要求しているか否かを決定するステップと、
（ハ）前記アプリケーションが前記少なくとも１つの遠隔ネットワーク・サービスへのアクセスを要求しているとの決定に応答して、前記仮想環境マネージャが、前記ネットワーク・クライアントが使用可能な１組の遠隔ネットワーク・サービスのリストを保持する遠隔サービス・ディレクトリを照会することにより、前記少なくとも１つの遠隔ネットワーク・サービスを提供するための特定の遠隔サービス・プロバイダの位置を突き止めるステップと、
（ニ）前記アプリケーションが前記少なくとも１つの遠隔ネットワーク・サービスを要求時にアクセスすることができるように、前記仮想環境マネージャが、前記特定の遠隔サービス・プロバイダに接続するための少なくとも１つのクライアント・スタブまたはサービス・ハンドルを、前記遠隔サービス・ディレクトリから前記ネットワーク・クライアントのメモリにダウンロードすることにより、前記少なくとも１つの遠隔ネットワーク・サービスを構成するステップと、
（ホ）前記仮想環境マネージャが、前記アプリケーションに対し、構成済みの前記少なくとも１つの遠隔ネットワーク・サービスへのアクセスを提供するステップと、
　を含む、方法。」
　
３．刊行物
　本件優先権主張日前に、外国において頒布された刊行物である、
Wollrath,A.,et al、A Distributed Object Model for the Java System、Proceedings of the USENIX Conference on Object-Oriented Technologies、1996年6月、Page.219-231
には、参照する図面とともに、次の記載がある。
　
ａ．「 Introduction
  Distributed systems require entities which reside in different address spaces, potentially on different machines, to communicate. The Java system  (hereafter referred to simply as Java) provides a basic communication mechanism, sockets [13]. While flexible and sufficient for general  communication, the use of sockets requires the client and server using this medium to engage in some application-level protocol to encode and  decode messages for exchange. Design of such protocols is cumbersome and can be error-prone. 
　An alternative to sockets is Remote Procedure Call (RPC) [13]. RPC systems abstract the communication interface to the level of a procedure call.  Thus, instead of application programmers having to deal directly with sockets, the programmer has the illusion of calling a local procedure when, in  fact, the arguments of the call are packaged up and shipped off to the remote target of the call. Such RPC systems encode arguments and return  values using some type of an external data representation (e.g., XDR).
　RPC, however, does not translate well into distributed object systems where communication between program-level objects residing in different address spaces is needed. In order to match the semantics of object invocation, distributed object systems require remote method invocation or
  RMI. In such systems, the programmer has the illusion of invoking a method on an object, when in fact the invocation may act on a remote object (one not resident in the caller's address space).
  In order to support distributed objects in Java, we have designed a remote method invocation system that is specifically tailored to operate in the  Java environment. Other RMI systems exist (such as CORBA) that can be adapted to handle Java objects, but these systems fall short of seamless integration due to their inter-operability requirement with other languages. CORBA presumes a heterogeneous, multi-language environment and thus must have a language neutral object model. In contrast, the Java language's RMI system assumes the homogeneous environment of the Java Virtual Machine, and the system can therefore follow the Java object model whenever possible.」（第1頁左欄第23行〜右欄題33行）
（仮訳）「導入
  分散システムは、異なったアドレス・スペースに存在する、潜在的に異なったマシンの上の、エンティティーを必要とします。  Java システム（以下、単に「Java」と言う。）は基本的なコミュニケーション・メカニズムである、ソケット[13]を供給します。 ソケットの使用は、柔軟で、一般の通信には十分である一方で、クライアントとサーバに、幾つかのアプリケーション・レベルのプロトコルで、メッセージを交換するためのエンコード及びデコードするための手段を要求します。このようなプロトコルの設計は扱いにくくて、そしてエラーが起きやすいものです。 　
  ソケットの代替手段はリモート・プロシジャー・コール（RPC）[13]です。 RPC システムはプロシジャー・コールのレベルにコミュニケーション・インタフェースを抽象化します。 このように、アプリケーション・プログラマーが直接ソケットを扱う代わりに、呼び出しの引数がパッケージされて、そしてリモートの標的に送り出されるとき、プログラマーは、ローカルなプロシージャを呼び出す如き錯覚を持ちます。このような RPC システムは、引数と返り値とを外部のデータ表現のいくつかの型を使って、エンコードします（例えば、XDR ）。　
  RPCは、しかしながら、異なったアドレス・スペースに存在するプログラム−レベルのオブジェクト間のコミュニケーションが必要とされる、分散オブジェクトシステムの中には、うまく移植することができません。Object Invocationのセマンティクスをマッチさせるために、分散オブジェクトシステムは、Remote Method Invocation すなわちRMI を必要とします。 このようなシステムでは、その時、現実では、起動はリモートのオブジェクト（呼出し側のアドレス空間に存在しないオブジェクト）に作用するかもしれないが、プログラマーはオブジェクトの上のメソッドを呼び出す如き錯覚を持ちます。　
  Javaで分散オブジェクトをサポートするために、我々は、Java環境に特に適合する、remote method invocation システムを設計しました。 他にも、Javaオブジェクトの扱いに適合する事のできる、RMI システム（CORBAのようなシステム）が存在しますが、しかし、これらのシステムは他の言語との互換性を必要とするためにシームレスなインテグレーションを達成できません。 CORBA は混成の、多言語の環境を予想して、そして、そのために、言語の中間オブジェクトモデルを持っていなくてはなりません。 それと対照的に、 Java 言語の RMI システムは Java バーチャルマシンの同種の環境を想定し、そして、そのために、システムはいつでも Java オブジェクトモデルに従うことができます。」
　
ｂ．「3 Distributed Object Model
 In our model, a remote object is one whose methods can be accessed from another address space, potentially on a different machine. An object of this type is described by a remote interface, which is an interface (in Java) that declares the methods of a remote object. Remote method invocation (or RMI) is the action of invoking a method (of a remote interface) on a remote object. Most importantly, a method invocation on a remote object has the same syntax as a method invocation on a local object.
 Clients of remote objects program to remote interfaces, not to the implementation classes of those interfaces. 」（第3頁左欄第15〜28行）
（仮訳）「３分配されたオブジェクトモデル
 我々のモデルでは、remote object は、もう１つのアドレス空間である、潜在的に異なったマシンの上から、アクセスされることができます。 この型のオブジェクトは、remote objectのメソッドを宣言するインタフェース（ Java の）であるremote interface によって記述されます。 Remote Method Invocation （すなわち RMI ）は、（remote interface の）メソッドを起動する動作です。 最も重要なことは、remote object上のメソッド起動は、local object上のメソッド起動と同じ文法を持っていることです。
 Remote objectsのクライアントは、それらのインタフェースのimplementation classesに対してではなく、remote interfacesに対してプログラムされます。」
　
ｃ．「Remote Interfaces
 In order to implement a remote object, one must first define a remote interface for that object. A remote interface must extend (either directly or indirectly) a distinguished interface called java.rmi.Remote. This interface is completely abstract and has no methods.」（第3頁右欄第7〜12行）
（仮訳）「Remote Interfaces
　Remote objectをインプリメントするために、最初にそのオブジェクトのためのRemote Interfacesを定義しなければなりません。Remote Interfacesは、java.rmi.Remoteと呼ばれる、区別されたインターフェースを(直接あるいは間接的に)拡張しなければなりません。このインターフェースは完全に抽象的で、メソッドがありません。」
　
ｄ．「Remote Implementations
  There are two ways to implement a remote interface (such as BankAccount). The simplest implementation route is for the implementation class,  e.g., BankAcctImpl, to extend the class RemoteServer. We call this first scheme remote implementation reuse. Figure 1 below is an illustration of  the interface and class hierarchies for remote interfaces and implementations in this scheme. 
 ・・・Figure 1 omitted・・・
  The default constructor for RemoteServer takes care of making an implementation object remotely accessible to clients by exporting the remote  object implementation to the RMI runtime. The class RemoteObject overrides methods inherited from Object to have semantics that make sense  for remote objects. We will discuss what the appropriate semantics for these methods are in the section on Object Method Semantics.
  In the second implementation scheme, called local implementation reuse, the implementation class for a remote object does not extend  RemoteServer but may extend any other local implementation class as appropriate. However, the implementation must explicitly export the object  to make it remotely accessible. 」（第3頁右欄第42行〜第4頁左欄第17行）
（仮訳）「remote interface (BankAccountのような)をインプリメントするために、2つの方法があります。implementation class(例えばBankAcctImpl)の最も単純なインプリメンテーション・ルートはクラスRemoteServerを拡張することです。私たちはこの第1のスキームをremote implementation reuseと呼びます。下記の図1は、このスキームの、remote interfaces と implementationsに関するインターフェースとクラスの階層の実例です。
・・・図１省略・・・
RemoteServerのためのデフォルトconstructorは、RMIランタイムにremote object implementationをエクスポートすることにより、implementation objectをクライアントが遠隔にアクセス可能とする世話をします。クラスRemoteObjectは、remote objectsにとって意味をなすセマンティクスを持つために、オブジェクトから継承したメソッドを上書きします。私たちは、それらのメソッドにとって何が適切なセマンティクスかを、Object Method Semanticsのセクションで議論するでしょう。
　local implementation reuseと呼ばれる第2のインプリメンテーション計画では、remote objectのためのimplementation classは、RemoteServerを拡張しないが、適切であれば、他のlocal implementation classを拡張してもよいものです。しかしながら、そのimplementationは、オブジェクトを遠隔にアクセス可能にするために、明示的にオブジェクトをエクスポートしなければなりません。」
　
ｅ．「Remote Reference Types
 In the distributed object model, clients interact with stub (surrogate) objects that have exactly the same set of remote interfaces defined by the remote object's class; the stub class does not include the non-remote portions of the class hierarchy that constitutes the object's type graph. This is because the stub class is generated from the most refined implementation class that implements one or more remote interfaces. For example, if C extends B and B extends A, but only B implements a remote interface, then a stub is generated from B, not C.」（第5頁左欄第3〜14行）
（仮訳）「Remote Reference 型
　分散オブジェクトモデルでは、クライアントが、remote objectクラスによって定義されるremote interfacesとまったく同じ集合を持つ、スタブ(代理)オブジェクトと対話します；スタブ・クラスは、オブジェクトのタイプ・グラフを構成するクラス階層のnon-remoteである部分を含んでいません。これはスタブ・クラスが、1つ以上のremote interfacesをインプリメントする最も洗練されたインプリメンテーション・クラスから生成されるからです。例えば、CがBを拡張し、BがAを拡張し、しかし、Bだけがremote interfaceをインプリメントする場合、次に、スタブが、CではなくBから生成されます。　」
　
ｆ．「Remote Method Invocation
 For a client to invoke a method on a remote object, that client must first obtain a reference to the object. A reference to a remote object is obtained in the usual manner: as a return value in a method call or as a parameter passed to a method. The RMI system provides a simple bootstrap name server from which to obtain remote objects on given hosts.」（第5頁左欄第31〜38行）
（仮訳）「Remote Method Invocation
　クライアントがremote object上のメソッドを起動するために、そのクライアントは、最初にオブジェクトへのreferenceを得なければなりません。Remote Objectへのreferenceは通常の方法で得られます：メソッド呼び出しの返し値として、すなわち、メソッドへ渡されるパラメータとしてです。RMIシステムは、与えられたホストのremote objectsを得る単純なブートストラップ・ネーム・サーバを提供します。」
　
ｇ．「Locating Remote Objects
 A simple bootstrap name server is provided for storing named references to remote objects. A remote object reference can be stored using the URL-based interface java.rmi.Naming.
 For a client to invoke a method on a remote object, that client must first obtain a reference to the object. A reference to a remote object is usually obtained as a return value in a method call. The RMI system provides a simple bootstrap name server from which to obtain remote objects on given hosts. The Naming interface provides Uniform Resource Locator (URL) based methods to lookup, bind, rebind, unbind and list the name and object pairings maintained on a particular host and port.」（第7頁左欄第4〜20行）
（仮訳）「Locating Remote Objects
　単純なブートストラップ・ネーム・サーバは、remote objectsへの名前の付けられたreferenceを格納するために、提供されます。Remote Objectへのreferenceは、URLに基づいたインターフェースjava.rmi.Namingを使用して格納することができます。クライアントがremote object上のメソッドを起動するために、そのクライアントは、そのオブジェクトへの referenceを最初に得なければなりません。 Remote Objectへのreferenceは、たいてい、メソッド・コールの返り値として得られます。RMIシステムは、それから、与えられたホストのremote objectsを得るための、単純なブートストラップ・ネーム・サーバを提供します。Naming interfaceは、ルックアップし、バインドし、再バインドし、アンバインドし、そして、特定のホストとポートによって維持されている、名前とオブジェクトの組みをリストするためのメソッドに基づいた、Uniform Resource Locator (URL)を提供します。」
　
ｈ．「Architectural Overview
・stub/skeletons - client-side stubs (proxies) and server-side skeletons (dispatchers) 
・remote reference layer - invocation behavior and reference semantics (e.g., unicast, multicast) 
・transport - connection set up and management and remote object tracking 
The application layer sits on top of the RMI system.
 ・・・Figure 3 omitted・・・
 Figure 3 is an illustration of the layers of the RMI system. A remote method invocation from a client to a remote server object travels down through the layers of the RMI system to the client-side transport, then up through the server-side transport to the server. The rest of this section summarizes the functionality at each layer in the system.
 A client invoking a method on a remote server object actually makes use of a stub or proxy for the remote object as a conduit to the remote object. A client-held reference to a remote object is a reference to a local stub. This stub is an implementation of the remote interfaces of the remote object and forwards invocation requests to that server object via the remote reference layer.」（第7頁第8〜32行）
（仮訳）「アーキテクチャの概観
　RMIシステムの3つのレイヤは下記から成ります:
・stub/skeletons -　クライアント側スタブ(proxies)及びサーバー側スケルトン(dispatchers)
・remote reference layer -　invocation及びセマンティクス(例えばユニキャスト、マルチキャスト)
・transport - コネクションのセット・アップ、管理及びremote objectのトラッキング
アプリケーション層はRMIシステムの上にあります。
　・・・図3省略・・・
　図3はRMIシステムのレイヤの実例です。クライアントから遠隔のサーバー・オブジェクトまでのremote method invocationnは、RMIシステムの層を通って、クライアント側transportに、下へ移動し、その後、サーバ側のtransportを通って上に、サーバへと渡り歩きます。このセクションの残りでは、このシステムの各層の機能を要約します。
　遠隔のサーバー・オブジェクト上のメソッドを起動するクライアントは、現実にremote objectへの導管として遠隔のオブジェクトのためのstubかproxyの使用を行ないます。remote objectへのクライアントに保持されたreferenceはローカルのstubへのreferenceです。このstubはremote objectのremote interfacesのインプリメンテーションです。そして、起動リクエストをremote referenceを経由してそのサーバー・オブジェクトへ転送します。」
　
ｉ．「Stub/Skeleton Layer
 The stub/skeleton layer is the interface between the application layer and the rest of the RMI system. 
This layer does not deal with specifics of any transport, but transmits data to the remote reference layer via the abstraction of marshal streams. Marshal streams employ a mechanism called pickling which enables Java objects to be transmitted between address spaces. Objects transmitted using the pickling system are passed by copy to the remote address space.」（第8頁左欄第28〜37行）
（仮訳）「Stub/Skeleton層
　スタブ/スケルトン層は、アプリケーション層と、RMIシステムの残りのものとの間のインターフェースです。この層は、いかなるトランスポートの特定の部分を扱うものではないが、marshal streamsを抽象化したものを経由してremote reference層にデータを送信します。marshal streamsは、Java objectsがアドレス・スペースの間を送信されるための、picklingと呼ばれるメカニズムを持ちます。picklingシステムを使って送信されるオブジェクトは、そのコピーがremote address spaceに渡されます。」
　
ｊ．「Dynamic Stub Loading
 In remote procedure call systems, client-side stub code must be generated and linked into a client before a remote procedure call can be done. This code may be either statically linked into the client or linked in at run-time via dynamic linking with libraries available locally or over a network file system. In either the case of static or dynamic linking, the specific code to handle an RPC must be available to the client machine in compiled form.
 This approach to code linking is static in that the stub code must be compiled and directly available to the client in binary-compatible form at compile time and at run time. Also with these systems, the stub code that the client uses is determined and fixed at compile time. Because of the static nature of the stub code available to clients in such systems, the code may not be the actual stub code that the client needs at run time, but perhaps the closest matched code that can be determined at compile time. For example in an RMI system, perhaps only a supertype (less specific form) of a more specific stub is available to the client at run-time. This code mismatch can lead to run-time errors if the client in fact needs a subtype (more specific form) of the stub that has been linked in at compile-time.
 Our approach solves this code mismatch by loading the exact stub code (in Java's architecture neutral bytecode format) at run-time to handle method invocations on a remote object. 
This mechanism, called dynamic stub loading, exploits the Java mechanism for downloading code. Dynamic stub loading is used only when code for a needed stub is not already available. 
The argument and return types specified in the remote interfaces are made available using the same mechanism. Loading arbitrary classes into clients or servers presents a potential security problem; this problem is addressed by requiring that a security manager check any classes downloaded for RMI. In this scheme, client-side stub code is generated from the remote object implementation class, and therefore supports the same set of remote interfaces as supported by the remote implementation. Such stub code resides on the server's host (or perhaps another location), and can be downloaded to the client on demand (if the correct stub code is not already available to the client). Stub code for a remote implementation could be generated on-the-fly at the remote site and shipped to the client or could be generated on the client-side from the list of remote interfaces supported by the remote implementation.」（第10頁左欄第21行〜右欄第20行）
（仮訳）「Dynamic Stub Loading
　リモート・プロシージャ・コール・システムでは、リモート・プロシージャ・コールが行われる前に、クライアント側スタブコードが生成され、クライアントにリンクされなければなりません。このコードは、クライアントへ静的にリンクされるかもしれないし、ローカルで、又は、ネットワーク・ファイル・システム上で、入手可能なライブラリを用いたダイナミック・リンキングを介して、実行時にリンクされるものかもしれません。静的あるいは動的なリンクのいずれの場合でも、RPCをハンドルする特定のコードは、コンパイルされた形式で、クライアント・マシンに利用可能でなくてはなりません。
　リンキングをコード化するこのアプローチは、静的なもので、その中では、スタブ・コードがコンパイルされるとともに、コンパイル時及び実行時に、バイナリ・コンパチブルな形式で、クライアントが直接利用可能でなければなりません。また、これらのシステムでは、クライアントが使用するスタブ・コードは、コンパイル時に決定され、固定されます。そのようなシステムでは、クライアントに利用可能なスタブ・コードのスタティックな性質のために、そのコードは、クライアントが実行時に必要とする、実際のスタブ・コードではないかもしれませんが、しかし、恐らく、コンパイル時に決定することのできる、最も一致したコードです。例えば、RMIシステムでは、恐らく、より特定のスタブのスーパータイプだけ(それほど特定でない形式)がランタイムのクライアントに利用可能です。クライアントが、実際に、コンパイル時にリンクされたスタブのサブタイプ(より特定の形式)を必要とする場合には、このコードのミスマッチは、ランタイム・エラーに結びつくかもしれません。
　私たちのアプローチは、実行時に、remote object上のメソッドのinvocationsをハンドルするために、正確なスタブ・コード(Javaのアーキテクチャーでは、neutral bytecodeフォーマット)をロードすることにより、このコードのミスマッチを解決します。dynamic stub loadingと呼ばれるこのメカニズムは、コードをダウンロードするためのJavaメカニズムを開発するものです。remote interfacesで指定される引数と返される型は、同じメカニズムを使用して、利用可能にされます。クライアントまたはサーバーに任意のクラスをロードすることは、潜在的なセキュリティ問題を示します;この問題は、セキュリティ・マネージャーがRMIのためにダウンロードされたどんなクラスもチェックすることを要求することにより解決されます。このスキームでは、クライアント側スタブ・コードがremote object implementation クラスから生成され、そして、それ故に、remote implementationにサポートされるようなremote interfacesの同じセットをサポートします。そのようなスタブコードはサーバーのホスト(あるいは恐らく別の位置)上に存在し、要求によって(正確なスタブコードがクライアントに既に利用可能でない場合)クライアントにダウンロードすることができます。remote implementationのためのスタブ・コードは、remote siteで大急ぎで生成し、そして、クライアントに送ることができるか、又は、remote implementationによってサポートされるremote interfacesのリストからクライアント側で生成することができます。」
　
　１）　引用記載ａ，ｂによると、remote method invocation システムは、Javaで分散オブジェクトをサポートするために設計されたもので、 Java バーチャルマシンの同種の環境を想定し、そして、そのために、システムはいつでも Java オブジェクトモデルに従うものである。
　
　２）　引用記載ｃ乃至ｅによると、remote objectをインプリメントするために、最初にそのオブジェクトのためのremote Interfacesが定義されている。そして、サーバにおいては、RMIランタイムにremote object implementationをエクスポートすることにより、implementation　objectをクライアントに遠隔にアクセス可能にしており、クライアントにおいては、remote objectクラスによって定義されるremote interfacesとまったく同じ集合を持つ、スタブ(代理)オブジェクトと対話する。
　
　３）　引用記載ｆ，ｇによると、クライアントがremote object上のメソッドを起動する際に、そのクライアントがオブジェクトへの名前の付けられたreferenceを得るために、remote objectへのreferenceが格納されたブートストラップ・ネーム・サーバが提供され、ブートストラップ・ネーム・サーバは、特定のホストとポートによって維持されている、その名前とオブジェクトの組みをリストするためのメソッドに基づき、Uniform Resource Locator (URL)を提供する。
　
　４）　引用記載ｈによると、RMIシステムは、（クライアント側）stub/（サーバ側）proxy，remote reference，Transport層からなっており、クライアントから遠隔のサーバー・オブジェクトまでのremote method invocationnは、RMIシステムの層を、クライアント側transportに、下へ移動し、その後、サーバ側のtransportを通って上に、サーバへと伝わっている。また、stubは、remote objectのremote interfacesのインプリメンテーションで、起動リクエストをremote referenceを経由してそのサーバー・オブジェクトへ転送するものである。
  　
　５）　引用記載ｊによると、クライアントは、Dynamic stub loadingと呼ばれるメカニズムによって、実行時に、remote object上のメソッドの起動をハンドルするために、スタブ・コードをロードしている。このスタブ・コードはサーバーのホスト上に存在し、要求によってクライアントにダウンロードすることができ、スタブ・コードは、remote site（サーバ）で生成し、そして、クライアントに送ることができる。
　
　以上を整理すると、刊行物には、次の発明（以下、引用発明という。）が記載されている。
　
　Java バーチャルマシンの同種の環境を想定し、Javaで分散オブジェクトをサポートするために設計された、remote method invocation(RMI) システムにおいて、
　remote objectをインプリメントするための、remote Interfacesが定義され、サーバにおいては、RMIランタイムにremote object implementationをエクスポートすることにより、implementation objectをクライアントに遠隔にアクセス可能にし、 クライアントにおいては、remote objectクラスによって定義されるremote interfacesとまったく同じ集合を持つスタブ(代理)オブジェクトと対話するものであり、
　ブートストラップ・ネーム・サーバは、クライアントがremote object上のメソッドを起動する際に用いるremote objectへの名前の付けられたreferenceを格納し、特定のホストとポートによって維持されているその名前とオブジェクトの組みをリストするためのメソッドに基いて、Uniform Resource Locator (URL)を提供し、
　クライアントは、Dynamic stub loadingと呼ばれるメカニズムによって、実行時に、remote object上のメソッドの起動をハンドルするための、remote objectのremote interfacesのインプリメンテーションであるスタブコードをremote objectが存在するサーバからロードするとともに、当該ロードしたスタブにより、起動リクエストをサーバー・オブジェクトへ転送し、remote objectを起動する、
　remote objectへのアクセスを提供する方法。
　
が記載されている。
　
４．対比
　以下に、本願発明と、引用発明とを対比する。
　１）引用発明は、ネットワーク・クライアント上で、複数の遠隔ネットワーク・サービスへのアクセスを提供する方法の一つである。
　
　２）引用発明と本願発明は、次の点で相当するものである。
　○　引用発明のクライアントと、本願発明のネットワーク・クライアント。
　○　引用発明のremote objectによって提供されるサービスと、本願発明の遠隔ネットワーク・サービス。
　○　引用発明のブートストラップ・ネーム・サーバと、本願発明の遠隔サービス・ディレクトリ。
　○　引用発明のremote objectが存在するサーバと、本願発明の遠隔サービス・プロバイダ。
　○　引用発明のremote objectへのreferenceは、特定のホストとポートによって維持されているサーバの名前とオブジェクトの組みをリストするための情報を含むものであるから、引用発明のremote objectへのreferenceと、本願発明のネットワーク・クライアントが使用可能な１組の遠隔ネットワーク・サービスのリスト。
　○　引用発明のUniform Resource Locator (URL)と、本願発明の遠隔サービス・プロバイダの位置。
　○　引用発明のスタブと、本願発明のクライアント・スタブ又はサービス・ハンドル。
 　
　３）引用発明は、クライアントにおける、複数の遠隔ネットワーク・サービスのうち少なくとも１つの遠隔ネットワーク・サービスへのアクセスへの要求、に基づいて遠隔ネットワーク・サービスへのアクセスを提供するものであり、前記要求の際に、要求しているか否かを決定することは当然に行われる処理である。
　
　したがって、本願発明と引用発明とは、次の点で一致し、相違する。
　
［一致点］
　ネットワーク・クライアント上で、複数の遠隔ネットワーク・サービスへのアクセスを提供する方法であって、
　クライアントで、前記複数の遠隔ネットワーク・サービスのうち少なくとも１つの遠隔ネットワーク・サービスへのアクセスを要求しているか否かを決定するステップと、
　クライアントの少なくとも１つの遠隔ネットワーク・サービスへのアクセスを要求に応答して、前記ネットワーク・クライアントが使用可能な１組の遠隔ネットワーク・サービスのリストを保持する遠隔サービス・ディレクトリを照会することにより、前記少なくとも１つの遠隔ネットワーク・サービスを提供するための特定の遠隔サービス・プロバイダの位置を突き止めるステップと、
　前記クライアントが、前記少なくとも１つの遠隔ネットワーク・サービスを要求時にアクセスすることができるように、前記特定の遠隔サービス・プロバイダに接続するための少なくとも１つのクライアント・スタブまたはサービス・ハンドルを、前記遠隔サービス・ディレクトリから前記ネットワーク・クライアントのメモリにダウンロードすることにより、前記少なくとも１つの遠隔ネットワーク・サービスを構成するステップと、
　前記クライアントに対し、構成済みの前記少なくとも１つの遠隔ネットワーク・サービスへのアクセスを提供するステップと、
　を含む、方法。
　
［相違点］
（相違点１）
　ネットワーク・クライアント上で、複数の遠隔ネットワーク・サービスへのアクセスを提供する対象、及び、複数の遠隔ネットワーク・サービスのうち少なくとも１つの遠隔ネットワーク・サービスへのアクセスを要求しているか否かを決定するものが、
　本願発明では、ネットワーク・クライアント上で実行されるアプリケーションであるが、引用発明では、ネットワーク・クライアントであり、それ以上詳細には言及されていない点。
　
（相違点２）
　遠隔ネットワーク・サービスを提供するための特定の遠隔サービス・プロバイダの位置を突き止めるステップ、遠隔ネットワーク・サービスを構成するステップ、遠隔ネットワーク・サービスへのアクセスを提供するステップ、を実行する主体が、
　本件発明では、ネットワーク・クライアントのユーザからの要求に応答して、前記ネットワーク・クライアントが、遠隔サービス・プロバイダから前記ネットワーク・クライアントのメモリにダウンロードした、前記複数の遠隔ネットワーク・サービスへのアクセスを提供するための実行可能コードから成る仮想環境マネージャであるのに対して、
　引用発明では、クライアントが、遠隔サービス・プロバイダの位置を突き止め、遠隔ネットワーク・サービスを構成し、遠隔ネットワーク・サービスへのアクセスを提供するものではあるが、クライアント上の何が主体となるかは具体的に言及されていない点。
　
５．相違点の検討
（１）相違点１
　引用発明のものも、Java バーチャルマシンにおいて動作するアプリケーションのために、前記遠隔ネットワーク・サービスへのアクセスを提供する仕組みを提供するものであることは明らかである。したがって、前記相違点１は、実質的な相違点ではない。
　
（２）相違点２
　引用発明において、前記各ステップが全体としてRMIシステムと呼ばれることが示すように、これらステップは、一体として、アプリケーションが遠隔ネットワーク・サービスへアクセスするための機能を、提供するものである。したがって、これらの各ステップの機能は、これらを統括する管理ソフトウェアであるマネージャと一体として、提供されるべく設計されたものと解される。したがって、引用発明は、本願発明の複数の遠隔ネットワーク・サービスへのアクセスを提供するための実行可能コードから成る仮想環境マネージャに相当する前記マネージャを念頭に置いたものであるといえる。
　そして、必要なソフトウェアをユーザ等の要求に応じてクライアントにダウンロードして実行することは、周知の事項（次の周知例1, 2参照）であるから、前記マネージャをユーザの要求に応じて、適宜ダウンロードするようにし、本願発明の如く構成することに、困難性は認められない。
　
　周知例１：「いよいよ始まる、５００ドルＰＣの熱い攻防！」，ＤＯＳ／Ｖ　ＰＯＷＥＲ　ＲＥＰＯＲＴ，株式会社インプレス発行，1996年4月号，page 60-67
　周知例２：「C/Sシステムの新インフラ，JavaとOLEの2本立てで整備進む」，日経オープンシステム，日経ＢＰ社発行，1996年4月，page 282-293
　
６．むすび
　以上のとおり、本願発明は、当業者が、刊行物１に記載の発明及び前記周知技術に基づいて容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許することができない。
　よって、結論のとおり審決する。