2021-012819

第２ 原査定の概要

原査定（令和３年５月２１日付け拒絶査定）の概要は次のとおりである。

本願請求項１９～３８に係る発明は、その出願前に日本国内又は外国において、頒布された以下の引用文献１～４に記載された発明に基いて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

（当審注： 少なくとも請求項１９，２９，３６に対する引用文献は、令和２年１０月２２日付けの拒絶理由通知書の請求項２１等と同様であり、引用文献１，２に限られるものと解される。）

第３ 本願発明

本願請求項１～３８に係る発明（請求項１９～３８に係る発明について、以下、それぞれ「本願発明１９」～「本願発明３８」という。）は、令和３年１月１９日に提出された手続補正書により補正された特許請求の範囲の請求項１～３８に記載された事項により特定される発明であり、それらのうちの本願発明１９，２９，３６は、それぞれ以下のとおりの発明である。

「【請求項１９】

ネットワークコントローラを備えるシステムであって、

前記ネットワークコントローラが、

情報をネットワークの複数のノードから受信することであって、前記複数のノードが第２のノードに対して運動している第１のノードを含むことと、

前記ネットワーク内のノード、各ノードにおいて利用可能なストレージ、および可能なリンクを表わすテーブルを、所定の期間にわたって前記受信した情報に基づいて生成することと、

前記ネットワークの一連のトポロジーを前記所定の期間にわたって前記生成したテーブルに基づいて決定することと、

クライアントデータ情報を１つ以上のクライアントデバイスから受信することであって、前記クライアントデータ情報がデータ量を含むことと、

前記決定した一連のトポロジーに関する複数のフローを、少なくとも前記データ量および各ノードで前記利用可能なストレージに基づいて決定することであって、前記複数のフローの各フローが、前記ネットワークを通るルーティング経路に関する１つ以上の要件を含むことと、

前記決定した一連のトポロジーに関するネットワーク構成のスケジュールを、前記決定した複数のフローに基づいて生成することと、

命令を前記ネットワークの前記複数のノードに送信して、ネットワーク構成の前記スケジュールを実現してクライアントデータを前記所定の期間にわたって送信することと、を行うように構成されている、システム。」

「【請求項２９】

方法であって、

ネットワークのネットワークコントローラにより、情報を前記ネットワークの複数のノードから受信することであって、前記複数のノードが、第２のノードに対して運動している第１のノードを含むことと、

前記ネットワークコントローラにより、前記ネットワーク内のノード、各ノードのストレージ容量、および可能なリンクを表わすテーブルを所定の期間にわたって前記受信した情報に基づいて生成することと、

前記ネットワークコントローラにより、前記ネットワークの一連のトポロジーを前記所定の期間にわたって、前記生成したテーブルに基づいて決定することと、

前記ネットワークコントローラにより、クライアントデータ情報を１つ以上のクライアントデバイスから受信することであって、前記クライアントデータ情報がデータ量を含むことと、

前記ネットワークコントローラにより、前記決定した一連のトポロジーに関する複数のフローを各ノードの少なくとも前記データ量および前記ストレージ容量に基づいて決定することであって、前記複数のフローの各フローが、前記ネットワークを通るルーティング経路に関する１つ以上の要件を含むことと、

前記ネットワークコントローラにより、前記決定した一連のトポロジーに関するネットワーク構成のスケジュールを、前記決定した複数のフローに基づいて生成することと、

前記ネットワークコントローラにより、命令を前記ネットワークの前記複数のノードに送信して、ネットワーク構成の前記スケジュールを実現してクライアントデータを前記所定の期間にわたって送信することと、を含む、方法。」

「【請求項３６】

プログラムのコンピュータ可読命令の格納先である非一時的な有形のコンピュータ可読記憶媒体であって、前記命令は、ネットワークのネットワークコントローラにより実行されると、前記ネットワークコントローラに方法を実行させ、前記方法は、

情報を前記ネットワークの複数のノードから受信することであって、前記複数のノードが、第２のノードに対して運動している第１のノードを含むことと、

前記ネットワーク内のノード、各ノードのストレージ容量、および可能なリンクを表わすテーブルを所定の期間にわたって前記受信した情報に基づいて生成することと、

前記ネットワークの一連のトポロジーを、前記所定の期間にわたって前記生成したテーブルに基づいて決定することと、

クライアントデータ情報を１つ以上のクライアントデバイスから受信することであって、前記クライアントデータ情報がデータ量を含むことと、

前記決定した一連のトポロジーに関する複数のフローを、少なくとも各ノードの前記データ量および前記ストレージ容量に基づいて決定することであって、前記複数のフローの各フローが、前記ネットワークを通るルーティング経路に関する１つ以上の要件を含むことと、

前記決定した一連のトポロジーに関するネットワーク構成のスケジュールを、前記決定した複数のフローに基づいて生成することと、

命令を前記ネットワークの前記複数のノードに送信して、ネットワーク構成の前記スケジュールを実現してクライアントデータを前記所定の期間にわたって送信することと、を含む、媒体。」

なお、本願発明２０～２８は本願発明１９を、本願発明３０～３５は本願発明２９を、本願発明３７，３８は本願発明３６を、それぞれ減縮した発明である。

第４ 引用文献、引用発明等

（１）引用文献１、引用発明

ア 原査定の拒絶の理由にて引用された引用文献１には、図面とともに次の事項が記載されている（下線は当審による。以下同様。）。

「[0035] With reference to FIG. 1, such a regenerative satellite payload comprises functional sections, including a payload control computer (PCC) 111, a receive section 113, a packet processing section 115, and a transmit section 117. Additionally, when the satellite network node includes inter-satellite links (ISLs), the regenerative payload will also include and ISL receive and transmit section for each inter-satellite link. As shown in FIG. 1, the satellite includes two inter-satellite links, ISL-1 and ISL-2, whereby the payload includes the ISL-1 receive section 119, the ISL-1 transmit section 121, the ISL-2 receives section 123 and the ISL-2 transmit section 125. For each receive antenna feed, the receive section includes an analog to digital converter (ADC), down-converter (DC), demodulator (DEMOD) and decoder (DECODER)--as depicted in FIG. 1, the ADC/DC 131a and DEMOD/DECODER 133a, the ADC/DC 131b and DEMOD/DECODER 133b and the ADC/DC 131n, and DEMOD/DECODER 133n. Similarly, for each transmit antenna feed, the transmit section includes an encoder (ENCODER), modulator (MOD), up-converter (UC) and digital to analog converter (DAC)--as depicted in FIG. 1, the ENCODER/MOD 135a and the UC/DAC 137a, the ENCODER/MOD 135b and the UC/DAC 137b, and the ENCODER/MOD 135n and the UC/DAC 137n. The ADC/DC translates and down-converts analog signals received by the respective receive antenna feed to generate a respective digital signal waveform. The packet processing section 115 includes a packet processor 147 that is configured to perform overall processing of the received packets and control of the input queuing section 141, the packet switch 143, and the output queuing section 145.」

（当審訳： [0035]図１を参照すると、そのような再生衛星ペイロードは、ペイロード制御コンピュータ(PCC)111、受信部113、パケット処理部115、及び送信部117を含む、機能区分から構成される。加えて、衛星ネットワークノードが衛星間リンク(ISLs)を含む場合、再生ペイロードはまた、各衛星間リンクのためのISL受信及び送信部を含む。図１に示すように、衛星は、２つの衛星間リンクISL-1及びISL2を含み、ここで、ペイロードは、ISL-1の受信部119、ISL-1の送信部121、ISL2の受信部123及びISL2の送信部125を含む。・・・（後略）・・・）

