Obviousness

Obviousness under 35 U.S.C. § 103 requires an analysis of whether "the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains." This analysis is based on the Graham factors: (1) the scope and content of the prior art; (2) the differences between the prior art and the claims; (3) the level of ordinary skill in the pertinent art; and (4) secondary considerations of non-obviousness. While a "teaching, suggestion, or motivation" (TSM) to combine references is a factor, the Supreme Court in KSR International Co. v. Teleflex Inc. emphasized a more flexible "common sense" approach, stating that predictable results from combining familiar elements are often sufficient to prove obviousness.

The effective filing date of US 8,780,887 is October 29, 2010 (the priority date from Korean Patent Application No. 10-2010-0107107). Therefore, prior art references existing before this date are relevant.

Prior Art References (from the patent document):

• US20060130136A1 (Devarapalli): "Method and system for providing wireless data network interworking." Priority date: 2004-12-01.
• US7237260B2 (Matsushita Electric Industrial Co., Ltd.): "Method for dynamic selection for secure and firewall friendly communication protocols between multiple distributed modules." Priority date: 2003-07-08.
• US20070174436A1 (Maekawa): "Communication system, information processing system, information processing apparatus, tunnel management apparatus, information processing method, tunnel management method, and program." Priority date: 2004-01-30.
• KR20080059900A (한국과학기술정보연구원): "System level MPI communication method that supports private IP in grid environment through modified hole punching." Priority date: 2006-12-26.
• US20080307519A1 (Avaya Technology Llc): "Peer-to-peer network over a virtual private network." Priority date: 2007-06-06.
• US7609701B2 (Yang): "Communication using private IP addresses of local networks." Priority date: 2006-02-22.
• US20100235481A1 (Lantronix, Inc.): "Various methods and apparatuses for accessing networked devices without accessible addresses via virtual ip addresses." Priority date: 2007-10-24.
• US7843918B2 (Cisco Technology, Inc.): "Selectively forwarding traffic through tunnels in a computer network." Priority date: 2008-01-25.
• US20110082941A1 (Electronics And Telecommunications Research Institute): "Method of providing direct communication in internet protocol network." Priority date: 2009-10-06.
• US8014421B2 (Citrix Systems, Inc.): "Systems and methods for adjusting the maximum transmission unit by an intermediary device." Priority date: 2004-07-23.
• US8296437B2 (Logmein, Inc.): "Server-mediated setup and maintenance of peer-to-peer client computer communications." Priority date: 2005-12-29.
• B. Ford, Peer-to-Peer communication across network address translators, MIT Lab, Feb. 17, 2005, pp. 1-14. (Ford)
• P. Srisuresh, State of P2P communication across NATs, RFC 5128, RFC, Mar. 2008, pp. 1-32. (Srisuresh)

Elements of the Independent Claims and Corresponding Prior Art:

The independent claims (Claim 1 and Claim 6) of US 8,780,887 describe a method of network-based communication in a virtual network environment, focusing on direct communication between virtual tunnel routers (TRs) using virtual network prefix information and hole punching, orchestrated by a tunnel mapping controller.

• Virtual Tunnel Routers (Virtual TRs): The concept of "virtual routers" is known in the prior art. For example, US6765881B1 (Rajakarunanayake) discusses "virtual L2TP/VPN tunnel network" and MAC address detection for virtual routers. US20080307519A1 (Avaya Technology Llc) describes a "peer-to-peer network over a virtual private network" which would inherently involve routing functions in a virtualized environment. US20100235481A1 (Lantronix, Inc.) discusses "accessing networked devices without accessible addresses via virtual ip addresses," implying virtual routing.

• Tunnel Mapping Controller: While not explicitly named "tunnel mapping controller," the functionality of a central entity managing tunnels and network information in a virtualized environment is present in prior art. Maekawa (US20070174436A1) describes a "tunnel management apparatus" that manages communication systems. Rajakarunanayake (US6765881B1) mentions "tunnel switch network" where each tunnel switch is "preconfigured with a list of tunnels with which it is associated and a list of domains corresponding to each tunnel," suggesting a form of centralized tunnel management. Moreover, US20110082941A1 (ETRI, an inventor family related patent) discusses "a server to provide direct communication" in an IP network.

• Virtual Network Prefix Information: The use of virtual IP addresses and associated network prefixes for identifying virtual networks and terminals within them is also a known concept. The patent itself states, "A virtual IP has the meaning as an unchangeable identifier on the virtualized network, like identifying respective virtual networks and identifying terminals located in a virtual network area." The use of IP prefixes for network addressing is fundamental to IP networking. Private IP address ranges and their use in virtual networks are well-established. Azure documentation shows that virtual network subnets use standard naming conventions including prefixes.

