`
`In re PATENT APPLICATION OF:
`
`Attorney Docket:
`
`2655—0185
`
`Net2Phone, Inc. (Patent No. 6,009,469)
`
`Group An Unit:
`
`3992
`
`Control No.:
`
`90/010,422
`
`Examiner: KOSOWSKI, Alexander
`
`Issue Date: December 28, 1999
`Title: GRAPHIC USER INTERFACE FOR
`INTERNET TELEPHONY APPLICATION
`
`Confirmation No.:
`
`6565
`
`DECLARATION OF KETAN MAYER-PATEL UNDER 37 C.F.R. 1.132
`
`Hon. Commissioner of Patents
`PO. Box 1450
`
`Alexandria, VA 22313-1450
`
`I. INTRODUCTION
`
`1.
`
`I have been retained as an independent expert witness by NetZPhone, Inc., the assignee of
`
`the patent presently undergoing reexamination (i.c., US. Patent No. 6,009,469 (hereinafter “the
`
`‘469 patent”)).
`
`2.
`
`I am an expert in the field of networking protocols including networking protocols
`
`supporting multimedia streams including digital audio data. See Curriculum Vitae attached as
`
`Exhibit 1.
`
`3.
`
`1 received Bachelors of Arts degrees in Computer Science and Economics in 1992, a
`
`Masters of Science in 1997 from the Department of Electrical Engineering and Computer
`
`Science and a Ph.D. in 1999 from the Department of Electrical Engineering and Computer
`
`Science, all from the University of California, Berkeley.
`
`4.
`
`I received the National Science Foundation CAREER Award in 2003 while an Assistant
`
`Professor at the University of North Carolina, Chapel Hill.
`
`5.
`
`I have had extensive experience in both industry and academia as it relates to the
`
`technical fields relevant here. For example, I have been a programmer, a visiting researcher, and
`
`an Assistant and Associate professor.
`
`Page 1 of 31
`
`LG Electronics Exhibit 1027
`
`
`
`Re-Examination of Patent No. 6,009,469
`Control No.: 90/010,422
`Filed:
`February 24, 2009
`Declaration of Ketan Mayer-Patel under 37 CPR. 1.132
`
`6.
`
`I am a co-author of numerous articles that have appeared in a number of refereed
`
`publications and proceedings.
`
`7.
`
`Governmental agencies, such as the National Science Foundation and the Office of Naval
`
`Research, have provided funding for my research.
`
`II. RETENTION AND COMPENSATION
`
`8.
`
`l have been retained to offer an expert opinion on the prior art relevant to the ‘469 patent
`
`(and other patents currently under re-examination) and the validity of the claims undergoing re-
`
`examination.
`
`9.
`
`My work on this case is being billed at a rate of $400 per hour, with reimbursement for
`
`actual expenses. My compensation is not contingent upon the outcome of the case.
`
`III. BASIS OF MY OPINION AND MATERIALS CONSIDERED
`
`10.
`
`In preparation for this report, I have considered and relied on data or other documents
`
`identified in this report. For example, I have reviewed the Office Action dated August 25, 2009
`
`as well as the Request for Re—examination that was filed for the ‘469 patent including the
`
`Exhibits to the Request for Re-examination.
`
`I have also reviewed the file history of the ‘469
`
`patent.
`
`11.
`
`I have familiarized myself with the state of the art at the time the ‘469 patent was filed by
`
`reviewing both patent and non-patent references from prior to the filing date of the application
`
`that became the ‘469 patent.
`
`12.
`
`My opinions are also based upon my education, training, research, knowledge, and
`
`experience in this technical field.
`
`IV. SUMMARY OF MY OPINIONS
`
`13.
`
`Based on my prior experience in the field of computer systems and networking, including
`
`network communication protocols, and based on my review of the documents relating to the
`
`2
`
`Page 2 of3l
`
`
`
`Re-Examination of Patent No. 6,009,469
`Control No.: 90/010,422
`
`February 24, 2009
`Filed:
`Declaration of Ketan Mayer-Patel under 37 CPR. 1.132
`
`pending re—examination proceeding, I have developed an understanding of the ‘469 patent and
`
`the claimed inventions.
`
`14.
`
`I have been asked to compare the claims of the ‘469 patent to the references applied in
`
`the outstanding Office Action. The results of my comparison are provided below.
`
`15.
`
`In general, it is my opinion that all of the claims undergoing re-examination (i.e., claims
`
`1-3, 5, 6, 8, 9 and 14-18) are patentable over the applied referencw for at least the reasons set
`
`forth below.
`
`The rejection of claims 1-3, 5, 6, 8, 9, and 14-18 over NetBIOS, RFC 1531, Pinard and the
`
`VocalChat User’s Guide
`
`16.
`
`Claims 1-3, 5, 6, 8. 9, and 14-18 were rejected under 35 U.S.C. § 103(a) as being
`
`obvious in light of Protocols for X/Open PC Interworking SMB, Version 2, The Open Group
`
`(1992) (hereinafter “NetBIOS”), in view of RFC 1531, Pinard and the VocalChat User’s Guide.
`
`17.
`
`I understand that a rejection under 35 U.S.C. § 103(a) means that an examiner believes
`
`that although no single reference includes all of the claimed limitations, nonetheless the
`
`combination of references made by the examiner would have been obvious to one of ordinary
`
`skill in the art at the time the invention was made.
`
`Claims 1-3
`
`18.
`
`Claim 1 recites “a. program code for generating a user-interface enabling control of a fu‘st
`
`process executing on the computer system.” With respect to the limitation of “program code for
`
`generating a user-interface enabling control of a first process executing on the computer system,”
`
`the Office Action alleges that “computers executing NetBIOS may contain DOS operating
`
`systems or may operate on other operating systems, which examiner notes inherently contain at
`
`least text-based user interfaces.” By stating that NetBIOS “may contain” DOS operating systems
`
`I believe the Examiner is indicating that NetBIOS need not actually contain or be running on a
`
`Page 3 of3l
`
`
`
`Re—Examination of Patent No. 6,009,469
`Control No.: 90l0l 0,422
`Filed:
`February 24, 2009
`Declaration of Kctan Mayer-Patel under 37 C.F.R. 1.132
`
`DOS operating system. Since that is true, NetBIOS (or the computer running NetBIOS) does not
`
`inherently include text-based user interfaces.
`
`19.
`
`Furthermore, the recitation of “other operating systems” also does not inherently mean
`
`that “text-based user interfaces” are provided. For example, embedded systems need not have a
`
`diSplay or a tract interface even thoagh they may have operating systems. The Office Action also
`
`has not asserted that this limitation is taught by RFC 1531. Thus, I do not believe that limitation
`
`(a) has been shown to be taught by either applied reference.
`
`20.
`
`Claim 1 also recites “1). program code for determining the currently assigned network
`
`protocol address of the first process upon connection to the computer network.” The Office
`
`Action admits that NetBIOS does not teach this limitation. The Office Action alleges that such a
`
`limitation is taught by RFC 1531 because “RFC 1531 teaches dynamically assigning IP address
`
`on a TCPr’IP network by an Internet access server.” By looking at limitations (a) and (b)
`
`together, however, it can be seen that the Office Action has not shown that the currentiy assigned
`
`network protocol address is that of the first process which the Office Action alleged was the
`
`“text-based user interface.” The Office Action also has not explained why the text‘based
`
`interface would have to have its currently assigned network protocol address determined. Thus, I
`
`do not believe that limitation (b) is taught by either applied reference.
`
`21.
`
`Claim 1 recites “c. program code responsive
`
`for forwarding the assigned network
`
`protocol address of the first process and a unique identifier of the first process to the server
`
`process upon establishing a communication connection with the server process.” The Office
`
`Action has not shown that the assigned network protocol address of the first process is
`
`determined, so the Off] ce Action also has not shown that the assigned network protocol address
`
`of the first process would be forwarded to the server upon establishing a communication
`
`connection with the server process. Similarly, the Office Action has not shown that the text-
`
`based user interfaces would have a unique identifier to be forwarded to the server. The Office
`
`Action further has not shown that such a limitation is taught by RFC 1531. Accordingly, I do not
`
`believe that limitation (c) is taught by either applied reference.
`
`4
`
`Page 4 of31
`
`Page 4 of 31
`
`
`
`Ito-Examination of Patent No. 6,009,469
`Control No.: 9010104122
`Filed:
`February 24, 2009
`Declaration of Ketan Mayer-Patel under 37 CPR. 1.132
`
`22.
`
`Claim 1 also recites “d. program code, responsive to user input commands, for
`
`establishing a point-to-point communications with another process over the computer network.”
`
`The Office Action cites NetBIOS, pgs. 393L400, as teaching that “point-to-point communication
`
`is established upon initiation between nodes once target names and addresses have been found.”
`
`However, the Office Action has not shown that the code is “responsive to user input commands”
`
`as no user input commands have been identified. Even assuming that text-based user interfaces
`
`were taught by NetBIOS, the Office Action still w0uld not have shown that point-to—point
`
`communications are inherently established “responsive to user input commands.” The text-based
`
`user interfaces could have been used for non-communicating fimctions or even functions that use
`
`non-point—to-point communications. The Office Action further has not shown that such a
`
`limitation is taught by RFC 1531. Accordingly, I do not believe that limitation (d) is taught by
`
`either applied reference.
`
`23.
`
`Since none of the limitations of claim 1 have been shown to be taught by the applied
`
`combination of references, I do not believe that claim 1 and dependent claims 2 and 3 are
`
`obvious in light of the proposed combination.
`
`24.
`
`The Office Action states that “it would have been obvious
`
`to determine the currently
`
`assigned network address of the first process upon connection to the computer network in the
`
`invention taught by NetBIOS above since this allows for automatic reuse of an address
`
`and
`
`since examiner notes the use of dynamic IP address assignment
`
`are old and well known
`
`and are useful to eliminate the burdensome task of manually assigning IP addresses for all
`
`networked computers.” However, the Office Action does not acknowledge the problems that
`
`could arise in doing so or how those problems w0uld be resolved by those of ordinary skill at the
`
`time the patent was filed.
`
`25.
`
`In the context of point-to-point communication, widespread use of dynamically assigned
`
`addresses can create additional problems for a NetBIOS environment. For example, Section
`
`l5. [.7 of the NetBIOS reference (entitled “Consistency of the NBNS Data Base”) recognizes
`
`that the association between a node, a registered name and an IP address is tenuous, even in an
`
`5
`
`Page 5 of31
`
`Page 5 of 31
`
`
`
`Re-Examination of Patent No. 6,009,469
`Control No.2 90/010,422
`Filed:
`February 24, 2009
`Declaration of Ketan Mayer-Patel under 37 C.F.R. 1.132
`
`environment that uses static IP addresses. “Even in a properly running NetBIOS scope the
`
`NBNS and its community of end—nodes may occasionally lose synchronization with respect to
`
`the true state of name registrations.” To minimize the impact of this problem, the reference
`
`states, “Various approaches have been incorporated into the NetBIOS-over—TCP protocols”
`
`which it then proceeds to describe.
`
`26.
`
`However, by incorporating DHCP and adopting of dynamic address allocation (c.g., as
`
`used by Internet access providers), the synchronization problem would become more disruptive,
`
`not less. Dynamic addressing introduced a new uncertainty to the relationships among the
`
`NBNS and its community of end-nodes and a new set of obstacles to NetBIOS synchronization
`
`that are not addressed by the NetBIOS reference. Consider the case of a node that is turned-off
`
`and then subsequently turned back on, or the case of a node that has simply lost its Internet
`
`connection for some technical reason or whose DHCP lease has expired which then re-
`
`establishes a connection. In such a dynamic addressing environment, such a node would most
`
`likely obtain a new IP address when it was tumed back on that was different than the one it had
`
`when it registered its name. This change could lead to any number of node-name-IP address
`
`synchronization problems for the disclosed NetBIOS protocols.
`
`27.
`
`For example, because the NBNS does not know the node’s new address, the NBNS
`
`would be unable to send to the node a Name Release Request or a Name Conflict Demand or
`
`request that the node send it a Name Status Request. Because communication from the node
`
`would be originating at a new address that was not recognized by the NBNS, a node‘s response
`
`to a Name Query Request (assuming it somehow knew that its name had been challenged,
`
`perhaps from before it lost network connectivity) would not be recognized. A node would also
`
`be unable to confirm its association with registered names by sending Name Refi'esh Request
`
`packets to the NBNS.
`
`If a session between two NetBIOS applications were cut-off, re-
`
`establishing the communication would be especially difficult where the ability of a called entity
`
`to obtain both its associated name and its associated IP address were in doubt. As a result, the
`
`Office Action has not demonstrated that a solution to the problems created by exposure of
`
`6
`
`Page 6 of3l
`
`
`
`Re-Examination of Patent No. 6,009,469
`Control No.2 90/010,422
`Filed:
`February 24, 2009
`Declaration of Ketan Mayer-Patel under 37 CPR. 1.132
`
`NetBIOS to DHCP and dynamic addressing has been addressed by any of the applied
`
`references. '
`
`28.
`
`The Office Action also has not identified anything in the cited an that suggests how a
`
`person of ordinary skill is to go about the redesign of NetBIOS and the solving of obstacles to
`
`NetBIOS operation that are created by lntemet access; problems that were recognized and left as
`
`warnings unresolved in the NetBIOS reference.2
`
`29.
`
`Thus, I believe claims 1—3 are patentable over the combination of NetBIOS and RFC
`
`1531.
`
`Claims 5 and 6
`
`30.
`
`Claim 5 recites “determining the currently assigned network protocol address of the first
`
`process upon connection to the computer network." The Office Action acknowledges that this
`
`limitation is not taught by NetBIOS but alleges that “RFC 1531 teaches dynamically assigning IP
`
`addresses on a TCP/IP network by an lntemet access server." Ihe Office Action further alleges
`
`that “it would have been obvious
`
`to determine the cun'ently assigned network address of the
`
`first process upon connection to the computer network in the invention taught by NetBIOS above
`
`since this allows for automatic reuse of an address
`
`and since examiner notes the use of
`
`dynamic IP address assignment
`
`are old and well known
`
`and are useful to eliminate the
`
`burdensome task of manually assigning IP addresses for all networked computers.” However, as
`
`described above with respect to claims 1-3, I do not believe that the Office Action has shown that
`
`in light of the problems that worsen by combining NetBIOS and RFC 1531, that a person of
`
`‘ Besides dynamic addressing, lntemet access would pose other challenges to a NetBIOS system. For example,
`because NetBIOS was designed for use on local arm networks with small numbers of computers, trust among the
`network participants is assumed. That assumption cannot be transferred to a global lntemet made up of unknown,
`and sometimes malevolent, entities. An implementation of NetBIOS on the public lntemet would necessitate non-
`trivial adaptations to ensure that its services perform correctly and return accurate information. See Exhibit 2, from
`httpi/wwwyfischmlssganSite/sjmficuritygasp which instructs Microsofi Windows users whose computers access
`the lntemet to disable NetBIOS over TCP/IP in order to solve their security problems.
`2 See Section 4.6 (“The proposed standard recognizes the need for NetBIOS operation across a set of networks
`interconnected by network (1P) level relays (gateways) However, the standard assumes that this form of operation
`will be less frequent than on the local MAC bridged-LAN")
`7
`
`Page 7 of3l
`
`
`
`Re-Examination of Patent No. 6,009,469
`Control No.: 90/010,422
`
`February 24, 2009
`Filed:
`Declaration of Ketan Mayer-Patel under 37 CPR. 1.132
`
`ordinary skill in the art would have combined the two references as proposed. Thus, I believe
`
`that claims 5 and 6 are patentable over the applied NetBIOS and RFC 1531 references.
`
`
`Claims 8 9 and 14-18
`
`31.
`
`Claim 8 recites “querying the server process to determine if the first callee process is
`
`accessible.” The Office Action asserts that this limitation is taught by NetBIOS and cites pages
`
`377, 388, 389 and 446 as supporting the proposition that “a query is sent to the NBNS to
`
`determine if another node is logged in and discover[s] the node[’]s IP address." However, the
`
`Office Action has not shown how knowing that a name has been registered equates to
`
`“determin[ing] if the first callee process is accessible.” While NetBIOS uses name entries with
`
`“active” statuses as part of its name management process, an analysis of how that “active” status
`
`is used shows that “an active name" is not synonymous with determining if the first callee
`
`process is accessible. An active name simply refers to a name that has been registered and that
`
`has not yet been de-registered, independent of whether the associated computer is or is not
`
`accessible. As shown on page 447 (and reproduced below), the Node_Name entries stored with
`
`respect to a NetBIOS Name Server contain a series of fields including the “ACT” field.
`
`Page 8 of3l
`
`
`
`Re-Examination of Patent No. 6,009,469
`Control No.: 90/010,422
`Filed:
`February 24, 2009
`Declaration of Ketan Mayer-Patel under 37 CPR. 1.132
`
`The mumms field:
`
`I
`1
`1
`1
`1
`1
`5
`4
`3
`2
`1
`0
`9
`8
`'7
`6
`S
`4
`3
`2
`1
`0
`a---+~-—+----+--—+---o---4---i—--r--~i—--i—--¢--—a—--s———o——-t---o
`
`i
`RESERVED
`[DRGICNPIACTIPHMI
`ONT
`i G I
`4--—o--~~s—~—o--—-+—"s—--+-——~-~-¢—-v+--—+e-—+---&———i-——+-—-o~~—+
`
`The mgpmas field is defined as:
`
`Symbol
`
`Bitts)
`
`Description:
`
`745
`6
`
`then name on this
`
`RESERVED
`Pan
`
`ACT
`
`CH?
`
`DRG
`
`ONT
`
`6
`
`Reserved for future use. Hunt be zero (0) .
`Permanent Name Flag.
`If one (1)
`than entry
`is for the permanent node name.
`Flag is zero
`(0) for all other names.
`5 Active Name Flag. All entries have this flag
`set to one (1).
`If one (1)
`Conflict Flag.
`node is in conflict.
`then this name
`‘3 Dcrcgistcr Plug.
`If one ('1)
`is in the process of being deleted.
`Owner Node Type:
`00 a 5 node
`01 = P node
`10 = fl node
`11 = Reserved for future use
`Group blame Nag.
`If one (I)
`then the name is a GROUP NetBIOS
`name.
`
`4
`
`1,2
`
`0
`
`If zero (0)
`
`then it is a UNIQUE HetBIOS name.
`
`32.
`
`The ACT field is a single bit field (in bit 5) that signifies an “Active Name Flag. All
`
`entries have thisflag set to one (1).” (Emphasis added.) If all name entries have this flag set to
`
`one (1), then the NetBIOS name server cannot be using the Active Name Flag as a means of
`
`separately tracking whether the entity that owns the name is “active,” let alone what its “on-line”
`
`status might be.
`
`33.
`
`The NetBIOS reference also does not teach that the active status of a name in the
`
`NetBIOS server is an indication of the active status of the owner of that name. To the contrary,
`
`when information about whether the owner of a name is “active” may be relevant, for example
`
`when a new entity seeks to register a name that has already been registered in the NetBIOS name
`
`server, the NetBIOS reference describes an elaborate set of interactions used to test whether the
`9
`
`Page 9 of 31
`
`
`
`Re-Examination of Patent No. 6,009,469
`Control No.: 90/010,422
`
`February 24, 2009
`Filed:
`Declaration of Ketan Mayer-Patel under 37 CPR. 1.132
`
`existing owner of the registered name is active or inactive. 1t does not rely on the fact that the
`
`name is active in the NetBlOS name server (See Section 15.2.2.2 and 15.2.2.3 entitled “Existing
`
`Name and Owner is Inactive”).
`
`34.
`
`The NetBlOS reference also does not teach that an acquired lP address can be reasonably
`
`relied upon by a requesting end-node to confirm that an end-node associated with a sought name
`
`is, in fact, “accessible.” The NetBlOS reference describes at least two different scenarios where
`
`a second end-node sends a rejection response to the first end-node notwithstanding the fact that
`
`an end-node is connected to the computer network and active with respect to the sought name.
`
`See Section 16.1.1 ("There exists a NetBlOS LISTEN compatible with the incoming call, but
`
`there are inadequate resources to permit establishment of a session. .The called name does, in
`
`fact, exist on the called node, but there is no pending NetBlOS LISTEN compatible with the
`
`incoming call”). No distinction is made in the reference between the rejection response in these
`
`cases and the rejection response in cases where the called name does not exist on the called end-
`
`node. Section 16.1.1 also states “In all but the first case, a rejection response is sent back over
`
`the TCP connection to the caller.”
`
`35.
`
`The Office Action also has not alleged that any of the remaining references teach this
`
`limitation missing from the NetBIOS reference. As such, claim 8 and its dependent claims
`
`(claims 9 and 14- l 8) are not rendered obvious by the cited combination of references.
`
`The rejection of claims 1-3, 5. 6, 8, 9, and 14-18 over the combination of the Ethemhone papers
`
`in view of Vin and further in view of RFC 1531 Pinard and the VocalChar User’s Guide
`
`36.
`
`Claims 1-3 were rejected under 35 U.S.C. § 103(a) as obvious over Etherphone:
`
`Collected Papers 1987-1988 (May 1989) (hereinafier “Etherphone”) in view of Harrick M. Vin,
`
`et al. Multimedia Conferencing in the Etherphone Environment, IEEE Computer Society
`
`(October 1991) (hereinafier “Vin") and further in view of RFC 1531, Pinard and VocalChat
`
`User’s Guide. The Etherphone Collected Papers include An Overview ofthe Etherphone System
`
`and its Applications (hereinafter “Zellweger”), Telephone Management in the Etherphone
`
`10
`
`Page 10 of3l
`
`
`
`Re-Examination of Patent No. 6,009,469
`Control No.2 90/010,422
`
`February 24, 2009
`Filed:
`Declaration of Ketan Mayer-Patel under 37 CPR. 1.132
`
`System (hereinafter “Swinehart”), and Managing Stored Voice in the Etherphone System
`
`(hereinafier “Terry”).
`
`37.
`
`Claim 1, as amended, recites “a. program code for generating a user-interface enabling
`
`control of a first process executing on the computer system” and “d. program code means,
`
`responsive to user input commands, for establishing a point-to-point communications with
`
`another process over the computer network.” When read together, it can be seen that the Office
`
`Action has not shown that these limitations are taught by the applied combination of references.
`
`38. With respect to the limitation “a. program code for generating a user-interface enabling
`
`control of a first process executing on the computer system,” the Office Action cites Swinehart
`
`and Zellweger as teaching that “workstations include GUI’s.” Later, with respect to the
`
`limitation “d. program code means, responsive to user input commands, for establishing a point-
`
`to-point communications with another process over the computer network,” the Office Action
`
`asserts that “after acquin‘ngthe network address of a callee, voice datagrams are transmitted
`
`directly amont [sic; among] the participants, bypassing the control server.” However, by
`
`“participants” it appears that the Office Action is referring to Etherphones participating in a
`
`telephone call. As such, the Office Action has not shown that the datagrams are transmitted as
`
`part of a point-to-point communication from the workstation (which was alleged as having the
`
`first process) to one of the Etherphones. In fact, with respect to limitation (c), the Office Action
`
`confirms that its interpretation is that the “workstation address [is] transmitted to the Voice
`
`Control Server when connected” —- not the Etherphone’s network address.
`
`39.
`
`Similarly, looking at it from the opposite perspective, if the voice datagrams are actually
`
`going fiom one Etherphone to another, then the Office Action has not shown how the “currently
`
`assigned network protocol address of the first process” is the address of the Etherphone and how
`
`the Etherphone has a display or “a user-interface enabling control a first process” on that
`
`Etherphone. The Office Action also has not alleged that RFC 1531 teaches this limitation
`
`missing from the Etherphone references. Thus, claims 1-3 are not rendered obvious by the
`
`proposed combination.
`
`[1
`
`Page 11 of3l
`
`
`
`lie-Examination of Patent No. 6,009,469
`Control No.: 90!010,422
`
`February 24, 2009
`Filed:
`Declaration of Ketan Mayer-Patel under 3? C.F.R. 1.132
`
`Claims 5 and 6
`
`40.
`
`Claim 5 recites “A. determining the currently assigned network protocol address of the
`
`first process upon connection to the computer network” and “D. establishing a point—to—point
`
`communication with another process over the computer network.” As described above with
`
`respect to claim I, when these two limitations are examined together, it can be seen that the
`
`Office Action has not shown that these limitations are met.
`
`41. With respect to the limitation “A. determining the currently assigned network protocol
`
`address of the first process upon connection to the computer network,” the Office Action again
`
`cites the GUI‘s of the workstation as meeting this limitation. Then, with respect to the limitation
`
`“D. establishing a point-to-point communication with another process over the computer
`
`network,“ the Office Action again states “voice datagrams are transmitted directly amont [sic;
`
`among] the participants, bypassing the control server.” Thus, as discussed above with respect to
`
`claim 1, the Office Action appears to have overlooked that the Etherphone, not the workstation
`
`with the GUI, is receiving the voice datagrams, so the Elherphonc reference does not teach
`
`limitations (A) and (D). The Office Action also has not alleged that RFC 1531 teaches this
`
`limitation missing from the Etherphone references. Thus, claims 5 and 6 are not rendered
`
`obvious by the proposed combination.
`
`
`Claims 8 9 and 14-18
`
`42.
`
`Claim 8 recites “a method for establishing a point-to-point communication from a caller
`
`process to a callee process over a computer network, the caller process capable of generating a
`
`user interface and being operatively connected to the callee process and a server process over the
`
`computer network.” That method includes “querying the server process to determine if the first
`
`callee process is accessible” and “establishing a point-to-point communication link from the
`
`caller process to the first callee process.”
`
`12
`
`Page 12 0f31
`
`Page 12 of 31
`
`
`
`Re-Examination of Patent No. 6,009,469
`Control No.: 90/010,422
`Filed:
`February 24, 2009
`Declaration of Ketan Mayer-Patel under 37 C.F.R. 1.132
`
`43. With respect to the limitation of “establishing a point-to-point communication link from
`
`the caller process to the first callee process," the Office Action asserts that Swinehart and
`
`Zellweger teach “voice datagrams are transmitted directly among participants.” However, it
`
`appears that the Office Action means that the Etherphone are the “participants." If this is the
`
`case, there is no indication that the combination meets the limitation of “the caller process
`
`capable of generating a user interface” as the Office Action has not alleged that the Etherphone
`
`has such a capability. The Office Action has also not alleged that the other references overcome
`
`this deficiency of the Etherphone references. Thus, claim 8 and its dependent claims are
`
`patentable over the applied combination of references.
`
`The rejection of claims 1-3, 5, 6, 8, 9, and 14-18 over the combination ofthe VocalChat
`
`references in view of RFC 1531 and Pinard
`
`44.
`
`Claims 1-3, 5, 6, 8, 9 and 14-18 were rejected under 35 U.S.C. § 103(a) as obvious over
`
`VocalChat User’s Guide in view of VocalChat Readme, VocalChat Networking, VocalChat Help
`
`File and VocalChat Troubleshooting Help file (collectively the “VocalChat References") and
`
`further in view of RFC 1531 and Pinard.
`
`Claims 1-3
`
`45.
`
`Claim 1 recites “program code responsive to the currently assigned network protocol
`
`address of the first process, for establishing a communication connection with the server process
`
`and for forwarding the assigned network protocol address of the first process and a unique
`
`identifier of the first process to the server process upon establishing a communication connection
`
`with the server process.” The Office Action admits that this limitation is not disclosed by the
`
`VocalChat references. However, the Office Action attempts to overcome this deficiency by
`
`combining the VocalChat references with RFC 1531.
`
`46.
`
`However, the Office Action does not acknowledge the problems that could arise in doing
`
`so or how those problems would be resolved by those of ordinary skill at the time the patent was
`
`13
`
`Page 13 of3l
`
`
`
`Re-Examination of Patent No. 6,009,469
`Control No.: 90/010,422
`
`February 24, 2009
`Filed:
`Declaration of Ketan Mayer-Patel under 37 C.F.R. 1.132
`
`filed. Thus, 1 do not believe that the Office Action has proven that one of ordinary skill at the
`
`time the patent was filed would have made the proposed combination.
`
`47.
`
`Claim 1 also recites “forwarding the assigned network protocol address of the first
`
`process and a unique identifier of the first process to the server process upon establishing a
`
`communication connection with the server process.” The VocalChat Generic implementation
`
`does not disclose such a limitation. In the VocalChat Generic implementation, a local process
`
`reads a “USERS” file or a Connections file in its entirety and writes it back in its entirety rather
`
`than “forwarding the assigned network protocol address of the first process and a unique
`
`identifier of the first process to the server process upon establishing a communication connection
`
`with the server process." This causes the VocalChat system to have to send an increasing
`
`amount of information as the number of users increases. Sending the whole file such that the
`
`new file replaces the old file also creates problems with consistency such that one user’s changes
`
`could overwrite the changes of another user -- eSpecially as networks got larger which would
`
`have increased the problem of inconsistent files being written.
`
`48.
`
`The Office Action also has not shown that one of ordinary skill in the art would have
`
`made the proposed combination. The Office Action proposes a modification to the VocalChat
`
`References by incorporating the teachings of RFC 1531 because it allegedly “would have been
`
`obvious to utilize dynamically assigned IP addresses from lntemet access servers in the
`
`invention taught by VocalChat
`
`since this allows for automatic reuse of an address that is no
`
`longer needed by the host to which it is assigned.” Such an allegation ignores the development
`
`history of the VocalChat products themselves.
`
`49.
`
`The Request cites a Generic version of the VocalChat client which, according to Mr.
`
`Cohen, was used on local area networks. See Cohen Declaration, paragraph 3. There apparently
`
`was a subsequent version of VocalChat that was also released by VocalTec to the public in 1994,
`
`at least in beta. This version, called VocalChat Gateway To lnterent (or “VocalChat GT1”) was
`
`designed for use on the Internet, and I have been informed that NetZPhone believes that
`
`VocalChat (5T1 used static local address files into which static callee addresses were manually
`
`14
`
`Page 14 of 31
`
`
`
`Re-Examination of Patent No. 6,009,469
`Control No.: 90/010,422
`Filed:
`February 24, 2009
`Declaration of Ketan Mayer-Patel under 37 CPR. 1.132
`
`input.
`
`I have also been informed that NetZPhone believes that VocalChat GTI did not utilize a
`
`server at all.
`
`50.
`
`Based on the above, I believe the use of manual inputting of static addresses and the
`
`absence of a server suggests that the VocalTec designers—presumably software developers of at
`
`least ordinary skill in the art—did not consider the alleged combination of their own VocalChat
`
`references with RFC 1531, or it suggests that they did consider it but were unable to overcome
`
`the non-trivial obstacles to doing so.
`
`51.
`
`I have also been informed that NetZPhone believes that soon after the release of the
`
`VocalChat GT1 version, VocalTec released another VocalChat version that used lntemet Relay
`
`Chat (IRC) to help VocalChat clients with dynamically assigned IP addresses find one another.
`
`This change from VocalChat GT1 to VocalChat IRC appears to be further objective evidence that
`
`even the VocalChat designers recognized that the “improvement” to the Generic VocalChat
`
`implementation was still deficient. If the designers of the VocalChat Generic implementation
`
`did not see fit to combine dynamic addressing with the Generic implementation disclosed in