「[0038] FIG. 2A illustrates a diagram of a private software defined satellite network (SDSN) employing a logically centralized System Controller, in accordance with example embodiments of the present invention. With reference to FIG. 2A, the SDSN includes a number of satellites (e.g., S1, S2, S3), a Gateway (GWA), a Gateway (GWB), a number of consumer terminals (T1a, T1b, ..., T1n), a main corporate office enterprise terminal (T2), a remote office terminal (T3) of the same enterprise as the terminal T2, and the System Controller (SC). The enterprise terminal is connected to a number of user devices (D1, D2, ..., Dn) via a LAN 201. The gateways GWA and GWB, and the System Controller SC, connected to a global network 203 (e.g., the Internet). As would be appreciated by one of skill in the art, the SC in the gateways GWA and GWB may communicate over the network 203 via many different methods, such as a virtual private network (VPN), a dedicated wide area network (WAN), or the like. Further, the constellation of satellites S1, S2, S3 may comprise any combination of LEO, MEO, GEO satellites, and other airborne platforms (e.g., high-altitude platforms (HAPs) or other aircraft platforms), which may scale upwards to multiple additional satellites and/or other airborne platforms. As would also be appreciated by one of skill in the art, such a network may scale to larger sizes to include multiple enterprises, multiple communications service providers (such as Internet service providers (ISPs), each potentially with a multitude of its own respective customers), backhaul enterprise customers (such as backhaul links for providing backhaul services to 3G or 4G cellular network providers, hundreds or even thousands of direct small-scale customers (such as consumer Internet customers and small-office/home-office (SOHO) customers), etc. Additionally, these various terminals and gateways may be dispersed over a large geographic area within a given country or even spanning the globe across multiple countries. Accordingly, the SDSN must be configured to support potentially thousands of user terminals along with multiple gateway terminals dispersed throughout many facilities spread across vast geographical areas, where the data communications transmitted across the network comprise multiple different data traffic and priority classes associated with a wide variety of end-user applications (where the priorities of any given traffic class may vary depending on the source of specific packets--e.g., depending on the particular service level agreements (SLAs) of the enterprise customer from where the packets originated).」

（当審訳： [0038]図２Ａは、本発明の例示的な実施形態に従う、論理的に集中化されたシステムコントローラを用いたプライベートソフトウェア定義衛星ネットワーク(SDSN)の図を示す。図２Ａを参照すると、SDSNは多数の衛星(例えば、S1、S2、S3)、ゲートウェイ(GWA)、ゲートウェイ(GWB)、多数の消費者端末(T1a,T1b,…,T1n)、本社オフィスの企業端末(T2)、端末T2としての同じ企業のリモートオフィス端末(T3)、システムコントローラ(SC)を含んでいる。企業端末は、ＬＡＮ201を介してユーザ装置(D1、D2、…、Dn)の中に接続されている。ゲートウェイGWA及びGWB、及びシステムコントローラ(SC)、グローバルネットワーク203は、グローバルネットワーク203(例えば、インターネット)に接続されている。当業者には理解されるように、ゲートウェイGWA及びGWBにおけるSCは、仮想プライベートネットワーク(VPN)、広域ネットワーク(WAN)又は類似のもののような多くの異なる方法で、ネットワーク203上で通信することができる。更に、衛星S1、S2、S3の配置は、LEO、MEO、GEO衛星、及び他の空中プラットフォーム(例えば、高々度プラットフォーム(H APs)又は他の航空機プラットフォーム)の任意の組み合わせからなるものであってもよく、それは、複数の追加の衛星及び／又は空中プラットフォームへまで拡大されてもよい。これも当業者に理解されるように、そのようなネットワークは、複数の企業、複数の通信サービスプロバイダ(インターネットサービスプロバイダ(ISP)、潜在的には多数のそれ自身のそれぞれの顧客を伴う)、バックホール企業顧客(バックホールサービスを3G又は4Gの携帯電話ネットワークプロバイダに提供するためのバックホールリンクなど)、数百又は数千の直接的な小規模の顧客(消費者インターネット顧客及び小オフィス／家オフィス(SOHO顧客)のような)、などを含む大規模のサイズまで拡大され得る。加えて、これらの様々な端末及びゲートウェイは、所与の国内、又は複数の国にまたがる世界に及ぶ大規模な地理的領域にわたって分散されていてもよい。したがって、SDSNは、広大な地域にある多くの施設に分散している複数のゲートウェイ端末とともに、潜在的には数千のユーザ端末をサポートするように構成されなければならず、ここで、ネットワークで送信されるデータ通信は、複数の異なるデータトラフィック、及び多種多様なエンドユーザアプリケーションに関連する優先度クラスで構成される(あらゆる所与のトラフィッククラスの優先順位は、特定のパケットの送信元に依存して－－例えばパケットの送信元の企業顧客の特定のサービスレベル合意(SLA)に依存して、変化し得る)。）

「[0040] With further reference to FIG. 2A, a data routing example may entail a data transmission from the remote office terminal T3 (e.g., in London) to the corporate headquarters terminal T2 (e.g., in California). Such a data transmission may take a number of different paths. For example, the transmission may take a short path via the satellite S1 to the Gateway GWA, and then from the Gateway GWA (via the same satellite) to the terminal T2. At the time, however, suppose that the satellite S1 is unable to reach the terminal T2 and the satellite S2 can--where, in that case the routing decision would have to be made by the satellite S1 to forward the data packets via an ISL to the satellite S2 for transmission to the terminal T2. Additionally, network conditions may render certain paths less desirable and others in the context of meeting required SLAs for the data traffic--where, in that case further routing decisions must be made by respective network nodes to take into consideration such network link conditions. Typically, however, such routing decisions are made based on protocols such as shortest path routing whereby the required SLAs may not be met depending on network link conditions. Also, if a large number of terminals of a given region (e.g., terminals T1a, T1b, ..., T1n) are sending data via a shortest path route to a respective gateway (e.g., Gateway GWA), the respective links of that route may become saturated resulting in a degraded quality of service for the terminals, and also may result in inability to satisfy required SLAs for enterprise data traffic being carried via a route including the saturated links.

[0041] In accordance with example embodiments, therefore, the System Controller (SC) centrally monitors network conditions between all the routing nodes of the network, and provides routing information to each of the nodes to ensure that the network traffic satisfies all respective transmission requirements. According to one such embodiment, each of the network nodes periodically reports traffic and link conditions for each of its potential transmission links to other network nodes. For example, if the satellite S1 has a current ISL with the satellite S2, and also has uplink and downlink channels to the gateways GWA and GWB, will periodically report the traffic and other conditions (e.g., achievable throughput which may vary depending on such factors as weather conditions) for each of those links to the System Controller. Further, with respect to inter-satellite links, any given satellite may be configured with one or two, and upwards of four or more, ISL transceivers, whereby the satellite may communicate with other satellites within its orbital plane, or even with satellites and other airborne platforms of other orbital planes (e.g., the satellites S1, S2, S3 may be LEO satellites that can communicate via respective ISLs with the GEO satellite S4). While a satellite may be configured with multiple inter-satellite links, however, at any given time the satellite may only be in range with one other satellite, or perhaps no other satellites may be in range, and even when in range the ISL may be degraded based on other conditions. Further, in the case of LEO satellites, for example, based on the movement of the satellite through its orbit, at any given time the satellite will be in range of different satellites and different gateways depending on its then current orbital position.

[0042] Accordingly, in one embodiment, the satellite would report its link conditions to the System Controller at an appropriate time interval in view of the expected frequency or timing of significant link condition changes (e.g., a LEO satellite may be configured report link conditions to the SC at a higher frequency than a GEO satellite). Alternatively, considering that such airborne platforms are controlled and flown in a particular orbital pattern (e.g., a LEO travels through its orbit at a known rate of speed, and a HAP would typically be flown in a given circular, oval or figure eight orbit), the System Controller may be programmed with the required information of the orbit of each airborne network node to be able to determine the location of each such airborne node at any given point in time. Further, based on such management and control of the satellites, the System Controller would have system knowledge of the programmed/controlled management of each of its links (e.g., whether at any given time, one or more of the ISLs of a given satellite has been shut down by the management control). In such a case, each airborne network node may still periodically report link conditions to the System Controller, whereby the System Controller may use that information to confirm orbital positions and other managed link conditions when making routing determinations for the respective node. Also, the System Controller would need such reports in the case that, regardless of the position of an airborne network node, a particular link of that node may be malfunctioning (information that the SC could not determine simply based on the known position of the airborne node).

[0043] According to such embodiments, therefore, at any given point in time, the System Controller will have knowledge of the overall network topology, and available routes between the various network nodes. Within that overall network topology, the System Controller will also have knowledge of the link conditions between the network nodes. Further, also within that network topology the System Controller may be programmed with knowledge of the distribution/location of various customers and customer sites, and of the particular customer sites and types of data traffic being serviced by a given network node. Based on that knowledge of the distribution of each customers sites within the network, the System Controller can be programmed to apply the various SLAs of a given enterprise customer on a site-by-site basis in making route determinations for the different data types of that enterprise customer. For example, with reference again to FIG. 2A, where the terminal T2 represents a corporate site and the terminal T3 represents a remote site of a given enterprise customer, the System Controller would apply any required bandwidth levels when making route determinations for packets with either a source or destination address of T2 or T3 in order to satisfy the respective SLAs of that enterprise for its sites T2 and T3. According to further embodiments, in addition to the reported information regarding link status and traffic conditions for each link of a network node, each network node may also report actual measured data usage of its respective links, which can be broken down on various granularity levels. For example, in network node may report aggregate traffic bandwidth over a given link at a respective time or time period, or may break that measured traffic information down on the basis of source/destination addresses to provide an estimate of the bandwidth usage over that link on a customer basis. Based on such information regarding measured data usage of the respective links, for example, where a particular customer is only using a fraction of the potential bandwidth guaranteed to that customer based on an SLA, the System Controller may update its route determinations to apportion the unused bandwidth for other data traffic over the respective links. Then, should that customers data usage ramp up towards the bandwidth guaranteed by the respective SLA, the System Controller would update its route determinations to reapportion that bandwidth back to the customer. Such operations, however, would depend on the exact terms of the respective SLA (e.g., whether the SLA was for an absolute guaranteed bandwidth, or whether the SLA bandwidth was preemptable).

[0044] In order to implement the routing determinations of the System Controller, in accordance with example embodiments, the System Controller generates a routing or forwarding table for each network node. By way of example, for a given network node, this routing table would provide a table of next network node hop destinations for each of a multitude of potential network data packets transmitted to that node. More specifically, the table would include a listing of potential packets designated by a traffic type or quality of service (QoS) requirement, a source address, a destination address, and a next network node hop. Accordingly, for each packet received by the network node, node determines its traffic type or QoS, its source address and its destination address, and determines the next network node hop for that packet based on the respective entry in the forwarding table for that QoS, source address and destination address. In that regard, the traffic type or QoS indicates a priority level for the packet, and the source and destination addresses indicate a particular customer and customer site/terminal from where the packet originated and two where the packet is being transmitted. Accordingly, the System Controller designs the respective forwarding table for each network node, based on its knowledge of the overall network topology and link conditions, to ensure that all routes amongst the network nodes support the required data traffic loads and throughput on a customer-level basis. Further, as network topology and link conditions change, the System Controller continually updates routing/forwarding tables and periodically provides the updated tables to the respective network nodes.

[0045] As an example, assume that a particular enterprise customer SLA guarantees that customer 50 Mbps of bandwidth for voice over IP (VOIP) data traffic between its terminal site T2 and its terminal site T3, the System Controller will determine an available route/path between the terminal sites T2 and T3 that supports the required 50 Mbps, and provide route entries in the forwarding tables for each of the network nodes along that path to ensure that the customers data follows the determined path between the terminal sites T2 and T3. For example, at one point, the System Controller may determine that the path from the terminal site T3 to/from the Gateway GWA via the satellite S1, and then to/from the Gateway GWA to the terminal site T2 via the satellite S2, satisfies the required 50 Mbps SLA. Accordingly, for VoIP data traffic with source address of T3 and a destination address of T2, the System Controller would include (i) an entry in the forwarding table for the satellite S1 whereby the next hop is the Gateway GWA, (ii) an entry in the forwarding table for the Gateway GWA whereby the next hop is the satellite S2, and (iii) an entry in the forwarding table for the satellite S2 whereby the next hop is the terminal site T2. Similarly, for VoIP data traffic between the terminal sites T2 and T3 in the opposite direction, the System Controller would also include entries in the forwarding tables for the network nodes S2, GWA and S1 to cover that direction.

[0046] Further, at a subsequent time, assume that the link between the satellite S1 and the Gateway GWA becomes congested to the point where it can no longer support the required 50 Mbps (e.g., is during a peak time when the consumer terminals T1a, T1b, ..., T1n are active and the node GWA services the Internet access for those terminals). At this point, the node GWA and/or the node S1 will report this traffic congestion to the System Controller. The System Controller would then determine an alternate route for the VoIP traffic between the customer sites T2 and T3 that supports the required 50 Mbps. For example, instead of using the link from the node S1 to the node GWA, the System Controller may determine that an ISL link is available from the satellite node S1 to the satellite node S2. Accordingly, for the VoIP traffic between the terminal sites T2 and T3, the System Controller would update the forwarding table for each of the nodes S1 and S2 so that they directly route such data via the ISL link between them. According to a further embodiment, in the event that the System Controller cannot determine any path or route at a given point in time that is capable of supporting the required 50 Mbps SLA, the SC may divide the traffic into two 25 Mbps routes. For example, the SC may update the respective network node forwarding tables to provide a 25 Mbps route/path from the terminal site T3 to/from the Gateway GWA via the satellite S1, and then to/from the Gateway GWA to the terminal site T2 via the satellite S2, and another 25 Mbps route/path from the terminal site T3 to the satellite S1, from the satellite S1 to the satellite S2 via the respective ISL, and from the satellite S2 to the terminal site T2.

[0047] In accordance with further example embodiments, in addition to the route determination function (RDF) performed by the System Controller for generating the routing or forwarding tables for the respective network nodes, the SC for the performs a resource management or planning function (RPF). As part of the RPF, the SC obtains capacity information from NOC databases, such as resource capacity information and resource capacity allocation information. Then, based on the obtained capacity information, as part of a particular route determination for a path between two endpoint nodes (e.g., to meet an applicable SLA requirement of a particular customer), the SC performs capacity analysis for each of the links to determine that each link of the routing path has sufficient capacity to support the applicable SLA requirement. More specifically, with respect to a specific link being considered as a potential link for the route determination, the SC determines the available capacity for that link. For example, based on the capacity information obtained from the NOC database, the SC determines the available capacity of the link as the total capacity of that link minus the already allocated capacity of that link. In accordance with such embodiments, this RPF function of the System Controller provides yet another level of granularity for ensuring that the forwarding tables of each network node provide route information for a path between two endpoints that will support all network requirements (e.g., customer SLAs, global system routing constraints, etc.). Further, such routing determinations taking into account capacity planning are not currently performed in terrestrial networks, because such networks employee significantly wideband communication links that do not require such tight resource planning (as opposed to resource planner required for satellite capacity). Further, such routing determinations are not performed in systems that employee distributed routing determination functions (where the network nodes themselves do the route determinations), because the network nodes themselves do not possess such information regarding the overall resource capacity and allocations of the network. By way of example, given a particular SLA requirement for a path between two endpoints (e.g. a particular SLA for packet indications between to sites of an enterprise customer, such as a 50 Mbps packet throughput requirement), the System Controller will first eliminate all links where the available capacity is less than the required 50 Mbps. Then, once the SC determines a desired route for the path (and includes that route in the respective individual node Forwarding Tables), where all links are able to meet the required 50 Mbps, the SC then updates the database (or informs the NOC to update the database) to indicate that the 50 Mbps is now an additional current allocation of the respective links. Further, in the event that the SC is unable to find a complete path of links, where each think supports the required 50 Mbps, as discussed above, the SC can divide the SLA requirement of 50 Mbps into two separate 25 Mbps SLA requirements between the two endpoints. In that case, the SC will determine two different route paths between the two endpoints, where each route path will support subdivided SLA of 25 Mbps.」

（当審訳： [0040]さらに図２Ａを参照すると、データルーティングの例は、リモートオフィス端末T3(例えば、ロンドン)から本社端末T2(例えば、カリフォルニア)へのデータ送信を伴ってもよい。このようなデータ伝送は、多くの異なるパスを取り得る。例えば、送信は、衛星S1を介してゲートウェイGWAに至り、そして、ゲートウェイGWAから(同じ衛星を介して)端末T2に至る、短い絡路を使用し得る。しかし、その際、衛星S1が端末T2に到達できず、衛星S2が到達できると仮定する－－その場合、ルーティング決定は、衛星S1により、ISLを介してデータパケットを、端末T2への送信のために衛星S2に転送すると決定されなければならない。加えて、ネットワーク状態は、あるパスが他のものよりも望ましくない状態とし得る－－その場合、このようなネットワークリンクの状態を考慮に入れるために、さらなるルーティング決定がそれぞれのネットワークノードによって行われなければならない。しかしながら、そのようなルーティング決定は、典型的には、ネットワークリンクの状態に依存して、要求されたSLAが満たされない、最短パスルーティングプロトコルのようなプロトコルに基づいて行われる。また、所与の領域における多数の端末(例えば、端子T1a,T1b,…,T1n)が、最短パスルートを介してそれぞれのゲートウェイ(例えば、ゲートウェイGWA)にデータを送信していると、そのルートのそれぞれのリンクは、端末のためのサービスの品質が低下するほどに飽和した状態になるかもしれず、飽和リンクを含むルートを介して搬送される企業データトラフィックに必要なSLAを満足できない結果にもなりかねない。

[0041]それゆえ、本発明の一実施形態によれば、システムコントローラ(SC)が、ネットワークの全てのルーティングノード間のネットワーク状態を集中監視し、ネットワークトラフィックがそれぞれの送信要件を満たすことを保証するために、各ノードにルーティング情報を提供する。1つのそのような実施形態によれば、ネットワークの各ノードは、それの他のネットワークノードへの潜在的な伝送リンクの各々について、リンク及びトラフィック状態を周期的に報告する。例えば、もし衛星S1が、衛星S2との現時点のISLを有しており、また、ゲートウェイGWA及びGWBにアップリンク及びダウンリンクチャネルを有するならば、システムコントローラに、これらのリンクの各々についてのトラフィック及び他の状態（例えば気象状況のような要因に依存して異なり得る達成可能スループット）を周期的に報告する。更に、衛星間リンクに関しては、任意の所与の衛星は１個又は２個、及び４個又はそれ以上のISL送受信機とともに構成され得る、ここで、衛星は、その軌道内の他の衛星と、又は他の軌道の他の空中プラットフォームと通信し得る(例えば、衛星S1、S2、S3は、GEO衛星S4とISLを介して通信可能なLEO衛星であり得る)。衛星は、複数の衛星間リンクとともに構成することができるが、任意の所与の時間に、衛星は、他の１つの衛星との範囲内のみに存在し得る、又は、おそらく他の衛星が範囲内にない可能性があり、範囲内にある場合でも、ISLが他の条件によって悪化し得る。更に、LEO衛星の場合には、例えば、その軌道を通る衛星の動きに基づいて、任意の所与の時間に、その衛星は、その軌道位置に依存して異なる衛星及び異なるゲートウェイの範囲内にあるだろう。

[0042]したがって、1つの実施形態では、衛星は、予期される大幅なリンク状態の変化の周波数又はタイミングを考慮して、適切な時間間隔でそのリンクの状態をシステムコントローラに報告するだろう(例えば、LEO衛星はGEO衛星よりも高い周波数でリンク状態をSCに報告するように構成されてもよい)。代替的に、このような空中プラットフォームは、特定の軌道パターン内で制御されて飛行させられる(例えば、LEOは、既知の速度でその軌道を通って移動し、HAPは、典型的には、所与の円形、楕円形又は８の字型の軌道で飛行させられるだろう)ことを考慮すると、システムコントローラは、任意の所与の時点においてそれぞれのこのような空中ノードの位置を決定することができるようにするため、各空中ネットワークノードの軌道についての必要な情報をもってプログラムされ得る。更に、衛星のような管理及び制御に基づいて、システムコントローラは、プログラムされた／制御された各リンクの管理についてのシステム知識を有するだろう(例えば、任意の所与の時点で、所与の衛星のISLの1つ又はそれ以上が、管理制御によって停止されたかどうか)。このような場合でもなお、各空中ネットワークノードは、リンク状態をシステムコントローラに周期的に報告してもよく、システムコントローラは、それぞれのノードのためのルーティング決定を行うときに、その情報を用いて軌道位置及び他の管理されたリンク状態を確認し得る。また、システムコントローラは、空中ネットワークノードの位置にかかわらず、そのノードの特定のリンクが正常に動作していないかもしれない場合では、そのようなレポートを必要とするだろう(SCが、空中ノードの既知の位置に基づいて単純には決定することができない情報)。

[0043]このような実施形態によれば、それゆえ、任意の所与の時点において、システムコントローラは、全体的なネットワークトポロジー、及び様々なネットワークノード間の利用可能なルートの知識を有することになるだろう。全体的なネットワークトポロジー内では、システムコントローラは、ネットワークノードの間のリンク状態の知識も有することになるだろう。また、ネットワークトポロジー内ではまた、システムコントローラは、様々な顧客及び顧客サイトの分布／位置の知識、並びに、特定の顧客サイト及び所与のネットワークノードによってサービスされているデータトラフィックのタイプタイプの知識を用いてプログラムされてもよい。ネットワーク内の各顧客サイトの分布の知識に基づいて、システムコントローラは、その企業顧客の異なるタイプのデータのためのルート決定を行う上で、サイトバイサイトの原則で、所与の企業顧客の様々なSLAを適用するようにプログラムされることができる。例えば、端末T2が会社サイトを表し、端末T3が所与の企業顧客のリモートサイトを表す図２Ａを再び参照すると、システムコントローラは、送信元アドレス又は宛先アドレスのいずれかであるT2又はT3のパケットのためのルート決定を行う際に、その企業のサイトT2及びT3に対するそれぞれのSLAを満足するために、何らかの必要な帯域幅レベルを適用するだろう。さらなる実施形態によれば、ネットワークノードの各リンクに関するリンク状態及びトラフィック条件に関する報告された情報に加えて、各ネットワークノードは、それぞれのリンクの実際に測定されたデータの使用は、様々な粒度レベルに分解することができる)を報告することもできる。例えば、ネットワークノード内のそれぞれの時点もしくは期間で、所与のリンク上のトラフィックの総計帯域幅を報告することができるか、又は測定されたトラフィック情報を顧客ベースに基づいて、リンク上の帯域幅使用量の推定値を提供するために、送信元／宛先アドレスに基づいて破壊がもたらされる。各リンクの測定されたデータの使用状況に関する情報に基づいて、例えば、特定の顧客は、SLAに基づくことを顧客に保証可能な帯域幅の一部だけを使用している場合、システムコントローラは、そのルート決定を更新する各リンク上のデータトラフィックのための未使用帯域幅を配分することができる。次いで、各SLAによって保証される帯域幅に向かって増加する消費者データ使用でなければ、システムコントローラは、帯域幅を再配分する顧客に戻すようにルート決定を更新するであろう。このような動作は、しかしながら、各SLA(例えば、絶対的に保証された帯域幅があったかどうか、あるいはSLA帯域は、プリエンプト可能であったかどうか)の正確な表現に依存することになる。

