- Biological Inventions
- Brand Valuation
- Competition Law
- Constitutional Law
- Consumer Law
- Copyright Infringement
- Copyright Litigation
- Corporate Law
- Digital Right Management
- Educational Conferences/ Seminar
- Fashion Law
- Hi Tech Patent Commercialisation
- Hi Tech Patent Litigation
- Intellectual Property
- Intellectual Property Protection
- IP Commercialization
- IP Licensing
- IP Litigation
- IP Practice in India
- IPAB Decisions
- Legal Issues
- Media & Entertainment Law
- News & Updates
- Patent Act
- Patent Commercialisation
- Patent Filing
- patent infringement
- Patent Licensing
- Patent Litigation
- Patent Marketing
- Patent Opposition
- Patent Rule Amendment
- Pharma- biotech- Patent Commercialisation
- Pharma/Biotech Patent Litigations
- Section 3(D)
- Social Media
- Telecom Law
- Trademark Litigation
The Indian Patent Act, 2005, like for most other geographies, does accord to and follow the disclosure guidelines put forth by the TRIPS and has similar Patentability grounds, especially for non-Pharmaceutical subject matters, in which the contention over 3(d) leads to a different interpretation over efficacy grounds. Furthermore, special provisions such as those provided under Section 8 of the Patent Act, enable the Indian Patent Office to retrieve additional and more relevant information about the prosecution that happens with the family foreign Patent Applications of the Indian national phase patent application. Moreover, additional prior art available by means of results cited by ISR, literature/patents cited by the Applicant, earlier Patent/Prosecution History of the Applicant, gives way for searching more relevant and anticipating applications. Furthermore, with the Indian Patent Office being accorded as an ISR, is it now time that the Indian Granted Patents have certain extent of serious patent prosecution done, not from a formality compliance perspective, but more importantly from novelty/obviousness standards.
For the present discussion, let’s take an exemplary and recently Indian granted Patent 245829 (‘829), having a publication of grant on 11/02/2011, the Application No. for which is 4445/CHENP/2006 and the Applicant being Utstarcom, Inc. In summary, the invention relates to address-based network communications and more specifically to determination of a prefix portion of an address. Abstract of the granted Patent states:
A network element (10) can retain a plurality of prefix identifiers as are used to formulate an address to be used by individual network users. Pursuant to a preferred approach, one or more of these prefix identifiers are pre-correlated to a given domain name while at least one other prefix identifier is pre-correlated to the absence of a domain name. So configured, a specific prefix identifier can be allocated for use by a given network user as a function, at least in part, of the domain name (or lack of a domain name) as may be presented by that network user when seeking to establish a network connection.
The first independent claim as granted as per the Indian Patent Office is:
1. A method comprising:
receiving a communication from a network user seeking to establish a network connection;
when the communication presents a domain name as corresponds to the network user:
identifying a first prefix identifier as having been pre-correlated to the domain name;
providing to the network user the first prefix identifier;
when the communication does not present a domain name as corresponds to the network user
providing to the network user a second prefix identifier, which second prefix identifier is reserved for use with network users that do not present a domain name.
As it is evident from the first claim itself, the invention relates to two scenarios of mapping between “Domain name” and “Prefix Identifier” or “IP Address” or “Network Address”. In case the domain name is given by a network user, an IP Address corresponding to the same is returned back and in case the domain name is not provided by the network user, a new/second prefix identifier is generated and provided to the user. This is typically a well known function of a DNS system, wherein the claimed novelty seems to relate to generating a second prefix identifier in case domain name is not presented by a user.
As at the time of writing this article the Application Status search of the Indian Patent was not working, I am assuming that as the patent was granted in Feb 2011, the FER was issued somewhere around Jan-Feb 2010. From a strategic perspective, it would not have made sense to see the prosecution status of the corresponding applications in geographies such as EP or US, more so given the fact that Section 8 of the Indian Patent Act asks the Applicant’s to submit detailed updates on filing/publication/prosecution/abandonment/grant activities related to the corresponding foreign applications. It is to be noted that for the Corresponding application EP 1759300, the application was withdrawn by the Applicant on 28.08.2009, before the Indian Patent Office issued the FER. The same was the case in the corresponding US Application, wherein the Applicant itself failed to respond to the Final Office Action.
A close look at the cited portions of the Prior arts cited in the ISR, specially US 6324585, could also have given help in identifying anticipating documents, specially with the claimed subject matter being broad and relating to the overall functionality of a standard DNS system. Furthermore, prior arts discussed in US prosecution including ‘585 and US 2004/0258005 and US 2002/0172206 give clear pointers to claimed subject matter.
Furthermore, even if the above due-diligence was not considered worth, a very brief and quick search with the most basic keyword string (Dynamic AND “domain name” AND “network address”) would have revealed so many below mentioned and relevant patents, based on which the patentability of the subject matter involved could have been evaluated. Based on our quick due-diligence, we found following relevant patents that covers ‘829 subject mater partly or wholly.
IIPRD – Search Results
Search Result 1: US 6338082 – (Cited Portion for the first element of the independent claim which claims mapping between a domain name and a prefix identifier (IP Address)): A client of the DNS is called a resolver 114 . Resolvers 114 are typically located in the application layer of the networking software of each TCP/IP capable machine. Users typically do not interact directly with the resolver 114 . Resolvers 114 query the DNS by directing queries at name servers, which contain parts of the distributed database that is accessed by using the DNS protocols to translate domain names into IP addresses needed for transmission of information across the network. DNS is commonly employed by other application-layer protocols—including HTTP, SMTP and FTP—to translate user-supplied domain names to IP addresses. When a browser program 112 (e.g., an HTTP client), running on a user’s machine, requests a URL having a resolvable domain name, in order for the user’s machine to be able to send an HTTP request message to a server 120 , the user’s machine must obtain the IP address of the domain name. The user machine then runs the resolver 114 (DNS client) on the client-side of the DNS application. The browser 112 extracts the domain name from the URL and passes the domain name to the resolver 114 on the client-side of the DNS application. As part of a DNS query message, the DNS client 114 sends the domain name to a DNS server system 120 ′ connected to the Internet. The DNS client 114 eventually receives a reply, which includes the IP address for the domain name. The browser then opens a TCP connection 116 to the HTTP server process 120 located at the IP address.
Search Result 2: US 6425003 – (Relevant Cited Portion for the second element of the first independent claim which claims mapping between “no domain name” and a “second (new) prefix identifier”): A method and apparatus for resolving where to forward DNS (domain name service) requests for a user simultaneously logged into more than one service existing on a data communications network utilizes an active service list (ASL) to keep track of the services that the user is currently logged into. The active service list includes a list of services sorted in a particular order based on information about the service and sometimes the order in which the user logged into the services. Each service has a profile that defines, among other things, the IP Address space for the service and a Domain attribute. To determine the appropriate service and, therefore, the appropriate DNS server for a DNS request, the QName from the DNS request is compared to the configured Domain attribute(s) for each service in the order of the ASL. If a match is found, then the DNS request packet is modified to re-direct the DNS request to the DNS server configured for the matched service. If no domain match is found and the user is logged into an Internet Service, then the DNS request packet is modified to re-direct the DNS request to the DNS server configured for the first Internet Service found in the user’s ASL. If no domain match is found and the user is not logged into an active Internet Service, then the DNS request is not re-directed, but rather forwarded unmodified.
Search Result 3: US 6,944,167 – In one embodiment of the present invention, a domain name server receives a request for the public address of a private network host, using a public Internet Protocol (IP) address. The domain name server then determines if a valid public address for the private network host exists in an address data structure maintained by the domain name server. If a valid public address is found, the domain name server returns it to the requesting host. If a valid public address is not found, then the domain name server requests a public address from a network address translator identified with the private network. The network address translator then determines whether a public network address is currently assigned to the private network host. If not, and one is available from a pool of public network addresses available to the network address translator for the private network, then the network address translator allocates a public network address for the private network host. The network address translator then sends the domain name server the public network address or an indication that such address or the host was unavailable. An appropriate public network address might not be assigned for many reasons, including all public numbers are currently used or reserved; the private network host is not running; or security considerations preclude public access to the private network host.
It would be appreciated that the above prior arts have only been given for exemplary purposes after a very brief search merely to draw relevancy to the concern and no comprehensive evaluation of patentability has not been done based on these.
It further needs to be considered of how the first independent claim passes the bar for Section 3(k). The claimed method merely aims at providing a new IP address to a user request which does not have a domain name. The method clearly does not involve any change in structure of the mechanism of data/packet communication, or packet format, or increases the efficiency of transmission, or produces a tangible output in any manner whatever to qualify the concerned test and merely gives an IP address from a pool of prefix identifiers, a step that DNS is already is configured to do.
There are many more allied issues that might crop up for discussion when many more of such patents are evaluated for actual merit but the two I would last put across are: What worth would be such patents, both from enforceability and commercial perspective, if they would be invalidated the day they are litigated? Secondly, what credibility would such Indian Granted Patents have if the Patentees themselves are not even confident that they would be able to enforce their rights when the need arises?
1. Indian Patent office database
About the Author: Mr. Tarun Khurana, Partner and Patent Attorney in Institute of Intellectual Property Research & Development (IIPRD) and can be reached: Tarun@iiprd.com.