• Hole Punching Message / Hole Punching: Peer-to-peer (P2P) communication across Network Address Translators (NATs) using "hole punching" techniques was a known method for establishing direct communication. Ford (2005) and Srisuresh (2008) are non-patent literature references explicitly discussing "Peer-to-Peer communication across network address translators." KR20080059900A (한국과학기술정보연구원) explicitly discloses a "System level MPI communication method that supports private IP in grid environment through modified hole punching." Hole punching for reclaiming unused space from a data container on a storage system is also known.

• Establishing a Tunnel: The establishment of tunnels between network entities, including virtual private network (VPN) tunnels over IP networks, is a well-known technology. US6636520B1 (Jason et al.) describes a "Method for establishing IPSEC tunnels." Rajakarunanayake (US6765881B1) also describes a "virtual private tunneling network" for communication across a VPN. The general concept of "tunneling" involves encapsulating packets.

• Direct Communication through an Established Tunnel: Once a tunnel is established between two network entities, direct communication through that tunnel is the inherent purpose and a widely understood function.

Obviousness Combinations:

A person having ordinary skill in the art (PHOSITA) in 2010 would have been familiar with virtual networking, NAT traversal techniques like hole punching, and the use of centralized management entities for network resources.

Combination 1: Devarapalli (US20060130136A1) + KR20080059900A (한국과학기술정보연구원) + Maekawa (US20070174436A1)

• Devarapalli could provide the context of a virtualized network environment for interworking wireless data networks, where direct communication between entities in different network segments would be desirable.
• KR20080059900A clearly teaches "system level MPI communication method that supports private IP in grid environment through modified hole punching" for direct communication. This reference directly addresses the "hole punching" aspect and its application in a network environment for direct communication using private IPs.
• Maekawa discloses a "tunnel management apparatus" which could provide the functionality of a "tunnel mapping controller" to manage tunnels and facilitate communication between virtual tunnel routers. Maekawa’s “tunnel management apparatus” managing tunnels between devices would motivate a PHOSITA to use this for managing the "virtual tunnel routers" envisioned in the present patent.

Motivation to combine: A PHOSITA would be motivated to combine these references to overcome the challenges of direct communication in network environments with NATs/firewalls, as explicitly stated in the background of US8780887. The goal of "providing a method of network-based communication in a virtual network environment capable of direction communication based on a virtual address" would drive the use of established hole punching techniques (from KR20080059900A) within a virtualized network managed by a tunnel management entity (from Maekawa) to achieve direct communication as envisioned in Devarapalli's interworking wireless data networks. The "virtual network prefix information" would be a natural extension of existing IP addressing schemes for managing addresses within such a virtualized environment. The combination would yield a predictable result: enabling direct communication between virtual routers in a virtual network, even through NATs/firewalls.

Combination 2: Rajakarunanayake (US6765881B1) + Ford (2005) / Srisuresh (2008)

• Rajakarunanayake teaches a "virtual L2TP/VPN tunnel network" and "tunnel switches" that are "preconfigured with a list of tunnels with which it is associated and a list of domains corresponding to each tunnel." This provides a clear teaching of virtual tunnel routers and a centralized management concept similar to a "tunnel mapping controller" that manages "virtual network prefix information" (implied by "list of domains" and tunnels).
• Ford (2005) and/or Srisuresh (2008) provide explicit teachings of "Peer-to-Peer communication across network address translators" using "hole punching." These references highlight the problems and solutions related to direct communication through NATs.

Motivation to combine: A PHOSITA, facing the known difficulties of direct communication across NATs in VPNs (as described in Rajakarunanayake), would be motivated to employ known NAT traversal techniques like "hole punching" (from Ford or Srisuresh). The "tunnel switches" in Rajakarunanayake that manage tunnels and domains could readily be adapted to orchestrate the hole punching process and provide the necessary virtual network prefix information to the virtual tunnel routers. The combination would address a known problem (NAT traversal in VPNs) with a known solution (hole punching) in a predictable way to enable direct communication between the virtual tunnel routers.

Conclusion on Obviousness:

Based on the analysis of the independent claims and the prior art references, the claimed methods in US 8,780,887 appear to be obvious under 35 U.S.C. § 103. The core elements of virtual tunnel routers, tunnel mapping controllers, virtual network prefix information, and hole punching for direct communication were all known in the art, and a PHOSITA would have been motivated to combine these known elements in predictable ways to achieve the desired outcome of direct communication in a virtual network environment.