[0044]システムコントローラのルーティングの決定を実現するために、例示的実施形態によれば、システムコントローラは、各ネットワークノードのルーティング又はフォワーディングテーブルを生成する。一例として、所与のネットワークのノードについては、このルーティングテーブルには、そのノードに送信された候補ネットワークの多数のデータパケットのそれぞれについて、次のネットワークノードのホップ先のテーブルを提供する。より具体的には、そのテーブルは、トラフィックのタイプ又はサービス品質(QoS)要求、送信元アドレス、宛先アドレス、及び次のネットワークノードホップの品質で指定されたパケットのリストを有する。したがって、ネットワークノードによって受信された各パケットについて、ノードは、それのトラフィックタイプ又はQoS、ソースアドレス及び宛先アドレスを決定し、そのパケットのための次のネットワークノードのホップを、そのQoS、ソースアドレス及び宛先アドレスのためのフォワーディングテーブルにおけるそれぞれのエントリに基づいて決定する。この点に関して、トラフィックタイプ又はQoSは、パケットに関する優先レベル示し、ソースアドレス及び宛先アドレスは、パケットが発生し、パケットが送信されている特定の顧客及び顧客サイト／端末を示す。したがって、システムコントローラは、ネットワークノード間の全てのルートが、顧客レベルに基づいて必要なデータトラフィック負荷及びスループットをサポートすることを確実にするために、全体的なネットワークトポロジー及びリンク状態の知識に基づいて、各々のネットワークノードのための各フォワーディングテーブルを設計する。さらに、ネットワークトポロジー及びリンク状態が変化すると、システムコントローラは、ルーティング／フォワーディングテーブルを連続的に更新し、周期的にそれぞれのネットワークノードに更新されたテーブルを提供する。

