Obviousness

To analyze the obviousness of US patent 7188180 under 35 U.S.C. § 103, we must identify combinations of prior art that would have made the claimed invention obvious to a person having ordinary skill in the art (POSITA) at the time of the invention (priority date: 1998-10-30).

The patent's detailed description provides extensive background on existing secure communication techniques and a specific "secure mechanism for communicating over the internet using a unique two-layer encryption format and special TARP routers" (hereinafter referred to as the "TARP system"). This TARP system, described from column 5, line 11, through column 8, line 59, and further detailed in subsequent sections regarding IP hopping (IHOP), serves as a foundational component that the claimed "present invention" aims to enhance or enable more easily.

A POSITA in network security and software development at the time of the invention would have been familiar with:

• Secure communication protocols: Virtual Private Networks (VPNs), encryption (symmetric/asymmetric keys), and tunneling methods.
• Anonymity techniques: Proxy servers, Chaum's mixes, onion routing (ZKS Anonymous IP Protocol) as explicitly detailed in the patent's background.
• Network infrastructure: Internet Protocol (IP) routing, Domain Name System (DNS), and the function of firewalls.
• Software usability and deployment: The general desire for user-friendly interfaces and automated software installation/configuration.

The independent claims of US7188180 largely focus on methods for establishing or enabling secure communication (specifically a VPN using the underlying TARP-like mechanisms), providing a secure domain name service, and encapsulating application traffic for firewall traversal.

Here are combinations of prior art that would render the independent claims obvious:

Obviousness of Claims 1 and 23 (One-Click/No-Click VPN Setup)

• Prior Art Combination: The detailed description of the TARP system as provided in the patent (Col. 5, line 11 - Col. 8, line 59, and Col. 9, line 10 - Col. 10, line 23), which includes secure communication via agile routing, IP agility (address hopping with transmit/receive tables), two-layer encryption, and decoy data, in combination with general principles of user interface design and software deployment methods.
• Differences from Prior Art: Claims 1 and 23 distinguish themselves by enabling a secure communication mode without requiring a user to enter cryptographic information, often via a single action like selecting an icon or entering a command. It also includes automatically loading the secure communication software module if it's not present.
• Motivation for Combination: A POSITA would be highly motivated to simplify the user experience and deployment of complex secure communication systems, such as the described TARP system or any VPN. Automating the setup of a secure link through a "one-click" or "no-click" interface (like an icon selection) is a standard design goal for user-friendly software. Furthermore, automatically checking for and loading necessary software modules from a network address is a common and obvious practice in software distribution and client-server applications (e.g., web plugins, auto-updaters) to ensure functionality and minimize user setup burden. This combination would lead to greater adoption and seamless integration of secure communication capabilities.

Obviousness of Claim 13 (Application-Layer Encapsulation for Firewall Traversal)

• Prior Art Combination: The TARP system (as described above), which provides a secure communication link, in combination with the explicitly recognized firewall technology (Col. 4, line 43) and common knowledge in network security regarding firewall traversal techniques and protocol encapsulation. The patent itself highlights that the invention "more easily penetrates the firewall" by "working on top of existing protocols (i.e., UDP, ICMP and TCP)" (Col. 9, lines 46-51).
• Differences from Prior Art: Claim 13 involves a client computer sending an information packet with VPN data inserted into the payload at the application layer, allowing it to traverse a firewall. This packet is then received at the kernel layer of the server's operating system, where it's determined if it contains VPN data. The server replies with a kernel-layer modified packet containing VPN information in its payload.
• Motivation for Combination: Faced with the acknowledged challenge of firewalls blocking desired network traffic (as noted in the patent's background, Col. 4, lines 43-59), a POSITA in network security would be motivated to devise methods for secure communication to circumvent these barriers. Encapsulating secure communication data within the payload of standard, commonly permitted protocols (like UDP, TCP, or ICMP) at the application layer is an obvious technique to make the traffic appear innocuous to firewalls. Processing these encapsulated packets at a lower layer, such as the kernel layer, on the receiving side is a well-known architectural approach for efficient and transparent network protocol implementation. The symmetric act of the server sending a reply packet similarly modified at the kernel layer is a logical extension for establishing two-way secure communication.

Obviousness of Claims 21 and 22 (Secure Domain Name Service with Non-Standard TLDs)

• Prior Art Combination: The conventional Domain Name Service (DNS) (illustrated as prior art in FIG. 25) in combination with the TARP system's existing internal address mapping mechanisms, such as "TARP addresses" correlated via "Lookup Tables (LUT)" (Col. 6, lines 10-15), and general principles of securing network services and creating dedicated namespaces.
• Differences from Prior Art: Claims 21 and 22 describe a Secure Domain Name Service (SDNS) specifically for "secure, non-standard top-level domain names" (e.g., .scom, .sorg, .snet). The SDNS includes a portal for authenticating queries and a database for storing these secure network addresses. Claim 21 further describes a computer system where a hyperlink establishes a VPN, then sends these non-standard TLDs over the VPN to the SDNS.
• Motivation for Combination: A POSITA designing or implementing a secure network (like the TARP system or any VPN) would be motivated to provide a corresponding secure and segregated naming resolution service. The standard DNS system, while fundamental, is known to have security limitations. Creating an "SDNS" with "non-standard TLDs" offers a dedicated, controlled, and potentially more secure namespace that resolves only within the secure network context, enhancing overall security, privacy, and control. The TARP system already utilizes internal "TARP addresses" and "LUTs," demonstrating a recognition of the need for internal address mapping. Formalizing this into a "Secure Domain Name Service" that incorporates authentication (a standard security practice for any critical network service) and a dedicated database for these addresses would be an obvious and desirable architectural extension for a secure virtual network. The integration with a hyperlink for ease of VPN establishment (as discussed for Claims 1 and 23) further reinforces the motivation for such a combined system.

In conclusion, the innovations described in the independent claims of US7188180, while useful, represent an obvious combination of the background TARP secure communication system (or generic VPNs/secure communication methods) with known principles of user interface design, software deployment, firewall traversal, and secure naming services, all driven by clear motivations to enhance usability, connectivity, and security for virtual private networks.