ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 H04M 審判 査定不服 5項独立特許用件 特許、登録しない。 H04M |
|---|---|
| 管理番号 | 1148945 |
| 審判番号 | 不服2004-6757 |
| 総通号数 | 86 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2001-10-16 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2004-04-05 |
| 確定日 | 2006-12-06 |
| 事件の表示 | 特願2000-514447「メタデータベースのネットワークルーティング」拒絶査定不服審判事件〔平成11年 4月 8日国際公開、WO99/17517、平成13年10月16日国内公表、特表2001-518753〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
1.手続の経緯 本件出願は、1998年9月9日(優先権主張1997年9月30日、アメリカ合衆国)を国際出願日とする特許出願であって、平成15年12月26日付けで拒絶査定され、平成16年4月5日に審判請求がなされるとともに、同年4月30日に手続補正がなされたものである。 2.平成16年4月30日付け手続補正についての補正却下の決定 [補正却下の決定の結論] 平成16年4月30日付け手続補正を却下する。 [理由] (1)補正の内容 本件補正により、特許請求の範囲の請求項1が次のように補正された。 「【請求項1】 ネットワークサービスプロバイダにより維持される電話ネットワーク中で電話通話をルーティングする方法において、 (a)ネットワークルーティングポイントにおいて発呼者からの通話を受け入れ、 (b)通話をルーティングするために、ネットワークルーティングポイントに対するアクセスをネットワークサービスプロバイダのカスタマに提供し、 (c)通話に関係する識別子を、カスタマにより維持される、コード化され圧縮された(メタデータベース)情報システム中のデータベースエンティティと相互参照し、 (d)検索されたメタデータベースの情報に基づいて複数のカスタマ設備の選択された1つに通話をルーティングするために、ネットワークに対してルーティング宛先を提供するステップを含む方法。」 上記補正は、請求項1に記載された発明を特定するために必要な「メタデータベース情報システム」を、「コード化され圧縮された(メタデータベース)情報システム」と限定するものであるから、特許法第17条の2第4項第2号の特許請求の範囲の減縮を目的とするものに該当する。 そこで、本件補正後の請求項1に記載された事項により特定される発明(以下、「本願補正発明1」という。)が、特許出願の際に独立して特許を受けることができるものであるかについて、以下に検討する。 (2)引用発明 原査定の拒絶の理由に引用された米国特許第5,452,350号明細書(以下、「引用例」という。)には、図面と共に次の記載がある。 (ア) 「 With reference to FIG. 1, a diagrammatic/block diagram illustrates a subscriber call routing processing system used in accordance with the invention. The system is designed to allow a subscriber the ability to control routing of inbound N00 (currently area codes 800 or 900) telephone calls to a desired destination or resource based on the subscriber supplied routing criteria. This embodiment of the invention uses area codes 800 and 900 but can easily be extended to support any inbound service and any numbering plan. The system utilizes the facilities of the public switched telephone network (PSTN) 100 provided by one or more network carriers. These carriers include, for example, Sprint, MCI, AT&T and any local exchange carrier. A caller originates a call at a telephone 102 by dialing a number assigned to the particular subscriber. The call is connected to one of many carrier switch nodes 104 contained in the PSTN 100. The particular carrier switch node 104 is generally that in closest proximity to the caller 102. The carrier switch node 104 temporarily suspends the call setup process owing to the receipt of an N00 number and launches a routing query to the carrier's call routing database or service control point (SCP) 106. Based on the number dialed, a call translation process is invoked in the SCP 106 using routing trees configured for the subscriber. Within a subscriber network 112, there are included a plurality of resources, identified as Resources A, B and C, 108, 109 and 110, respectively, to which the calls should ultimately be routed. Conventionally the routing decision is made by the routing tree at the SCP 106. The SCP 106 controls switching in the carrier switch nodes 104 to connect the caller 102 to one of the resources 108-110. One example of such a conventional system is disclosed in Frauenthal et al., U.S. Pat. No. 4,737,983. 」(4欄34?68行) (イ) 「 In accordance with the invention, the subscriber network 112 also includes an advanced intelligent network (AIN) processor 114, a user terminal 116 and a customer database 118 for making routing decisions outside of the PSTN 100. The SCP 106 is modified so that instead of directly implementing decisions from its own routing tree, it launches a routing query to the AIN processor 114 in the subscriber network 112. Based on the information provided by the carrier within the routing query, information about the caller contained in the subscriber's customer database 118, information provided by the carrier's operation support system 120 about the status of the facilities, and information about the status of the resources 108-110 which may handle the call, the AIN processor 114 returns a resource identifier to the SCP 106. This response may also include data to be delivered to the resource by the PSTN 100. The SCP 106 receives the routing response from the AIN processor 114 and instructs the carrier switch node 104 to resume the call setup process and complete the call through the PSTN 100 to the designated subscriber resource 108, 109 or 110. 」(5欄1?22行) (ウ) 「The SCP 106 generates an inquiry message when a communication node is encountered in processing a call. Each inquiry message will contain: 1. Inquiry ID; 2. NPA-NXX-XXXX (or as many digits as available); 3. N00 Number; 4. Node Identifier; 5. Caller information (such as class of service); and 6. Caller entered digits. The subscriber network 112 generates a response message in response to an inquiry. The inquiry ID will be from the inquiry message received. Each response will contain: 1. Inquiry ID; 2. Select Code; 3. Destination tag; and 4. Caller information. When the session is established, initialization messages are exchanged identifying the communication node processed by node identifier. "NPA-NXX-XXXX" designates the area code, exchange and station of the caller. "N00 number" identifies the number dialed by the caller. "Node identifier" specifies a character string identifying a particular usage of the communication feature known to both the SCP 106 and the AIN processor 114. The "Select code" and "Destination tag" identify a particular routing choice. These are also known to both the SCP 106 and the AIN processor 114. 」(6欄47行?7欄7行) (エ) 「With reference to FIG. 5, a flow diagram further illustrates operation of the rule task 403 of FIG. 4. The main routine begins at a decision block 500 which determines if a routing inquiry has been received. If none is received, then no action is taken. Particularly, the routing query is received from the carrier SCP 106, see FIG. 1. If one is received, then a routing rule is selected at a block 502. The N00 Number dialed by the caller, contained in the routing query, is used to select the rule as defined when the rule is activated. The routing rule may already be in the memory of the AIN processor 114 or may have to be loaded into the memory from DASD storage 138. At a decision block 504, the caller identity, if available, is checked against the subscriber's customer database 118, see FIG. 1. If a match is found,then caller attributes contained in the customer database 118 are retrieved at a block 506 for use in routing the call. The routing rule is then implemented at a block 508. The routing rule is implemented at the block 508 by executing the call routing instructions 204, see FIG. 3, for the selected rule. Particularly, the caller attributes and call characteristics are compared to the various screening criteria specified by the subscriber in the call routing instructions. The screening criteria consists of lists of possible values of the caller attributes and call characteristics. Logical comparisons are performed between the actual values of the caller attributes and call characteristics for the particular call being processed and the values contained in the system variable list 200 and rule variable list 202. The format of each list depends on the caller attribute or call characteristics being screened. For example, if the originating area code, or NPA, of the caller is being compared, then the list would contain a sequence of possible NPA values. A successful logical comparison would occur if one of the values in the list equalled the originating NPA. In another example, if the time of day is being compared, then the list would contain two time values. A successful logical comparison occurs if the time of day the call is being made is between the two time values in the list. 」(13欄30行?14欄2行) 上記摘記事項(ア)には、公衆交換電話網(PSTN)100において、発呼者からの通話がキャリア交換ノード104の一つに接続され、該キャリア交換ノード104はサービス制御ポイント(SCP)106にクエリーを送出することが記載されている。 上記摘記事項(イ)には、サービス制御ポイント106が、加入者ネットワーク112のAINプロセッサ114にルーティングクエリーを送出し、AINプロセッサ114が、ルーティングクエリーの情報、加入者のカスタマデータベース118内の発呼者についての情報等に基づいて、リソースの識別子をSCP106に返信することが記載されている。 上記摘記事項(ウ)には、SCP106が、発呼者の電話番号や発呼者情報を含む照会メッセージを送信し、加入者ネットワーク112が宛先タグを含む応答を返信することが記載されている。 上記摘記事項(エ)には、カスタマデータベース118を用いて発呼者が特定され、発呼者が特定されればその属性が呼のルーティングに使用されることが記載されている。 これら記載事項において、公衆交換電話網100は、ネットワークサービスプロバイダにより維持される電話ネットワークであり、そのキャリア交換ノード104やサービス制御ポイント106は、ネットワークルーティングポイントである。また、発呼者の電話番号や発呼者情報は通話に関する識別子であるといえ、加入者ネットワーク112のAINプロセッサ114やカスタマデータベース118が加入者であるカスタマによって維持されることは、引用例の記載から明らかである。さらに、加入者のリソースはカスタマ設備であり、これらが複数備えられていることも明らかである。 したがって、引用例には、「ネットワークサービスプロバイダにより維持される電話ネットワークにおいて電話通話をルーティングする方法において、 (a)ネットワークルーティングポイントにおいて発呼者からの通話を受け入れ、 (b)通話をルーティングするために、ネットワークルーティングポイントに対するアクセスをネットワークサービスプロバイダのカスタマに提供し、 (c)通話に関係する識別子を、カスタマにより維持される、情報システム中のデータベースエンティティと相互参照し、 (d)検索されたデータベースの情報に基づいて複数のカスタマ設備の選択された1つに通話をルーティングするために、ネットワークに対してルーティング宛先を提供するステップを含む方法。」(以下、「引用発明」という。)が記載されている。 (3)補正後の発明との対比・判断 本願補正発明1と引用発明とを対比すると、両者は、 「電話通話をルーティングする方法において、 (a)ネットワークルーティングポイントにおいて発呼者からの通話を受け入れ、 (b)通話をルーティングするために、ネットワークルーティングポイントに対するアクセスをネットワークサービスプロバイダのカスタマに提供し、 (c)通話に関係する識別子を、カスタマにより維持される、情報システム中のデータベースエンティティと相互参照し、 (d)検索されたデータベースの情報に基づいて複数のカスタマ設備の選択された1つに通話をルーティングするために、ネットワークに対してルーティング宛先を提供するステップを含む方法。」である点で一致し、次の点で相違する。 (相違点1) 本願補正発明1は、「電話ネットワーク中で電話通話をルーティングする」のに対し、引用発明においては、この点が明らかでない点。 (相違点2) 本願発明の情報システムは、「コード化され圧縮された(メタデータベース)情報システム」であり、したがって、データベースがメタデータベースであるのに対し、引用発明の情報システムやデータベースについてはこのような点の明示がない点。 まず、相違点1について検討する。 本願補正発明1の「電話ネットワーク中で電話通話をルーティングする」ことの意味は必ずしも明らかではないが、本願明細書の段落【0011】に「その目的は特定の企業にアクセスされた電話通話が現に電話ネットワークを通して送られている間に企業がこれらの電話通話についてルーティング決定を行えるようにすることである。」と記載されている。一方、引用発明も、カスタマデータベースに基づいたルーティングが、電話ネットワークである公衆交換電話網のルーティングポイントにおいて行われるのであるから、この点に実質的な差異はない。 また、本願明細書の段落【0035】等に記載されるように、本願補正発明1が、カスタマによって維持されるデータベース(ローカルデータベース)303が電話ネットワーク中に置かれることを前提とするものであるとしても、検索速度を速めるためにデータベースを分散配置することは、通常行われていることであり、電話ネットワーク中にカスタマに関するデータベースを配置することも、特開昭62-98846号公報、特開平7-170546号公報、特表平8-510629号公報に記載されるように周知であるから、引用発明において、ネットワークルーティングポインタからのアクセスが容易なようにカスタマデータベースをネットワーク内に配置することは当業者が容易に想到し得ることである。 したがって、相違点1に係る本願補正発明1の構成を実現することは、当業者が容易に想到し得ることである。 次に、相違点2について検討する。本願明細書の段落【0034】に記載されるように、「データベースエンティティに関する選択された基準はコード化システム中の文字または数字により表され、データはコンパクトな表示方法のために非常に効率的な方法で記憶され、送信される」ようにデータベースシステムを構成することは、周知であるから、相違点2に係る本願補正発明の構成を得ることは当業者が容易になし得ることである。 また、本願補正発明1の効果も、引用発明及び周知技術に基づいて当業者が予測可能な範囲のものである。 したがって、本願補正発明1は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許出願の際に独立して特許を受けることができないものである。 (4)まとめ 以上のとおり、本件補正は、特許法第17条に2第5項で準用する同法第126条第5項の規定に違反するものであり、特許法第159条第1項で読み替えて準用する同法第53条第1項の規定により却下すべきものである。 3.本願発明についての検討 (1)本願発明 平成16年4月30日付けの手続補正は上記のように却下されたので、本件出願の請求項1に係る発明(以下、「本願発明1」という。)は、平成14年12月3日付けで補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項1に記載された次のとおりのものである。 「【請求項1】 ネットワークサービスプロバイダにより維持される電話ネットワーク中で電話通話をルーティングする方法において、 (a)ネットワークルーティングポイントにおいて発呼者からの通話を受け入れ、 (b)通話をルーティングするために、ネットワークルーティングポイントに対するアクセスをネットワークサービスプロバイダのカスタマに提供し、 (c)通話に関係する識別子を、カスタマにより維持されるメタデータベース情報システム中のデータベースエンティティと相互参照し、 (d)検索されたメタデータベースの情報に基づいて複数のカスタマ設備の選択された1つに通話をルーティングするために、ネットワークに対してルーティング宛先を提供するステップを含む方法。」 (2)引用発明 原査定の拒絶の理由に引用された引用例、及び、該引用例に記載された発明は、上記「2.(2)」に記載したとおりである。 (3)対比・判断 本願発明は、上記「2.」で検討した本願補正発明1の「コード化され圧縮された(メタデータベース)情報システム」を単なる「メタデータベース情報システム」としたものである。 そうすると、本願補正発明の構成要件を全て含み、さらに他の構成要件を付加したものに相当する本願補正発明1が、上記「2.」に説示したとおり、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、本願発明1も、同様の理由により、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。 (4)むすび 以上のとおり、本願発明1は、引用発明および周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができないものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2006-07-05 |
| 結審通知日 | 2006-07-11 |
| 審決日 | 2006-07-24 |
| 出願番号 | 特願2000-514447(P2000-514447) |
| 審決分類 |
P
1
8・
575-
Z
(H04M)
P 1 8・ 121- Z (H04M) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 稲葉 和生 |
| 特許庁審判長 |
廣岡 浩平 |
| 特許庁審判官 |
中木 努 宮下 誠 |
| 発明の名称 | メタデータベースのネットワークルーティング |
| 代理人 | 大崎 勝真 |
| 代理人 | 一入 章夫 |
| 代理人 | 川口 義雄 |
| 代理人 | 小野 誠 |