[0045]一例として、特定の企業顧客のSLAが、その端末サイトT2及びその端末サイトT3との間でVoice over IP(VoIP)データトラフィック上での音声のための帯域幅が50Mbpsをその顧客に保証すると仮定すると、システムコントローラは、必要とされる50Mbpsをサポートする端末サイトT2とT3との間の利用可能なルート／パスを決定し、顧客データが端末T2とT3との間の決定されたルートに従うことを確実にするために、そのルートに沿ったネットワークノードの各々についてフォワーディングテーブルにおけるルートエントリを提供する。例えば、ある点では、システムコントローラは、端末サイトT3からゲートウェイGWAへの／ゲートウェイGWAから端末サイトT3への衛星S1を介したルートが、その後、端末サイトT2からゲートウェイGWAへの／ゲートウェイGWAから端末サイトT2への衛星S2を介したルートが、必要とされる50MbpsのSLAを満たしていると決定し得る。したがって、T3のソースアドレス及びT2の宛先アドレスを有するVoIPデータトラフィックのために、システムコントローラは、(i)衛星S1のための、次のホップがゲートウェイGWAであるフォワーディングテーブルのエントリ、(ii)ゲートウェイGWAのための、次のホップが衛星S2であるフォワーディングテーブルのエントリ、及び、(iii)衛星S2のための、次のホップが端末T2であるフォワーディングテーブルのエントリ、を含めるだろう。同様に、端末T2及びT3との間の反対方向のVoIPデータトラフィックのために、システムコントローラはまた、その方向をカバーするために、ネットワークノードS2、GBA及びS1についてのフォワーディングテーブル内にエントリを含めるだろう。

