Open Source 4 Open Markets

Open Source for Open Markets is an industry group which was created to counter the those in the industry which would seek to take ownership of methodologies and technologies which are clearly open source and where prior art was prevalent prior to the patent filings.

In order to bring to light what we believe are illegitimate patents OS4OM has initiated legal challenges to those patents which we believe were granted without full analysis by the US Patent Office and has begun a public marketing campaign to prevent organizations from attempting to patent other methods and/or technology which are clearly open source and have prior art associated with them.

-------------------------------------------------------------------------------------------------------------------

In this release OS4OM is discussing a patent filed by Fatpipe Networks India Ltd.  The patent number is 7,269,143.  The full text can be found here: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&d=PTXT&s1=Fatpipe&OS=Fatpipe&RS=Fatpipe

The patent was filed in October 2002.  The patent asserts the following:  A controller is provided for increasing bandwidth between a local area network ("LAN") and other networks by using multiple routers on the given LAN. Data packets are multiplexed between the routers using a novel variation on the standard SYN packet synchronization protocol, and other components. On receiving data destined for an external network, the controller or gateway computer will direct the data to the appropriate router. In addition to providing higher speed connections, the invention provides better fault tolerance in the form of redundant connections from the originating LAN to a wide area network such as the Internet.

These are quite broad assertions, however when looking at the claims themselves, this Abstract does not live up to what is actually covered in the claims themselves.

The primary claim is the most important to review here and this is where we start.  The primary claim states that “A controller for combining routers to provide increased concurrency in external access to a computer network, the controller comprising: a router identifier for identifying at least two routers for a LAN, each identified router having its own IP address and its own physical address; a router selector for selecting between identified routers, the router selector making its selection in a manner which increases concurrent operation of identified routers by sending subsequent data requests and their corresponding responses through the selected router, thereby helping provide improved external access to the computer network through identified routers; and a SYN modifier which provides modified SYN requests that contain the address of an identified router, each response specifying the address of an identified router which was selected by the router selector.”

There are two significant issues with this claim, the first is that it describes making changes to a routers address, in this case it is referring to both the IP and physical (or MAC) address of the router, as specified in the claim.   The second issue is that in order to modify an address in conjunction with a “SYN” identifier one must be talking about modifying a packet.  The problem is that one CAN NOT modify a physical (or MAC) address within a packet.  This is not possible.  We could stop right here as the patent is clearly not useable, however there are other issues.

Even if one were to believe that the claim was only referring to modifying the IP address within a SYN packet, not both (even though this is clearly identified in the claim) the claim further states that each response packet must specify the address of an identified router.  This is also a major problem as if you were to modify a SYN packet so that its response was set to an identified router, as stated in this claim, the response packet would never get back to the controller.  The response would simply be dropped once it got back to the “identified router”.

What Fatpipe is claiming here is that they are changing the “response” i.e. the source IP address (and possibly MAC address) to that of the identified router.  The problem here is that when the remote node responds it will simply send the packets back to the “identified router” and thus the traffic will simply be dropped and will not get back to the controller.

These issue with modifying physical (or MAC) addresses within packets is a continuing problem throughout this patent application.  Claims 2, 3, and 5 all refer to specifying a physical address within a SYN packet.  All of these references are completely inaccurate and not usable.

Finally, claim 8 states that the controller should redirect responses from the local area network server using the “least loaded router”.  This is a significant problem in that if one were to choose the “least loaded router” for the return traffic you will then have session persistence issues with the remote client, i.e. the remote client (or ISP, or firewall appliance) will terminate the session as it would see this traffic coming from a different IP address then from which it was initiated.  Again based on these claims, this patent is not usable.

Beyond the fact that this patent is completely worthless and would never stand up in a court of law if it were ever actually taken that far, there are other issues which we should point out.

Prior to the filing date of this patent there is a tremendous amount of prior art.  Some examples include:

1)      Rainfinity, software which provided outbound link load balancing and DNS manipulation for inbound link balancing which was documented in the summer of 2002.

2)      Ip route, a Linux-based tool developed by Alexey Kuznetsov which provides for both SYN modification and multipath routing was originally released in 1997.  http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2

3)      IP NETWORK ADDRESS TRANSLATION, i.e. SYN Modification, written by Michael Hasenste in 1997.  http://www.hasenstein.com/HyperNews/get/linux-ip-nat.html.

4)      Fatpipe commonly says that it has the only “transparent proxy” solution, however it does not appear to take in to account a VERY common methodology called http proxy, RFC 2068, 1997.  Again, this demonstrates Fatpipe Network’s inability to fully understand the very technology that it is attempting to patent.

5)      RFC 1631 which describes the ability to perform Network Address Translation, i.e. SYN modification, 1994.

6)      RFC 1027 Which describes Proxy ARP, 1987

7)      RFC 925 Which describes Multi-LAN resolution including ARP boxes, similar to Fatpipe, 1984.

It is clear that Fatpipe Networks India should not have been allowed to patent these methodologies and we will work to have this patent revoked.

 

As we find more patents which appear to be attempting to take ownership over open source technologies we will clearly point these patents out and attempt to either prevent them from being patented or work to challenge and revoke the patents from those companies which sponsor such action.