【事件の表示】
　特願２００３−３９０８５９「シグナリング方法並びにサーバ及びゲートウェイ端末」拒絶査定不服審判事件〔平成１７年　６月１６日出願公開、特開２００５−１５９４３１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　手続の経緯・本願発明
　本願は、平成１５年１１月２０日の出願であって、平成１８年８月２５日付けで拒絶査定がなされ、これに対し、平成１８年９月２８日に拒絶査定に対する審判請求がなされたものであり、その請求項１４に係る発明は、出願時の特許請求の範囲の請求項１４に記載された事項により特定される次のとおりのものである。（以下、「本願発明１４」という。）
　「【請求項１４】
　公衆電話交換網に接続された電話機宛てのインバイトリクエストを受信したならば、該インバイトリクエストをゲートウェイ端末に転送する転送手段を備えることを特徴とするサーバ。」
　
２　引用例に記載された発明
　これに対して、原審における、平成１８年１月１８日付けで通知した拒絶の理由に引用された、ＲＦＣ３２６１，Ｊ．Ｒｏｓｅｎｂｅｒｇ　ｅｔ．ａｌ．，ＳＩＰ：　Ｓｅｓｓｉｏｎ　Ｉｎｉｔｉａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ，Ｊｕｎｅ　２００２，ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３２６１．ｔｘｔ（以下、「引用例１」という。）には、次の事項が記載されている。
　記載事項１
　「Abstract
  This document describes Session Initiation Protocol (SIP), an application-layer control  (signaling) protocol for creating, modifying, and terminating sessions with one or more  participants. These sessions include Internet telephone calls, multimedia distribution, and  multimedia conferences.
  SIP invitations used to create sessions carry session descriptions that allow participants to agree  on a set of compatible media types. SIP makes use of elements called proxy servers to help route  requests to the user's current location, authenticate and authorize users for services, implement  provider call-routing policies, and provide features to users.  SIP also provides a registration  function that allows users to upload their current locations for use by proxy servers.  SIP runs on  top of several different transport protocols.」（Page 1）
　記載事項２
　「1 Introduction
  There are many applications of the Internet that require the creation and management of a  session, where a session is considered an exchange of data between an association of participants.   The implementation of these applications is complicated by the practices of participants: users  may move between endpoints, they may be addressable by multiple names, and they may  communicate in several different media - sometimes simultaneously.  Numerous protocols have  been authored that carry various forms of real-time multimedia session data such as voice, video, or text messages.  The Session Initiation Protocol (SIP) works in concert with these protocols by  enabling Internet endpoints (called user agents) to discover one another and to agree on a  characterization of a session they would like to share.  For locating prospective session  participants, and for other functions, SIP enables the creation of an infrastructure of network hosts  (called proxy servers) to which user agents can send registrations, invitations to sessions, and  other requests.  SIP is an agile, general-purpose tool for creating, modifying, and terminating  sessions that works independently of underlying transport protocols and without dependency on  the type of session that is being established.」（Page8-9）
　記載事項３
　「16.12 Summary of Proxy Route Processing
  In the absence of local policy to the contrary, the processing a proxy performs on a request containing a Route header field can be summarized in the following steps.
  1.  The proxy will inspect the Request-URI.  If it indicates a resource owned by this proxy,  the  proxy will replace it with the results of running a location service.  Otherwise, the proxy  will  not change the Request-URI.
  2.  The proxy will inspect the URI in the topmost Route header field value.  If it indicates this  proxy, the proxy removes it from the Route header field (this route node has been reached).
  3.  The proxy will forward the request to the resource indicated by the URI in the topmost  Route header field value or in the Request-URI if no Route header field is present.  The proxy  determines the address, port and transport to use when forwarding the request by applying the  procedures in [4] to that URI.
  If no strict-routing elements are encountered on the path of the request, the Request-URI will  always indicate the target of the request.](page118)
　記載事項４
　「17.2 Server Transaction
  The server transaction is responsible for the delivery of requests to the TU and the reliable  transmission of responses.  It accomplishes this through a state machine.  Server transactions are  created by the core when a request is received, and transaction handling is desired for that  request (this is not always the case).
  As with the client transactions, the state machine depends on whether the received request is an  INVITE request.」（Page 134）
　記載事項５
　「19.1 SIP and SIPS Uniform Resource Indicators
  A SIP or SIPS URI identifies a communications resource.  Like all URIs, SIP and SIPS URIs  may be placed in web pages, email messages, or printed literature.  They contain sufficient  information to initiate and maintain a communication session with the resource.
  Examples of communications resources include the following:
      o  a user of an online service
      o  an appearance on a multi-line phone
      o  a mailbox on a messaging system
      o  a PSTN number at a gateway service
      o  a group (such as sales or helpdesk) in an organization
  A SIPS URI specifies that the resource be contacted securely.  This means, in particular, that  TLS is to be used between the UAC and the domain that owns the URI.  From there, secure  communications are used to reach the user, where the specific security mechanism depends on the  policy of the domain.  Any resource described by a SIP URI can be upgraded to a SIPS URI  by just changing the scheme, if it is desired to communicate with that resource securely.」（Page148）
　記載事項６
　「19.1.3 Example SIP and SIPS URIs
  sip:alice@atlanta.com
  sip:alice:secretword@atlanta.com;transport=tcp
  sips:alice@atlanta.com?subject=project%20xpriority=urgent
  sip:+1-212-555-1212:1234@gateway.com;user=phone
  sips:1212@gateway.com
  sip:alice@192.0.2.4
  sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
  sip:alice;day=tuesday@atlanta.com
  The last sample URI above has a user field value of alice;day=tuesday.  The escaping rules  defined above allow a semicolon to appear unescaped in this field.  For the purposes of this  protocol, the field is opaque.  The structure of that value is only useful to the SIP element  responsible for the resource.」（Page 153）
　
３　対比  
　本願発明１４と引用例１に記載された発明を対比すると、
　両者は、「公衆電話交換網に接続された電話機宛てのインバイトリクエストを受信したならば、該インバイトリクエストをゲートウェイに転送する転送手段を備えることを特徴とするサーバ。」である点で一致し、
　次の点で相違する。
　ａ）ゲートウエイとして、本願発明１は「ゲートウエイ端末」を用いているのに対し、引用例１に記載された発明はそのように構成されていない点。
　
４　当審の判断
　上記相違点ａ）について検討する。
　ＩＰ電話通信の分野において、ゲートウエイとして、ゲートウエイ端末を用いることは、周知技術（特表２００３−５０９９７４号公報）であり、その周知技術を引用例１に記載された発明に適用することには格別の困難性が存在しないため、上記相違点ａ）は、当業者が容易に想到し得る程度のものである。
　そして、本願発明１４の作用効果も、引用例１及び周知技術から当業者が予測できる範囲のものである。
　
５　むすび
　したがって、本願発明１４は、引用例１に記載された発明に基づいて、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。