[0046]さらに、後の時点で、衛星S1及びゲートウェイGWAの間のリンクが、もはや必要な50Mbpsをサポートすることができない程度まで輻輳するようになる(例えば、消費者端末T1a,T1b,…,T1nがアクティブであり、ノードGWAがこれらの端末に対してインターネットアクセスサービスを提供する際、ピーク時間中にある)と仮定する。この時点で、ノードGWA及び／又はノードS1はこの輻輳をシステムコントローラに報告するだろう。その後、システムコントローラは、必要な50Mbpsをサポートする顧客サイトT2とT3との間のVoIPトラフィックのための代わりのルートを決定する。例えば、ノードS1からノードGWAへのリンクを用いる代わりに、システムコントローラは、衛星ノードS1からノードS2へのISLリンクが利用できると決定し得る。したがって、端子T2とT3との間のVoIPトラフィックのために、システムコントローラは、ノードS1及びS2の各々についてフォワーディングテーブルを更新することで、それらは、それらの間のISLリンクを介して、そのようなデータを直接ルーティングする。さらなる実施形態によれば、システムコントローラは、必要とされる50Mbpsをサポートすることを可能にする所与の時点で任意のパス又はルートを決定することができない場合に、SCは、トラフィックを２つの25Mbpsのルートに分割することができる。例えば、SCは、各ネットワークノードのフォワーディングテーブルを更新するための衛星S1を介して、ゲートウェイGWAへ端末位置T3から、ゲートウェイGWAへ衛星S2を介して端末位置T2と、位置T3から衛星S1を他の25Mbpsのルート／パス、衛星S1から各ISLを介して衛星S2は衛星S2から終端T2まで25Mbpsのルート／パスを提供することができる。

[0047]さらに別の実施形態によれば、システムコントローラによって実行される、それぞれのネットワークノードのためのルーティング又はフォワーディングテーブルを生成するためのルート決定機能(RDF)に加えて、SCは、リソース管理又はプランニング機能(RPF)を行う。RPFの一部として、SCは、NOCデータベースから、リソースキャパシティ情報及びリソースキャパシティ割当情報などのキャパシティ情報を取得する。そして、取得したキャパシティ情報に基づいて、２つのエンドポイントノード間のパスのための特定のルート決定の一部として(例えば、特定の顧客の適用可能なSLA要件を満足するために)、SCはリンクごとのキャパシティ分析を実行し、ルーティングパスの各リンクは、適用可能なSLA要求をサポートするのに十分なキャパシティを有することを決定する。より具体的には、ルート決定のための潜在的なリンクとして考慮されている特定のリンクに関して、SCは、そのリンクのための利用可能なキャパシティを決定する。例えば、NOCデータベースから取得したキャパシティ情報に基づいて、SCは、既に割り当てられたリンクのキャパシティを差し引いたそのリンクの全キャパシティとして、そのリンクの利用可能なキャパシティを決定する。そのような実施形態によれば、システムコントローラのこのRPF機能は、各ネットワークノードのフォワーディングテーブルが、全てのネットワークの要求(例えば、顧客のSLA、グローバルシステムルーティング制約等)をサポートするであろう２つのエンドポイントの間のパスに関するルート情報を提供することを確実にするための、さらに別のレベルの細かさを提供する。さらに、キャパシティプランニングを考慮に入れたそのようなルーティング決定は、地上ネットワークにおいては、そのようなネットワークはそのようなタイトなリソースプランニングを(衛星のキャパシティについて必要とされるリソースプランナーとは対照的に)必要としない、かなり広帯域の通信リンクを使用するため、現在行われていない。さらに、そのようなルーティング決定は、分散型ルーティング決定機能(ネットワークノードが、自身にルート決定を行う)を採用したシステムでは、ネットワークノード自体は、全体的なリソースキャパシティ及びネットワークの割り当てに関するそのような情報を有していないため、行われていない。例として、２つのエンドポイント間パスに特定のSLA要件が与えられると(50Mbpsパケットスループット要件など、企業顧客の２つサイト間のパケット指示のための特定のSLA)、システムコントローラはまず、利用可能なキャパシティが50Mbps以下であるすべてのリンクを排除するだろう。そして、SCがそのパスのための、全てのリンクが必要とされる50Mbpsを満たすことができる所望のルートを決定する(及びそれぞれの個別のノードのフォワーディングテーブルにそのルートを含める)と、SCは、データベースを更新し(又はNOCにデータベースを更新するように通知する)、50Mbpsがそれぞれのリンクに対する追加の現在の割り当てであることを示す。さらに、SCが、各リンクが上述の必要な50Mbpsをサポートするリンクの完全なパスを見つけることができない場合、SCは、50MbpsのSLA要件を、その２つのエンドポイント間の２つの25MbpsのSLA要件に分割することができる。この場合、SCは、各ルートパスが25Mbpsの区分されたSLAをサポートする、２つのエンドポイント間の２つの異なるルートパスを決定する。）

（図２Ａ）「

［図：0001385059000001.jpg］

」

イ 上記アの記載から、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。

「システムコントローラを用いたプライベートソフトウェア定義衛星ネットワーク(SDSN)であって、

多数の衛星(例えば、S1、S2、S3)、ゲートウェイ(GWA)、ゲートウェイ(GWB)、多数の消費者端末(T1a,T1b,…,T1n)、本社オフィスの企業端末(T2)、端末T2としての同じ企業のリモートオフィス端末(T3)、システムコントローラ(SC)を含み、

衛星S1、S2、S3の配置は、LEO、MEO、GEO衛星、及び他の空中プラットフォーム(例えば、高々度プラットフォーム(HAPs)又は他の航空機プラットフォーム)の任意の組み合わせからなるものであり、

ネットワークの各ノードは、それの他のネットワークノードへの潜在的な伝送リンクの各々について、リンク及びトラフィック状態を周期的に報告し、例えば、もし衛星S1が、衛星S2との現時点の衛星間リンクを有しており、また、ゲートウェイGWA及びGWBにアップリンク及びダウンリンクチャネルを有するならば、システムコントローラに、これらのリンクの各々についてのトラフィック及び達成可能スループットを周期的に報告し、

続きを表示（全13行）

衛星は、複数の衛星間リンクとともに構成することができるが、任意の所与の時間に、衛星は、他の１つの衛星との範囲内のみに存在し得る、又は、おそらく他の衛星が範囲内にない可能性があり、

任意の所与の時点において、システムコントローラは、全体的なネットワークトポロジー、及び様々なネットワークノード間の利用可能なルートの知識を有することになり、全体的なネットワークトポロジー内では、システムコントローラは、ネットワークノードの間のリンク状態の知識も有することになり、

システムコントローラは、送信元アドレス又は宛先アドレスのいずれかであるT2又はT3のパケットのためのルート決定を行う際に、その企業のサイトT2及びT3に対するそれぞれのサービスレベル合意(SLA)を満足するために、何らかの必要な帯域幅レベルを適用し、

システムコントローラのルーティングの決定を実現するために、システムコントローラは、各ネットワークノードのルーティング又はフォワーディングテーブルを生成し、より具体的には、そのテーブルは、トラフィックのタイプ又はサービス品質(QoS)要求、送信元アドレス、宛先アドレス、及び次のネットワークノードホップの品質で指定されたパケットのリストを有し、したがって、ネットワークノードによって受信された各パケットについて、ノードは、それのトラフィックタイプ又はQoS、ソースアドレス及び宛先アドレスを決定し、そのパケットのための次のネットワークノードのホップを、そのQoS、ソースアドレス及び宛先アドレスのためのフォワーディングテーブルにおけるそれぞれのエントリに基づいて決定し、

システムコントローラは、ネットワークノード間の全てのルートが、顧客レベルに基づいて必要なデータトラフィック負荷及びスループットをサポートすることを確実にするために、全体的なネットワークトポロジー及びリンク状態の知識に基づいて、各々のネットワークノードのための各フォワーディングテーブルを設計し、さらに、ネットワークトポロジー及びリンク状態が変化すると、システムコントローラは、ルーティング／フォワーディングテーブルを連続的に更新し、周期的にそれぞれのネットワークノードに更新されたテーブルを提供し、

一例として、特定の企業顧客のSLAが、その端末サイトT2及びその端末サイトT3との間でVoice over IP(VoIP)データトラフィック上での音声のための帯域幅が50Mbpsをその顧客に保証すると仮定すると、システムコントローラは、必要とされる50Mbpsをサポートする端末サイトT2とT3との間の利用可能なルート／パスを決定し、顧客データが端末T2とT3との間の決定されたルートに従うことを確実にするために、そのルートに沿ったネットワークノードの各々についてフォワーディングテーブルにおけるルートエントリを提供し、

SCは、リソース管理又はプランニング機能(RPF)を行い、RPFの一部として、SCは、リソースキャパシティ情報及びリソースキャパシティ割当情報などのキャパシティ情報を取得し、そして、取得したキャパシティ情報に基づいて、２つのエンドポイントノード間のパスのための特定のルート決定の一部として(例えば、特定の顧客の適用可能なSLA要件を満足するために)、SCはリンクごとのキャパシティ分析を実行し、ルーティングパスの各リンクは、適用可能なSLA要求をサポートするのに十分なキャパシティを有することを決定し、

例として、２つのエンドポイント間パスに特定のSLA要件が与えられると、システムコントローラはまず、利用可能なキャパシティが50Mbps以下であるすべてのリンクを排除し、そして、SCがそのパスのための、全てのリンクが必要とされる50Mbpsを満たすことができる所望のルートを決定すると、SCが、データベースを更新し、50Mbpsがそれぞれのリンクに対する追加の現在の割り当てであることを示す、

プライベートソフトウェア定義衛星ネットワーク(SDSN)。」

（２）引用文献２

原査定の拒絶の理由にて引用された引用文献２には、図面とともに次の事項が記載されている。

「【０００１】

【発明の属する技術分野】本発明は、衛星と、センタ機能をもつ１局（以下センタ局とする）と、個々のユーザ等の端末と接続する多数の遠隔局（以下端末局とする）とで構成されるスター状型衛星通信システムにおける多元接続方式に係り、特に端末局からセンタ局への多元接続方式の１つであるランダムアクセス方式の改良に関する。」

「【０００５】予約方式は、基本的には、データの送信に先立って何らかの方法でタイムスロットの予約を行なうものである。この予約方式には、大別すると、予約の仕方によって、予約用パケットを用いてタイムスロット予約を行なうexplicitな予約方式と、予約用パケットを用いず一度衝突なくデータパケットの送達に成功すると、それ以降のフレームの同一タイムスロットを自動的に予約されたとみなすimplicitな予約方式の２種類がある。一般的に予約方式というとexplicitな予約方式を指し、本発明も、このexplicitな予約方式に係わっている。

【０００６】従来のexplicitな予約方式の例を図１２、図１３に示す。

【０００７】図１２は、タイムスロット予約のため、端末局がスロット付ランダムアクセス方式で最初に予約要求専用パケットを送信し、センタ局が該パケットを衝突なく正常に受信出来れば、予約要求に従いタイムスロット割り当てを行なうとともに、該タイムスロット割り当て情報を該パケット送信端末局に通知し、該端末局はこの割り当てられたタイムスロットを用いてデータを送信する通信手順を図示したものである。」

「【図１２】

［図：0001385059000002.jpg］

」

第５ 対比・判断

１ 本願発明１９について

（１）対比

ア 本願発明１９と引用発明とを対比すると、次のことがいえる。

（ア）引用発明の「システムコントローラ」、「プライベートソフトウェア定義衛星ネットワーク(SDSN)」は、それぞれ、本願発明１９の「ネットワークコントローラ」、「システム」に相当する。また、引用発明と本願発明１９とは、後述する相違点は別として「ネットワークコントローラを備えるシステム」である点で一致している。

（イ）引用発明の

「ネットワークの各ノードは、それの他のネットワークノードへの潜在的な伝送リンクの各々について、リンク及びトラフィック状態を周期的に報告し、例えば、もし衛星S1が、衛星S2との現時点の衛星間リンク(ISL)を有しており、また、ゲートウェイGWA及びGWBにアップリンク及びダウンリンクチャネルを有するならば、システムコントローラに、これらのリンクの各々についてのトラフィック及び達成可能スループットを周期的に報告し、

衛星は、複数の衛星間リンクとともに構成することができるが、任意の所与の時間に、衛星は、他の１つの衛星との範囲内のみに存在し得る、又は、おそらく他の衛星が範囲内にない可能性があり、

任意の所与の時点において、システムコントローラは、全体的なネットワークトポロジー、及び様々なネットワークノード間の利用可能なルートの知識を有することになり、全体的なネットワークトポロジー内では、システムコントローラは、ネットワークノードの間のリンク状態の知識も有することにな」る

との構成において、各「衛星」は、「ネットワークの各ノード」であり、「任意の所与の時間に、衛星は、他の１つの衛星との範囲内のみに存在し得る、又は、おそらく他の衛星が範囲内にない可能性があ」るから、「衛星」としての「ノード」は複数であり、ある「ノード」に対して運動している他の「ノード」を含むといえる。

また、「リンクの各々についてのトラフィック及び達成可能スループット」は、特定の「ノード」が「システムコントローラ」に「周期的に報告」する、すなわち「システムコントローラ」が受信する、当該「ノード」と他の「ノード」との間の、「衛星間リンク」等の「リンク」についての情報を示すものであって、本願発明１９の「情報」に相当する。

よって、引用発明の「システムコントローラ」は、本願発明１９の

「情報をネットワークの複数のノードから受信することであって、前記複数のノードが第２のノードに対して運動している第１のノードを含むこと」

に相当する動作を行うように構成されているといえる。

（ウ）上記（イ）で述べた引用発明の構成において、ある「衛星」について「他の１つの衛星との範囲内のみに存在し得る」場合は、「衛星間リンク」が可能であり、「他の衛星が範囲内にない」る場合は、「衛星間リンク」が可能でないといえる。そして、それが可能であるか否かは、「周期的に報告」される内容により示され、「システムコントローラ」は、上記「衛星」及び可能な「衛星間リンク」を表す各データを、所定の期間（ある「衛星」が「他の１つの衛星との範囲内のみに存在し得る」状態にある期間や「他の衛星が範囲内にない」状態にある期間を含み得る）にわたってなされた「周期的」な「報告」に基づいて生成することが明らかであって、ここで、当該各データと本願発明１９の「テーブル」とは、「データ群」である点で共通している。

また、引用発明の「システムコントローラ」が「有することにな」る、「全体的なネットワークトポロジー」の「知識」は、ある「衛星」について「他の１つの衛星との範囲内のみに存在し得る」状態や「他の衛星が範囲内にない」状態を含む一連のものとして、上記の各データに基づいて決定されることが明らかである。

そして、引用発明の「衛星間リンク」、「ネットワークトポロジー」は、それぞれ、本願発明１９の「リンク」、「トポロジー」に相当する。

よって、引用発明と、本願発明１９の「前記ネットワークコントローラ」が行う

「前記ネットワーク内のノード、各ノードにおいて利用可能なストレージ、および可能なリンクを表わすテーブルを、所定の期間にわたって前記受信した情報に基づいて生成することと、

前記ネットワークの一連のトポロジーを前記所定の期間にわたって前記生成したテーブルに基づいて決定すること」

とは、

「前記ネットワーク内のノード、および可能なリンクを表わすデータ群を、所定の期間にわたって前記受信した情報に基づいて生成することと、

前記ネットワークの一連のトポロジーを前記所定の期間にわたって前記生成したデータ群に基づいて決定すること」

である点で共通している。

（エ）引用発明は、

「一例として、特定の企業顧客のSLAが、その端末サイトT2及びその端末サイトT3との間でVoice over IP(VoIP)データトラフィック上での音声のための帯域幅が50Mbpsをその顧客に保証すると仮定すると、システムコントローラは、必要とされる50Mbpsをサポートする端末サイトT2とT3との間の利用可能なルート／パスを決定し、顧客データが端末T2とT3との間の決定されたルートに従うことを確実にするために、そのルートに沿ったネットワークノードの各々についてフォワーディングテーブルにおけるルートエントリを提供」する

との動作を行うものである。

当該動作において、「システムコントローラ」が、少なくとも「端末サイトT2」及び「端末サイトT3」のいずれかから発せられる、それらの発信元及び発信先の「VoIP」の通信に係る信号を受けて、すなわち、当該通信を示す情報を受信して、「必要とされる50Mbpsをサポートする端末サイトT2とT3との間の利用可能なルート／パスを決定」することが明らかであり、ここで、「端末サイトT2」及び「端末サイトT3」のいずれかは、本願発明１９の「クライアントデバイス」に相当し、上記情報は、本願発明１９の「クライアントデータ情報」に相当する。

また、上記信号は、例えば「50Mbps」である「音声のための帯域幅」に関連しているということができ、当該「音声のための帯域幅」は、「VoIP」に必要な通信速度、すなわち単位時間当たりのデータ量であって、本願発明１９の「データ量」に相当する。

よって、引用発明と、本願発明１９の「前記ネットワークコントローラ」が行う

「クライアントデータ情報を１つ以上のクライアントデバイスから受信することであって、前記クライアントデータ情報がデータ量を含むこと」

とは、

「クライアントデータ情報を１つ以上のクライアントデバイスから受信することであって、前記クライアントデータ情報がデータ量に関連していること」

である点で共通している。

（オ）上記（エ）で述べた引用発明の動作において、「システムコントローラ」が、「必要とされる50Mbpsをサポートする端末サイトT2とT3との間の利用可能なルート／パスを決定」することは、引用発明の「全体的なネットワークトポロジー」に関する、「端末サイトT2とT3との間」の「VoIP」の通信の流れ、すなわちフローを、「音声のための帯域幅」に基づいて決定することであり、当該通信の流れは、「ルート／パス」に関する「必要とされる50Mbpsをサポートする」との要件を含むといえる。ここで、「ルート／パス」は、本願発明１９の「前記ネットワークを通るルーティング経路」に相当する。

また、「顧客データが端末T2とT3との間の決定されたルートに従うことを確実にするために、そのルートに沿ったネットワークノードの各々についてフォワーディングテーブルにおけるルートエントリを提供」することは、上記「全体的なネットワークトポロジー」に関する、「T2」、「T3」及びそれらの間の「ルートに沿ったネットワークノードの各々」からなるネットワーク構成について、（当該ネットワーク構成を使用する）スケジュールを、「端末サイトT2とT3との間」の「VoIP」の上記通信の流れに基づいて生成し、「ネットワークノードの各々」に「フォワーディングテーブルにおけるルートエントリを提供」して、ネットワーク構成の前記スケジュールを実現して「T2」又は「T3」の「VoIP」に係るデータ、すなわちクライアントデータを、上記（ウ）で検討した所定の期間にわたって送信することであるといえる。ここで、「ルートエントリを提供」することは、本願発明１９の「命令」を「送信」することに相当する。

よって、引用発明と、本願発明１９の「前記ネットワークコントローラ」が行う

「前記決定した一連のトポロジーに関する複数のフローを、少なくとも前記データ量および各ノードで前記利用可能なストレージに基づいて決定することであって、前記複数のフローの各フローが、前記ネットワークを通るルーティング経路に関する１つ以上の要件を含むことと、

前記決定した一連のトポロジーに関するネットワーク構成のスケジュールを、前記決定した複数のフローに基づいて生成することと、

命令を前記ネットワークの前記複数のノードに送信して、ネットワーク構成の前記スケジュールを実現してクライアントデータを前記所定の期間にわたって送信すること」

とは、

「前記決定した一連のトポロジーに関するフローを、少なくとも前記データ量に基づいて決定することであって、前記複数のフローの各フローが、前記ネットワークを通るルーティング経路に関する１つ以上の要件を含むことと、

前記決定した一連のトポロジーに関するネットワーク構成のスケジュールを、前記決定したフローに基づいて生成することと、

命令を前記ネットワークの前記複数のノードに送信して、ネットワーク構成の前記スケジュールを実現してクライアントデータを前記所定の期間にわたって送信すること」

である点で共通している。

（カ）引用発明は、

「SCは、リソース管理又はプランニング機能(RPF)を行い、RPFの一部として、SCは、リソースキャパシティ情報及びリソースキャパシティ割当情報などのキャパシティ情報を取得し、そして、取得したキャパシティ情報に基づいて、２つのエンドポイントノード間のパスのための特定のルート決定の一部として(例えば、特定の顧客の適用可能なSLA要件を満足するために)、SCはリンクごとのキャパシティ分析を実行し、ルーティングパスの各リンクは、適用可能なSLA要求をサポートするのに十分なキャパシティを有することを決定し、

例として、２つのエンドポイント間パスに特定のSLA要件が与えられると、システムコントローラはまず、利用可能なキャパシティが50Mbps以下であるすべてのリンクを排除し、そして、SCがそのパスのための、全てのリンクが必要とされる50Mbpsを満たすことができる所望のルートを決定すると、SCが、データベースを更新し、50Mbpsがそれぞれのリンクに対する追加の現在の割り当てであることを示す」

ものである。

ここで、「リソースキャパシティ情報」は、「リンク」が、「十分なキャパシティを有する」か否かを示すものであり、例えば「利用可能なキャパシティが50Mbps以下である」といった、「リンク」の通信速度の情報であることが明らかであるから、引用発明の「リソースキャパシティ」は、本願発明１９の「各ノードにおいて利用可能なストレージ」に相当するとはいえない。

イ 上記アから、本願発明１９と引用発明との間には、次の一致点、相違点があるといえる。

（一致点）

「ネットワークコントローラを備えるシステムであって、

前記ネットワークコントローラが、

情報をネットワークの複数のノードから受信することであって、前記複数のノードが第２のノードに対して運動している第１のノードを含むことと、

前記ネットワーク内のノード、および可能なリンクを表わすデータ群を、所定の期間にわたって前記受信した情報に基づいて生成することと、

前記ネットワークの一連のトポロジーを前記所定の期間にわたって前記生成したデータ群に基づいて決定することと、

クライアントデータ情報を１つ以上のクライアントデバイスから受信することであって、前記クライアントデータ情報がデータ量に関連していることと、

前記決定した一連のトポロジーに関するフローを、少なくとも前記データ量に基づいて決定することであって、前記フローが、前記ネットワークを通るルーティング経路に関する１つ以上の要件を含むことと、

前記決定した一連のトポロジーに関するネットワーク構成のスケジュールを、前記決定したフローに基づいて生成することと、

命令を前記ネットワークの前記複数のノードに送信して、ネットワーク構成の前記スケジュールを実現してクライアントデータを前記所定の期間にわたって送信することと、を行うように構成されている、システム。」

（相違点１）

本願発明１９では、「前記ネットワークコントローラ」が「所定の期間にわたって前記受信した情報に基づいて生成する」対象が「表す」ものに、「各ノードにおいて利用可能なストレージ」が含まれ、かつ、「前記ネットワークコントローラ」が「決定する」「フロー」が、「前記データ量」に加えて「各ノードで前記利用可能なストレージ」にも基づくものであるのに対して、引用発明では、「システムコントローラ」が「報告」に基づいて生成する対象に「各ノードにおいて利用可能なストレージ」を表すものは含まれず、また、「システムコントローラ」が決定する「端末サイトT2とT3との間」の「VoIP」の通信の流れは、「各ノードにおいて前記利用可能なストレージ」に基づくものではない点。

（相違点２）

本願発明１９の「前記ネットワークコントローラ」が「所定の期間にわたって前記受信した情報に基づいて生成する」対象のデータ形式は、「テーブル」であるのに対して、引用発明の「システムコントローラ」が「報告」に基づいて生成する対象のデータ形式は、「テーブル」であると特定されるものではない点。

（相違点３）

本願発明１９の「データ量」は、「クライアントデバイスから受信する」「クライアントデータ情報」が「含む」ものであるのに対して、引用発明の「音声のための帯域幅」は、「端末サイトT2」及び「端末サイトT3」のいずれかから受信するものに含まれると特定されるものではない点。

（相違点４）

本願発明１９の「フロー」は、「複数」であるのに対して、引用発明の「端末サイトT2とT3との間」の「VoIP」の通信の流れは、「複数」であると特定されるものではない点。

（２）判断

そこで、まず相違点１について検討する。

ネットワークのトポロジーの経時的な変化等に対応するために、ネットワークの各ノードを経由した通信のフローを決定する際、各時点における可能なノードに加えて、各ノードにおいて利用可能なストレージにも基づいてフローを決定することは、引用文献１～４のいずれにも記載されておらず、本願の優先日前において周知技術であったともいえない。

よって、他の相違点について判断するまでもなく、本願発明１９は、当業者であっても、引用発明及び引用文献２～４に記載された発明に基づいて容易に発明をすることができたものであるとはいえない。

２ 本願発明２０～３８について

本願発明２９，３６は、それぞれ本願発明１９に対応する方法、媒体の発明であって、いずれも本願発明１９に対応する発明特定事項を含んでいる。

また、本願発明２０～２８は本願発明１９を、本願発明３０～３５は本願発明２９を、本願発明３７，３８は本願発明３６を、それぞれ減縮した発明である。

そうすると、本願発明２０～３８も、本願発明１９と同様の理由により、当業者であっても引用発明及び引用文献２～４に記載された発明に基づいて容易に発明をすることができたものであるとはいえない。

第６ むすび

以上のとおり、請求項１９～３８に係る発明は、当業者が引用文献１～４に記載された発明に基づいて容易に発明をすることができたものではない。したがって、原査定の理由によっては、本願を拒絶することはできない。

また、他に本願を拒絶すべき理由を発見しない。

よって、結論のとおり審決する。