IN THE UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD. GOOGLE INC., Petitioner,

Transcription

1 NO: US IN THE UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD GOOGLE INC., Petitioner, v. MOBILESTAR TECHNOLOGIES LLC, Patent Owners. Case IPR Patent U.S. 6,937,572 PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 6,937,572 UNDER 35 U.S.C. 312 AND 37 C.F.R Mail Stop PATENT BOARD Patent Trial and Appeal Board US Patent and Trademark Office PO Box 1450 Alexandria, Virginia

2 TABLE OF CONTENTS Page I. MANDATORY NOTICES PURSUANT TO 37 C.F.R II. CERTIFICATION OF GROUNDS FOR STANDING... 1 III. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED... 2 A. Prior Art Patents and Printed Publications... 2 B. Grounds for Challenge... 4 IV. BACKGROUND OF THE 572 PATENT... 4 A. Technology Background Relevant to the 572 Patent... 4 B. Overview of the 572 Patent... 7 C. Prosecution History of the 572 Patent... 8 V. CONSTRUCTION OF THE CHALLENGED CLAIMS A. call trace information B. Other Terms VI. IDENTIFICATION OF HOW CHALLENGED CLAIMS ARE UNPATENTABLE A. Claims 17, 18, and 20 are anticipated by Byers B. Claims 19 and 20 are rendered obvious by Byers in view of Mottishaw C. Claims are anticipated by Matsumoto D. Claim 19 is rendered obvious by Matsumoto in view of Mottishaw E. Claims and 20 are anticipated by Fobert F. Claim 19 is rendered obvious by Fobert in view of Mottishaw G. Claims and 20 are anticipated by Cruickshank i

3 H. Claim 19 is rendered obvious by Cruickshank in view of Mottishaw VII. CONCLUSION ii

4 Statutes TABLE OF AUTHORITIES Page 35 U.S.C. 102(e)... 2, 3 35 U.S.C. 314(a)... 4 Rules 37 C.F.R C.F.R C.F.R , 2, 16 iii

5 I. MANDATORY NOTICES PURSUANT TO 37 C.F.R Real Party-in-Interest: Google Inc. ( Petitioner ) Related Matters: U.S. Patent No. 6,937,572 ( the 572 Patent ) is asserted in the Eastern District of Texas in consolidated case Rockstar Consortium US LP et al v. ASUSTeK Computer, Inc. et al., Consolidated Case No. 2:13-cv (E.D. Tex.), which consolidated six different cases filed by Rockstar Consortium US LP. The 572 Patent is also asserted in Google Inc. v. Rockstar Consortium US LP et al., Case No. 4:13-cv CW (N.D. Cal.). Petitioner is filing another petition for inter partes review challenging claims (See IPR ) Petitioner recommends assigning both proceedings to the same panel. Counsel: Lead Counsel: Scott A. McKeown (Reg. No. 42,866) Backup Counsel: Greg Gardella (Reg. No. 46,045) Service Information : CPDocketMcKeown@oblon.com CPDocketGardella@oblon.com Post: Oblon Spivak, 1940 Duke St., Alexandria, VA Telephone: Facsimile: II. CERTIFICATION OF GROUNDS FOR STANDING Petitioner certifies pursuant to Rule (a) that the patent for which review is sought is available for inter partes review and that Petitioner is not 1

6 barred or estopped from requesting an inter partes review challenging the patent claims on the grounds identified in this Petition. III. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED Pursuant to Rules 42.22(a)(1) and (b)(1) (2), Petitioner challenges claims of the 572 patent. The application that matured into the 572 patent, U.S. Patent Application No. 09/751,796, was filed on Dec. 29, 2000 ( the priority date ). (Ex. 1001, the 572 patent; Ex. 1002, File History of the 572 Patent.) A. Prior Art Patents and Printed Publications Petitioner relies upon the following patents and printed publications: Exhibit 1003 U.S. Patent No. 6,853,713 to Fobert et al. ( Fobert ) issued on February 8, 2005, based on Application Serial No. 09/466,619, filed on December 17, 1999, which is prior to the earliest filing date claimed by the 572 patent (December 29, 2000). Fobert is prior art under pre-aia 35 U.S.C. 102(e). Fobert was not considered during the original prosecution of the 572 patent and is not cumulative of any prior art considered by the examiner(s). Exhibit 1004 U.S. Patent No. 6,721,284 to Mottishaw et al. ( Mottishaw ) issued April 13, 2004, based on Application Serial No. 09/283,541, filed on April 1, 1999, which is prior to the earliest filing date claimed by the 572 patent (December 29, 2000). Mottishaw is prior art under pre-aia 35 U.S.C. 102(e). Mottishaw was considered during the original prosecution of the 572 patent but is 2

7 now considered in view of the expert declaration of Professor Vijay K. Madisetti, PhD (Ex. 1007). Additionally, Mottishaw is combined here with Fobert, Matsumoto, and Cruickshank, which were not previously considered by the examiner(s). Exhibit 1005 U.S. Patent No. 6,798,872 to Matsumoto al. ( Matsumoto ) issued on September 28, 2004, based on Application Serial No. 09/692,018, filed on October 19, 2000, which is prior to the earliest filing date claimed by the 572 patent (December 29, 2000). Matsumoto is prior art under pre-aia 35 U.S.C. 102(e). Matsumoto was not considered during the original prosecution and is not cumulative of any prior art considered by the examiner(s). Exhibit 1006 U.S. Patent No. 6,888,927 to Cruickshank et al. ( Cruickshank ) issued May 3, 2005, based on Application Serial No. 09/220,962, filed on December 28, 1998, which is prior to the earliest filing date claimed by the 572 patent (December 29, 2000). Cruickshank is prior art under pre-aia 35 U.S.C. 102(e). Cruickshank was not considered during the original prosecution and is not cumulative of any prior art considered by the examiner(s). Exhibit 1021 U.S. Patent No. 6,975,619 to Byers et al. ( Byers ) issued on December 13, 2005, based on Application Serial No. 09/528,572, filed on March 20, 2000, which is prior to the earliest filing date claimed by the 572 patent (December 29, 2000). Byers is prior art under pre-aia 35 U.S.C. 102(e). Byers 3

8 was not considered during the original prosecution of the 572 patent and is not cumulative of any prior art considered by the examiner(s). B. Grounds for Challenge Petitioner requests cancellation of challenged claims under the following statutory grounds: i. Claims and 20 are anticipated by Byers ii. Claims 19 and 20 are rendered obvious by Byers in view of Mottishaw; iii. Claims and 20 are anticipated by Fobert; iv. Claim 19 is rendered obvious by Fobert in view of Mottishaw; v. Claims are anticipated by Matsumoto; vi. Claim 19 is rendered obvious by Matsumoto in view of Mottishaw; vii. Claims and 20 are anticipated by Cruickshank; and viii. Claim 19 is rendered obvious by Cruickshank in view of Mottishaw; Section VI below demonstrates, for each of the statutory grounds, that there is a reasonable likelihood that Petitioner will prevail. See 35 U.S.C. 314(a). Additional explanation and support for each ground of rejection is set forth in the Expert Declaration of Professor Vijay K. Madisetti (Exhibit 1007). IV. BACKGROUND OF THE 572 PATENT A. Technology Background Relevant to the 572 Patent 4

9 1. Call Trace Features Long before phone calls were made over packet-switched networks such as the Internet, they were made using the Public Switched Telephone Network (PSTN). (Ex. 1007, 36.) The PSTN existed in various forms since the late nineteenth century. (Ex. 1007, 36.) For nearly half a century prior to the filing date of the 572 Patent, it was well known that one could trace a call on a PSTN network to obtain information about a caller, such as their location or phone number. (Ex. 1007, 36.) This ability to trace a call was widely discussed both in technical circles and in popular culture. (Ex. 1007, 36.) In fact, call traces were so prevalent by the mid-1980s that Congress enacted statutory regulations restricting the widespread practice. (Ex. 1007, 36; Ex ) The benefits of being able to trace calls were well-documented long before the 572 Patent was filed. For example, call trace features served as a deterrent to harassment from crank callers. (Ex. 1007, 37; see also Ex. 1027, p. 10.) Call trace features also provided emergency responders with valuable location information. (Ex. 1007, 37; see also Ex ) By 1996 that the FCC required mobile networks to provide the same location-based trace services that wireline networks were already providing for E911 services effectively extending this trace feature from wireline to wireless networks. (Ex. 1007, 37.) In addition, caller ID services were well-known by the mid-1990s on PSTN networks, to 5

10 provide the name or number of a caller on a display of a called party s phone. (Ex. 1007, 37; see also Ex ( Caller ID feature operated by displaying the phone number of an incoming call on a screen at the recipient s phone while it is ringing. ); Ex (describing call trace features on PSTNs in 1989).) 2. Packet-Based Telephony By 2000, the Internet was already a popular delivery mechanism for voice calls, and a variety of Internet telephone services were already being offered. (Ex. 1007, ) The 572 Patent explicitly admits this: it states that Support for end-to-end voice calls using the Internet as an alternative to traditional public switched telephone networks (PSTN) is well known. (Ex at 1:13 15 (emphasis added).) As the patent recognized, packet-switched telephony was already a well-understood technique, and Voice over IP (VoIP) which the patent describes as encoded digitized voice that is packetized and communicated over the Internet for telephone-like communication was already in widespread use. (Id. at 1:23 26; see also Ex. 1007, ) 3. Network Analysis Tools Long before the 572 patent was filed, tools such as ping and traceroute provided information about a remote host, or the communication route to that host. As the Examiner noted, the ping tool was typically used to determine if a path exists between two hosts, and was usually implemented using the ICMP ECHO 6

11 facility, or ICMP echo request packets. (Ex. 1002, 35.) Traceroute, the Examiner explained, shows an actual path by transmitting a series of probe packets with increasing TTL values to a destination host. (Id.) These probe packets are a UDP datagram encapsulated into an IP packet. (Id.) Each hop in a path to the target (destination) host... returns an ICMP message that is used to discover the hop and to calculate a round trip time. (Id.) As further explained in TCP/IP Illustrated, cited in the file history, Traceroute lets us see the route that IP datagrams follow from one host to another. (Ex at p. 97.) The Examiner recognized that ping and traceroute tools were two very useful functions for managing networks, and that these tools could trace the path of a VoIP call: it is well known that tracing a call (path/route that call takes place on) can be achieved using the Internet Control Message Protocol (ICMP) or UDP packets. (Ex at ) The specification agrees, stating that in the preferred embodiment, [t]he implementation of this call trace feature uses ping and net trace tools. (Ex at 3:53-54; see also id. at 3:62 4:1.) B. Overview of the 572 Patent The 572 Patent discloses a very predictable idea: make Internet telephony more like traditional PTSN telephony, by giving VoIP phone users the trace features already available on circuit-switched phone networks. According to the 572 Patent, these popular trace features were not yet available by 2000 on VoIP 7

12 telephones: Users of VoIP devices currently are not provided with call trace information. (Ex at 1:36 38.) According to the 572 Patent, traditional trace features were just as useful for packet-switched phone calls as they were for circuit-switched phone calls: it would be useful for emergency E911 (electronic 911) service to help emergency personnel determine critical information about an IP client in advance of rendering emergency service, and [s]uch call trace information would also be useful for tracking down and apprehending prank callers who use VoIP. (Id. at 1:39 44.) The specification s description of the alleged invention is quite short; the patent relies on the well-known nature of the claim elements to provide the necessary details. According to the patent, call trace information is provided by (1) requesting information pertaining to the end-point device of a caller or called party, (2) receiving the requested call trace information, and (3) displaying at least a portion of the received call trace information. (Id. at 3:10 28.) Figure 1 (the only figure in the patent) depicts voice communication devices A, B, C, D, and E which participate in voice communications over a packet switched network. (Ex. 1001, 2:46 49.) The call trace information returned by these devices may include, but is not limited to, information about the parties to the call, the devices used by those parties, or the route taken by the call. (Id. at 2:10 19.) C. Prosecution History of the 572 Patent 8

13 The application that matured into the 572 patent, U.S. Patent Application No. 09/751,796 ( the 796 application ), was filed on Dec. 29, In a non-final office action mailed on June 1, 2004, the examiner rejected claims 1 24 of the 796 application over U.S. Patent No. 6,721,284 ( Mottishaw ) and rejected claims 25 and 26 of the 796 application over the combination of Mottishaw and U.S. Patent No. 6,681,232 ( Sistanizadeh ). (Ex at ) On October 1, 2004, the applicants amended the independent claims from stating provide an indication of the call trace information that was received to state display at least a portion of the call trace information that was received. (Id. at ) Additionally, applicants argued that the cited prior art did not teach the display aspect of the claimed invention. (Id. at ) However, in so arguing, applicants admitted that Mottishaw logs and stores the call trace information. (See id. at 70 ( in Mottishaw the Data Management Infrastructure (DMI) is responsible for the storage of the service detail records ).) In a final office action dated December 2, 2004, the examiner again rejected all claims as obvious in view of Mottishaw and the combination of Mottishaw and Sistanizadeh. The examiner rejected the applicants arguments, stating that it is obvious that the trace data that is collected can be displayed. (Id. at 47.) On March 2, 2005, the applicants further amended the independent claims to require dynamically display at least a portion of the call trace information 9

14 received. (Id. at ) The applicants argued that the 572 patent dynamically displayed trace results, whereas Mottishaw, while capable of displaying such information, did not do so automatically. (Id. at ) Based on this amendment, the examiner allowed the application. V. CONSTRUCTION OF THE CHALLENGED CLAIMS In an inter partes review, claim terms in an unexpired patent are interpreted according to their broadest reasonable interpretation ( BRI ) in view of the specification in which they appear. 37 C.F.R (b); Office Patent Trial Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012). The USPTO uses BRI because, among other reasons, the patentee has the opportunity to amend its claims in this proceeding. See, e.g., Office Patent Trial Practice Guide, 77 Fed. Reg. 48,764 (Aug. 14, 2012) ( Since patent owners have the opportunity to amend their claims during IPR, PGR, and CBM trials, unlike in district court proceedings, they are able to resolve ambiguities and overbreadth through this interpretive approach, producing clear and defensible patents at the lowest cost point in the system. ). Thus, as required by the rules, this Petition uses the BRI standard. A. call trace information Petitioner has filed two petitions challenging the validity of claims of the 572 patent. These two petitions propose different grounds, based on different interpretations of the phrase call trace information as used in claims

15 In this petition, Petitioner proposes what Petitioner believes to be the BRI for call trace information. In the other petition, Petitioner presents Patent Owner s apparent position on the BRI for call trace information, based on Patent Owner s statements regarding the alleged scope of the claims in Patent Owner s infringement contentions in Google Inc. v. Rockstar Consortium US LP et al., Case No. 4:13-cv CW (N.D. Cal.) (Ex. 1020). Claims use the term call trace information. The specification teaches that the 572 patent is directed to calls taking place over a packet-switched network such as the Internet: end-to-end voice calls using the Internet as an alternative to traditional public switched telephone networks (PSTN) is well known. (Ex. 1001, 1:13 16.) Such calls are accomplished using Voice over Internet Protocol (VoIP), which is encoded digitized voice that is packetized in accordance with IP, and communicated over the Internet for telephone-like communication. (Id. at 1:24 26.) Users make these calls using various network compatible devices, such as telephone sets, personal digital assistants, soft phones and the like. (Id. at 1:9 11.) Figure 1 (the only figure in the patent) depicts voice communication devices A, B, C, D, and E which participate in voice communications over a packet switched network. (Ex. 1001, 2:46 49.) The specification provides a non-exclusive list of information about a VoIP call that might be obtained as trace information, including the call route and the 11

16 topology of the route, the directory number and name, and the call back number for the user. (Ex. 1001, 2:10 19.) As described above, at the alleged time of invention, call trace had a wellknown meaning for calls placed on traditional public switched telephone networks. For example, Webster s Telecom Dictionary teaches that call trace is a feature that enables the subscriber to initiate a trace on the last call received. (Ex. 1030, p. 121.) Similarly, Newton s Telecom Dictionary teaches that call trace is a service which permits the tracing of the last call received.... (Ex. 1031, p. 142.) One of ordinary skill in the art would understand that the 572 patent uses the term call trace in the same fashion. The patent specification confirms that the claimed call trace is the packet-switched analog to earlier, well-known PSTN call trace features. See, e.g., Ex at 1:43 45 ( call trace information would also be useful for tracking down and apprehending prank callers who use VoIP ); id. at 3:21 22 ( call trace information is provided at the user s VOIP or TDM device ); id. at 3:40 44 ( In the case of a conference call, the invention may provide: a feature that enables the call trace information for each of the conferees to be delivered back to the originator of the conference call ). Moreover, the call trace feature is invoked by making queries to an Internet Protocol based Private Branch Exchange (IP-PBX) call manager, which is the packet switched equivalent to a traditional PBX telephone exchange. (Id. at 4:4 8.) Accordingly, a person of 12

17 ordinary skill in the art would consider the broadest reasonable interpretation in light of the specification and prosecution history of call trace information to be information provided by the tracing of a telephony session. (Ex. 1007, ) B. Other Terms The BRI of claim terms here may be different from the construction that those same terms may receive following claim construction proceedings in district court. See, e.g., In re Trans Texas Holdings Corp., 498 F.3d 1290, 1297 (Fed. Cir. 2007). Thus the claim constructions presented in this Petition, including where Petitioner does not propose an express construction, do not necessarily reflect the claim constructions that Petitioner believes should be adopted by a district court under Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005). In presenting this Petition, unless otherwise stated, the grounds set forth herein are based on (1) the proposed claim construction offered by the Patent Owner in Google Inc. v. Rockstar Consortium US LP et al., Case No. 4:13-cv CW (N.D. Cal.) (Ex. 1037), or (2) for terms where Patent Owner has not explicitly offered a claim construction, on petitioner s understanding of Patent Owner s infringement contentions in Google Inc. v. Rockstar Consortium US LP et al., Case No. 4:13-cv CW (N.D. Cal.) (Ex. 1020). In presenting the grounds set forth in this Petition, petitioner does not concede that any claim constructions impliedly or expressly proposed by Patent Owner are appropriate for the district court litigation, 13

18 where a different legal standard applies to the construction of the asserted claim terms. Petitioner does not believe that many of the Patent Owner s implied or express proposed constructions are appropriate under Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005). Instead, petitioner presents these proposed constructions to the Board for consideration in determining the BRI because Patent Owner considers these constructions correct under Phillips, and therefore necessarily also considers them within the appropriate scope of the BRI. Petitioner further submits these constructions under 35 U.S.C. 301(a)(2), which encourages submission of claim construction materials to prevent patentees from arguing broad constructions under Phillips while simultaneously arguing narrow constructions as the BRI. 1. dynamically displaying Claim 17 recites the dynamically displaying claim term. During prosecution, the applicant argued that: The present invention on the other hand discloses a dynamic monitoring system where once the call trace information is received it is then displayed without requiring further interaction. Consequently, the present invention distinguishes over Mottishaw since it deals with an entirely different monitoring system. Although the word dynamic was not in the original claims, it is inherent that the present invention is not a passive device since the 14

19 claims do not recite an intermediate step between receiving and displaying the call trace information. (Ex. 1002, p ) As the applicant admitted, dynamic display is inherent where a display function is described without reciting an intermediate step between receiving and displaying call trace information. (Id.) Accordingly, a person of ordinary skill in the art would consider the broadest reasonable interpretation in light of the specification and prosecution history of dynamically displaying to be displaying without requiring further user interaction. (Ex. 1007, 58.) 2. logging the call trace information Claim 19 recites the logging the call trace information claim term. The specification states that [a]n intelligent call log capability may be activated to log all of this call trace information for security or network performance analysis. (Ex. 1001, 3:46 48.) The term logging has a well-known meaning to one of ordinary skill in the art that is consistent with the use of the term in the specification. (Ex. 1007, ) Accordingly, a person of ordinary skill in the art would consider the broadest reasonable interpretation in light of the specification and prosecution history of logging the call trace information to be recording call trace information over time. (Ex. 1007, ) 15

20 3. storing Claim 20 recites the storing claim term. The specification states that [m]ost of the call trace information is configured at the time of registration for the VoIP device and stored in a variety of locations or centralized directory and may be accessed using Local Directory Application Protocol (LDAP). (Ex. 1001, 4:8 11.) The specification further teaches that some call trace information is stored in a call server data base while other call trace information is stored in a data network server. (Ex. 1001, 4:17 21.) Storing (and variants thereof) is used in the specification and prosecution history according to its plain and ordinary meaning. (Ex. 1007, 63.) Accordingly, a person of ordinary skill in the art would consider the broadest reasonable interpretation of storing to be saving in temporary or persistent memory. (Ex. 1007, 63.) VI. IDENTIFICATION OF HOW CHALLENGED CLAIMS ARE UNPATENTABLE Pursuant to Rule (b)(4) (5), this section demonstrates that the challenged claims are unpatentable. A. Claims 17, 18, and 20 are anticipated by Byers 1. Byers Byers discloses [a] geographic location identification system wherein, [u]pon a request from a requesting node, the geographic location information of one or more target nodes is provided to the requesting node. (Ex. 1021, Abstract.) 16

21 Byers did so using well-known ping and traceroute tools (Ex at 2:44 49; 4:44 57) the same network trace tools described in the 572 Patent. (Ex at 4:53 54.) Byers states that the resulting VoIP trace features mirror trace features already known on PSTN networks to packet-switched networks: as packet data networks were now being used for voice telephony applications, it would be desirable to implement a caller location feature that advises a called party of a calling party s geographic location, including to improve emergency response services for packet-based telephony. (Ex at 1:35 38, 5:39 57, Figs. 3 & 5.) As shown in Fig. 3, Byers discloses such an emergency response center. Byers discloses nodes 4 and 6, each node comprised of a data terminal and an optional telephone device. (Id. at 3:29 40.) In Fig. 3, the target node 4 and the requesting node 6 are engaged in a packet telephony communication session. (Id. at 5:40 41.) Requesting node 6 (network compatible device) generates a request for the geographic location (call trace information) of target node 4 (end-point device). (Id. at 5:46 49, 6:5 7, 6:31 34.) The target node s geographic location information is retrieved and returned to the requesting node. (Id. at 5:49 54, 6:7 9, 6:12 18, 6:34 40.) Upon receipt by the requesting node, the requesting node s data terminal dynamically displays the call trace information, i.e., the geographical location information. (Id.) The call trace information is 17

22 stored and subsequently retrieved from data store 22 that holds routing tables, host identification tables, and other network-related information. (Id. at 4:5 14.) 2. Claim Charts Claim 17. Byers (Ex. 1021) Claim 17. [17A] A method that obtains call trace information, comprising: Byers discloses a method that obtains call trace information, namely a geographic location identification system and method for a packet data network... wherein geographic location information is provisioned or derived at nodes that comprise the network. (Ex. 1021, Abstract.) [17B] communicating over a packet switched network between a network compatible device and an endpoint device, See also Ex. 1007, 65. Byers communicates between nodes on a packet switched network. FIG. 1 illustrates an exemplary packet data network 2 providing support for packet data communication between network nodes (also known as hosts ) 4 and 6. The packet data network 2 could be any conventional packet data network or inter-network, such as a private LAN (Local Area Network) or WAN (Wide Area Network), or the public Internet. (Ex. 1021, 3:31 36.) (Ex. 1021, Figure 1.) FIG. 3 represents an embodiment of the invention wherein the target node 4 and the requesting node 6 are engaged in a packet telephony communication session. 18

23 Claim 17. Byers (Ex. 1021) (Ex. 1021, 5:39 41.) (Ex. 1021, Figure 3.) [17C] generating a request for call trace information that pertains to the endpoint device, See also Ex. 1007, 66; Ex. 1021, 3:47 50; 4:34 56; 5:61 63; Figs. 4, 5.) A node generates a request for call trace information pertaining to another node. When the calling party initiates the communication session, the emergency response application 40 causes the data terminal 12 to send a geographic location request to the target node 4. Thus, as the calling party converses with the called party, the called party can determine the calling party s geographic location from the interface 42. (Ex. 1021, 5:46 57.) (Ex. 1021, Figure 3.) [17D] subsequently See also Ex. 1007, 67 68; Ex. 1021, 1:51 2:16; 2:30 34; 4:34 56, 5:36 40; Figs. 4, 5. The requesting node receives call trace information. 19

24 Claim 17. Byers (Ex. 1021) receiving the call trace information that was requested, and [17E] dynamically displaying at least a portion of the call trace information that was received. The geographic location information is provided in response packets sent back to the requesting node. (2:35-36.) In response to the request, the geographic location information provided in the response is passed to the emergency response application 40, which processes the information and displays it on a graphical user interface 42. (Ex. 1021, 5:51 54.) See also Ex. 1007, 67 68; Ex. 1021, 4:61 5:3; 6: The requesting node dynamically displays the received call trace information. In response to the request, the requesting node displays the call trace information without requiring further user interaction: geographic location information provided in the response is passed to the emergency response application 40, which processes the information and displays it on a graphical user interface 42. (Ex. 1021, Fig. 3, 5:51 54.) As applicants admitted, dynamic display is inherent as Byers does not recite an intermediate step between receiving and displaying the call trace information. (Ex. 1002, p. 35.) The geographic location information provided in the responses is passed to the network management server application 60, which processes the information and 20

25 Claim 17. Byers (Ex. 1021) displays it on the graphical user interface 62. (Ex. 1021, Fig. 5, 6:36 40.) See also Ex. 1007, 67 68; Ex. 1021, 6:13 22; 6: Claim 18. Byers (Ex. 1021) Claim 18. [18A] A See Claim 17. method as in claim 17, [18B] wherein the call trace information is selected from a group consisting of an Internet Protocol (IP) address, a geographical location of the endpoint device, a type or class of the end-point device, a call route, a topology of the route, a domain name server of the IP address and route, a directory number and name, a call back number, an advisement as to whether the IP address for the end-point device is mobile and an advisement as to Byers discloses call trace information including at least the geographical location of the end-point device, a topology of the route, and the callback number and name of the caller. The geographic location information 20 identifies the geographic location of the node at which it is provisioned or derived. This information may include latitude, longitude and altitude, and/or address information such as Country, State, City, Street and Floor or Suite number. (Ex. 1021, 4:5 10.) Thus, the network administrator is provided with accurate information about the topology of the packet data network 2. This can help the network administrator visualize network problems. By way of example, the geographic location of a heavily congested link 64 in the packet data network 2 is shown. (Ex. 1021, 6:40 45.) 21

26 Claim 18. Byers (Ex. 1021) what redirection may have occurred before the call was completed. (Ex. 1021, Figure 5.) See also Fig. 3 & Ex. 1007, Claim 20. Byers (Ex. 1021) Claim 20. [20A] A See Claim 18. method as in claim 18, [20B] further Geographic information is stored and displayed. comprising storing the call trace information. See Claim 17. The geographic location information 20 identifies the geographic location of the node at which it is provisioned or derived. This information may include latitude, longitude and altitude, and/or address information such as Country, State, City, Street and Floor or Suite number. If the geographic location information is provisioned, it can be maintained in the usual data store 22 that holds routing tables, host identification tables, and other networkrelated information 24. (Ex. 1021, 4:6 13.) See also Ex. 1007, 69. B. Claims 19 and 20 are rendered obvious by Byers in view of Mottishaw 22

27 1. Obviousness Arguments Claim 19 depends from claim 18, and recites logging the call trace information. It would have been obvious to a person of ordinary skill in the art at the time of the 572 patent priority date to combine Byers with the teaching of Mottishaw. (Ex. 1007, ) Mottishaw discloses a method and apparatus for generating service detail records, and to monitoring systems for collecting data for these records from a network, such as a packet data network, which is used for example to carry multimedia telephony services. (Ex. 1004, 1:5 9.) Specifically, Mottishaw discloses a Data Management Infrastructure (DMI) that sends out probes which collect call trace information. (Id. at 3:54 57.) The DMI collects data from the probes and processes the data to produce service detail records. (Id. at 3:48-50.) These records provide a record or real-time trace of calls, transactions and other services as they occur on the network. (Id. at 3:42 44.) [T]he DMI is also responsible for the storage of the service detail records and for providing interfaces for application programs to analyze the service detail records. (Ex at 3:63 65.) During prosecution of the 572 patent, the Examiner found that Mottishaw discloses database and call logs (e.g., DMI Figs. 1-2, col. 3, lines 48-67; col. 5, lines 25-44; col. 4, lines 30-42; col. 2, lines 16-20; Fig. 4). (Ex at 45.) 23

28 Both Byers and Mottishaw are from the same field of endeavor: network management tools, including for telephony networks. Compare Ex. 1021, 6:25 31 ( a network manager server application 60 that is used by a network administrator... which the network administrator uses to perform network load balancing or make determinations about the deployment of additional network resources ) with Ex. 1004, 1:5 9 ( method and apparatus for generating service detail records, and to monitoring systems for collecting data for these records from a network, such as a packet data network, which is used for example to carry multimedia telephony services. ); (Ex. 1007, 74.) Because both Byers and Mottishaw concern network management tools for telephony networks one of ordinary skill would have looked to Mottishaw for beneficial teachings relevant to Byers. (Ex. 1007, 74.) Mottishaw teaches numerous benefits of logging call trace information in a telephony network. First, Mottishaw teaches that its service detail records can be used for applications such as troubleshooting, surveillance, security, network planning, provision of accounting information to customers, fraud detection, billing and acquisition of marketing information. (Ex. 1004, 3:30 33.) The records can also be used to provide service quality information on selected customer's service. This can be used to track conformance to service level agreements, and be provided to the customer as an additional service. (Id. at 8:11 14.) These benefits would be 24

29 readily apparent to one of skill in the art, and are also explicitly laid out in greater detail in Mottishaw. (Id. at 8:5 60.) In addition, one of ordinary skill would have been aware of logging as a widely used tool in many computer and network systems. Logging was (and is) a classic tool for analyzing computer networks, and one of skill would have understood it had a variety of uses. (Ex. 1007, 76 (citing Usability Engineering (Ex. 1024) and Managing IP Networks (Ex. 1025)).) For example, one of ordinary skill would understand that logging is a useful tool to address network failures, analysis of user activity, and optimization of network resources. (Ex. 1007, 76; see also Usability Engineering (Ex. 1024) ( Logging the user s actual use of the system is particularly useful because it shows how users perform their actual work and because it is easy to automatically collect data from a large number of users working under different circumstances. ); Managing IP Networks (Ex. 1025) ( Logging is probably one of the most useful diagnostic tools available... [b]ecause a network is a large and dynamic entity, it is often difficult to get a clue where to start looking when things break, or what might be the cause of a failure. ).) Including Mottishaw s logging feature in Byers s VoIP system would be well within the technical skill of one of ordinary skill in the art. (Ex. 1007, 77.) For example, Byers teaches a network manager server application 60 that is used 25

30 by a network administrator. (Ex. 1021, 6:25 26.) Byers also teaches network node[s] that include data terminal[s]. (Ex. 1021, 3:37 38, 5:39 44, Figs. 1 5.) Adding logging functionalities to either the server application or data terminals would present no great technical challenges, and would not negatively impact the functionality of Byers s telephony system. (Ex. 1007, 77.) Thus, it would have been obvious to a person of ordinary skill in the art at the time of the 572 patent s priority date to combine the teaching of Byers with Mottishaw to incorporate the logging feature of Mottishaw into Byers s packet switched telephony network. (Ex. 1007, 77.) 2. Claim Charts Claim 19. Byers (Ex. 1021) in view of Mottishaw (Ex. 1004) Claim 19. [19A] See Section VI.A, Claim 18. A method as in claim 18, [19B] further Mottishaw logs call trace information in the form of comprising service detail records. logging the call trace information. As the Examiner found during prosecution, Mottishaw discloses logging call trace information, including database and call logs (e.g., DMI Figs. 1-2, col. 3, lines 48-67; col. 5, lines 25-44; col. 4, lines 30-42; col. 2, lines 16-20; Fig. 4). (Ex at 45.) In addition, the packets associated with a conference call can be correlated together to form a service record for a conference call. (Ex. 1004, 2:16 19.) A principal function of this software is to correlate data from different probes to provide a record or real-time 26

31 Claim 19. Byers (Ex. 1021) in view of Mottishaw (Ex. 1004) trace of calls, transactions and other services as they occur on the network.. (Ex. 1004, 3:41 44.) A Data Management Infrastructure (DMI) collects the data from the probes and processes the data to produce service detail records. (Ex. 1004, 3:48 50.) [T]he DMI is also responsible for the storage of the service detail records and for providing interfaces for application programs to analyse the service detail records. This aspect of the DMI may be implemented using data warehousing technology. (Ex. 1004, 3:62 67.) (Ex. 1004, Fig. 4.) See Ex. 1004, Figs. 1 & 2, 3:41 67; 5:25 44, 4:30 42, 5:45 6:18; see also Ex. 1007, Claim 20. Byers (Ex. 1021) in view of Mottishaw (Ex. 1004) Claim 20. [20A] A See Section VI.A, Claim 18. method as in claim 18, [20B] further comprising See Section VI.A, Claim 20. storing the call trace information. Mottishaw stores call trace information in the form of service detail records. See Claim 19. (Ex. 1004, 3:41 67, 5:25 44.) See also Ex. 1007,

32 C. Claims are anticipated by Matsumoto 1. Statement of Non-redundancy The grounds raised in the following sections are meaningfully distinct from those above and rely upon a different prior art reference. The grounds detailed in Sections VI.A and VI.B rely upon Byers as the primary reference. The grounds detailed in Sections VI.C and VI.D rely upon Matsumoto as the primary reference. Whereas the grounds detailed in Sections VI.A and VI.B describe a group of network nodes that comprise the packet data network, each node with the ability to determine its own geographic location information and provide that information in response to a request from a requesting node (Ex. 1021, 1:51 64), the grounds detailed in Sections VI.C and VI.D describe communication between at least two VoIP terminals, wherein call trace information is exchanged directly between terminals (Ex. 1005, 4:1 7, Figure 1). As Patent Owner may attempt to distinguish elements of the challenged claims based upon purportedly unique claim features, which are clearly described by Matsumoto, all grounds should be included for trial. Additionally, in the pending litigation Patent Owner asserted that: U.S. Patent No. 6,937,572 is entitled to a priority date of March 19, (Ex. 1032, p. 2.) Petitioner does not agree with the Patent Owner s claims of priority; however, if Patent Owner is successful in showing its alleged early conception 28

33 date, and is further successful in demonstrating the requisite diligence for its alleged priority date, and successfully shows it was first to invent the claimed subject matter, the ground raised below with respect to Matsumoto would not be redundant of the grounds raised in Sections VI.A through VI.B with respect to Byers. 1 Accordingly, all grounds should be included for trial. 2. Matsumoto Matsumoto discloses [a] caller information display system for VoIP terminals. (Ex. 1005, Abstract.) Specifically, [t]he present invention makes it possible to pass information and display it on terminals by using VoIP technology for transmitting/exchanging caller information held in each in a call setup procedure when a telephone conversation begins. (Id. at 4:1 7.) In one embodiment, a first terminal sends an information request message to a second terminal. (Id. at 12:19 23.) The first terminal monitors for call trace information in response, and when that information is received, the terminal dynamically displays it on display unit 14. (Id. at 12:19 26; Figure 11 at S11.) The terminal then logs and stores the end-point device s call trace information in reception caller information storage unit 17. (Id. at 7:14 16.) In addition to each terminal storing 1 Petitioner reserves the right to assert Byers as prior art under 35 U.S.C. 102(g) even if Patent Owner establishes a priority date of March 19,

34 call trace information (id. at 6:10 12; 6:66 7:2), database 33 stores the terminals call trace information (id. at 8:51 67). 3. Claim Charts Claim 17. Matsumoto (Ex. 1005) Claim 17. [17A] A method that obtains call trace information, comprising: [17B] communicating over a packet switched network between a network compatible device and an end-point device, Matsumoto discloses a method that obtains call trace information, namely a caller information display system [, which includes] a caller information transmission and reception control unit which controls transmission and reception of caller information when a call is made and received. (Ex. 1005, Abstract.) See also Ex. 1007, 80. Matsumoto discloses terminals communicating over a packet switched network. Network 2 may be a LAN, intranet, Internet, or other IP network that performs data communication using IP addresses and also performs telephone conversations by VoIP (a network that carries out call control of the network layer by an Internet protocol) terminal 1a is on the calling side and terminal 1b is on the called side. (Ex. 1005, 6:1 10, Figure 1.) (Ex. 1005, Figure 1.) FIG. 27 shows the operation sequence according to this 30

35 Claim 17. Matsumoto (Ex. 1005) invention, from making a call until conversation-in-progress. In the example shown in this FIG. 27, we describe the operation sequence from making a call until conversation-inprogress when the operator of terminal 1 initiates a telephone call, taking terminal 1 as the calling side and terminal 2 as the called side. (Ex. 1005, 18:32 38.) [17C] generating a request for call trace information that pertains to the end-point device, (Ex. 1005, Figure 27.) See also Ex. 1007, Matsumoto discloses generating requests in the form of ACK or information request messages. Terminal 1 transmit[s] to the other terminal an ACK message requesting transmission of the caller information. (Ex. 1005, 18:65 19:3, Figure 27.) The caller information transmission and reception control unit (16 in FIG. 2) transmits to the other terminal an information request message to transmit the caller information (S8 in FIG. 13.) (Ex. 1005, 12:20 23, Figure 13.) 31

36 Claim 17. Matsumoto (Ex. 1005) (Ex. 1005, Figure 13.) An information request message is transmitted so that the caller information transmission and reception control unit transmits the caller information to the other terminal (S10 in FIG. 14). (Ex. 1005, 12:55 58, Figure 14.) [17D] subsequently receiving the call trace information that was requested, and (Ex. 1005, Figure 14.) See also Ex. 1007, 82. Matsumoto receives and processes the information that is returned in response to an ACK or information request message. Terminal 1, which receives the caller information of terminal 2 and a callout-in-progress message, performs a callout-inprogress display on the display, together with the caller information of terminal 2 (S16 in FIG. 27). (Ex. 1005, 19:25 28.) The caller information transmission and reception control unit (16 in FIG. 2) transmits to the other terminal an information request message to transmit the caller information (S8 in FIG. 13), and one monitors that the caller information is received from the calling terminal (S9); if it is received, one jumps to the processing of S11 in aforesaid FIG. 11 and performs the subsequent processing. (Ex. 1005, 12:20 26, Figure 13.) 32

37 Claim 17. Matsumoto (Ex. 1005) An information request message is transmitted so that the caller information transmission and reception control unit transmits the caller information to the other terminal (S10 in FIG. 14), and one monitors the reception of caller information from the other terminal (S11); if it is received, one jumps to step S7 of the processing flow (FIG. 12). (Ex. 1005, 12:55 60, Figure 14.) [17E] dynamically displaying at least a portion of the call trace information that was received. See also Ex. 1007, 82. Matsumoto dynamically displays at least a portion of the received call trace information. Terminal 1, which receives the caller information of terminal 2 and a callout-in-progress message, performs a callout-inprogress display on the display, together with the caller information of terminal 2 (S16 in FIG. 27). (Ex. 1005, 19:25 28, Fig. 25A.) (Ex. 1005, Fig. 25A.) As applicants admitted, dynamic display is inherent as Matsumoto does not recite an intermediate step between receiving and displaying the call trace information. (Ex at 35.) If caller information is received from the other terminal, next it is decided whether a callout-in-progress message has been received from the other terminal (S10 in FIG. 11); when it is received, callout-in-progress is displayed, together with the caller information of the other terminal that has been received. (Ex. 1005, 10:65 11:4, Figure 11.) 33

38 Claim 17. Matsumoto (Ex. 1005) (Ex. 1005, Fig. 11.) See Ex. 1005, 12:25 31, Fig. 12; See also Ex. 1007, 82, 85. Claim 18. Matsumoto (Ex. 1005) Claim 18. [18A] A See Claim 17. method as in claim 17, [18B] wherein the call Matsumoto discloses at least the following call trace trace information is information: (1) the IP address information of terminal selected from a group 2 (Ex. 1005, 18:52 58, Figure 24); (2) address, i.e., the consisting of an geographical location of the end-point device; (3) Internet Protocol (IP) telephone number and portable telephone number, address, a geographical i.e., a call back number; and (4) name. (Ex. 1005, 17:57 location of the endpoint device, a type or 18:2, Figure 24, Figure 25A.) class of the end-point device, a call route, a topology of the route, a domain name server of the IP address and route, a directory number and name, a (Ex. 1005, Figure 24.) call back number, an advisement as to whether the IP address for the end-point device is mobile and an advisement as to what redirection may (Ex. 1005, Figure 25A.) have occurred before the call was completed. See also Ex. 1007,

39 Claim 19. Matsumoto (Ex. 1005) Claim 19. [19A] See Claim 18. A method as in claim 18, [19B] further comprising logging the call trace information. Call trace information regarding another terminal is logged in a reception caller information storage unit. A reception caller information storage unit, indicated by 17, is provided that stores caller information received from the other terminal. (Ex. 1005, 6:67 7:2.) In FIG. 2, it is assumed that previously communicated caller information from the other terminal is stored in reception caller information storage unit 17. (Ex. 1005, 7:14 16.) Matsumoto logs the time that call trace information is updated. In Figure 2, provided within a caller information storage unit 15, which stores information on the caller of the local terminal, is time management unit 150, which indicates the update time (date and time of day) of the caller information; provided within reception caller information storage unit 17 is a time management unit 170, which stores the update date and time of day of the caller information received from the other terminal. (Ex. 1005, 7:2 9.) (Ex. 1005, Figure 2.) Whenever call trace information pertaining to any 35

40 Claim 19. Matsumoto (Ex. 1005) terminal is updated, Matsumoto logs this most recent update in a database server. In the system of FIG. 6, when the caller information stored in each terminal is updated, the shared database server 3 is called out from communication interface 12 using the server address previously stored, by setting, etc., in server address storage unit 21, and when the caller information is transferred, data updating unit 31 is activated from communication control unit 30 and updates database 30. This database is able to share between the terminals the latest caller information at all times. (Ex. 1005, 9:1 9.) See also (Ex. 1005, 3:57 59.) See also Ex. 1007, Claim 20. Matsumoto (Ex. 1005) Claim 20. [20A] A See Claim 18. method as in claim 18, [20B] further See Claim 19. comprising storing the call trace information. The user terminal stores and displays call trace information. See Claim 17. Matsumoto discloses that information and software programs stored in memory are utilized for display operations. (See, e.g., Ex at 9:44 10:27, Fig. 8.) Thus, in the particular architecture disclosed by Matsumoto, display of the call trace information necessarily requires that it be stored in user terminal memory. Ex. 1007, D. Claim 19 is rendered obvious by Matsumoto in view of Mottishaw 36

41 1. Obviousness Argument Claim 19 depends from claim 18, and recites logging the call trace information. Data logging, including logging of call trace information, was well known prior to March 18, 2000, the alleged conception date of the 572 Patent. (Ex. 1007, ) It would have been obvious to a person of ordinary skill in the art at the time of the 572 patent priority date to combine Matsumoto with the logging system disclosed in Mottishaw (described in detail above at pages 23 26). (Ex. 1007, ) Both Matsumoto and Mottishaw are from the same field of endeavor: telephony voice calls over a packet switched network. Compare Ex. 1005, Abstract ( voice communication and data communication can be done between multiple terminals over a network following an Internet protocol ) with Ex. 1004, 1:5 9 ( method and apparatus for generating service detail records, and to monitoring systems for collecting data for these records from a network, such as a packet data network, which is used for example to carry multimedia telephony services. ); (Ex. 1007, 89.) Because both Matsumoto and Mottishaw concern telephony calls over a packet switched network one of ordinary skill would have looked to Mottishaw for beneficial teachings relevant to Matsumoto. (Ex. 1007, 90.) As explained more fully above, Mottishaw teaches numerous benefits of logging call trace information in a telephony network. (Supra at pp ; Ex. 37

42 1007, 90.) In addition, as explained above, one of ordinary skill would have been aware of logging as a widely-used tool with a variety of uses. (Supra at p. 25; Ex. 1007, 91.) Adding Mottishaw s logging of call trace information to Matsumoto s telephony system would be well within the technical skill of one of ordinary skill in the art. (Ex. 1007, 92.) Matsumoto teaches a centralized Communication Control Unit 30 which facilitates storage of data from various communication terminals. (Ex. 1004, 8:64 9:13.) Matsumoto also teaches communication terminals which include a CPU and has information processing functions by programs. (Id. at 5:51 55.) Addition of well-understood data logging functionalities to the centralized Communication Control Unit 30 or the communication data terminals would present no great technical challenges, and would not negatively impact the functionality of Matsumoto s telephony system. (Ex. 1007, 92.) Thus, it would have been obvious to a person of ordinary skill in the art at the time of the 572 patent s priority date to combine the teaching of Matsumoto with Mottishaw to incorporate the logging feature of Mottishaw into Matsumoto s packet switched telephony network. (Ex. 1007, ) 2. Claim Charts Claim 19. Matsumoto (Ex. 1005) in view of Mottishaw (Ex. 1004) Claim 19. [19A] See Section VI.C, Claim 18. A method as in claim 18, [19B] further Call trace information regarding another terminal is 38

43 Claim 19. Matsumoto (Ex. 1005) in view of Mottishaw (Ex. 1004) logged in a reception caller information storage unit. comprising logging the call trace information. A reception caller information storage unit, indicated by 17, is provided that stores caller information received from the other terminal. (Ex. 1005, 6:67 7:2.) In FIG. 2, it is assumed that previously communicated caller information from the other terminal is stored in reception caller information storage unit 17. (Ex. 1005, 7:14 16.) Matsumoto logs the time that call trace information is updated. In Figure 2, provided within a caller information storage unit 15, which stores information on the caller of the local terminal, is time management unit 150, which indicates the update time (date and time of day) of the caller information; provided within reception caller information storage unit 17 is a time management unit 170, which stores the update date and time of day of the caller information received from the other terminal. (Ex. 1005, 7:2 9.) (Ex. 1005, Figure 2.) Whenever call trace information pertaining to any terminal is updated, Matsumoto logs this most recent update in a database server. In the system of FIG. 6, when the caller information stored in each terminal is updated, the shared database server 3 is called out from communication interface 12 using the server 39

44 Claim 19. Matsumoto (Ex. 1005) in view of Mottishaw (Ex. 1004) address previously stored, by setting, etc., in server address storage unit 21, and when the caller information is transferred, data updating unit 31 is activated from communication control unit 30 and updates database 30. This database is able to share between the terminals the latest caller information at all times. (Ex. 1005, 9:1 9.) See also (Ex. 1005, 3:57 59.) Mottishaw logs call trace information in the form of service detail records. As the Examiner found during prosecution, Mottishaw discloses logging call trace information, including database and call logs (e.g., DMI Figs. 1-2, col. 3, lines 48-67; col. 5, lines 25-44; col. 4, lines 30-42; col. 2, lines 16-20; Fig. 4). (Ex at 45.) Mottishaw s disclosure of logging call trace information is detailed above at pages 23, See also Ex. 1004, Figs. 1-2 & Fig. 4; id. at 2:16 19, 3:41 67; 5:25 44, 4:30 42, 5:45 6:18; Ex. 1007, E. Claims and 20 are anticipated by Fobert 1. Statement of Non-redundancy The grounds raised in the following sections are meaningfully distinct from those above and rely upon a different prior art reference. The grounds detailed in Sections VI.A and VI.B rely upon Byers as the primary reference. The grounds detailed in Sections VI.C and VI.D rely upon Matsumoto as the primary reference. The grounds detailed in Sections VI.E and VI.F rely upon Fobert as the primary reference. Whereas the grounds detailed in Sections VI.A and VI.B describe a 40

45 group of network nodes that comprise the packet data network, each node with the ability to determine its own geographic location information and provide that information in response to a request from a requesting node (Ex. 1021, 1:51-64), and the grounds detailed in Sections VI.C and VI.D describe communication between at least two VoIP terminals, wherein call trace information is exchanged directly between terminals (Ex. 1005, 4:1 7, Figure 1), the grounds detailed in Sections VI.E and VI.F describe a single client terminal that receives call trace information by communicating with an address book database or LDAP server via a data network (Ex. 1003, 7:6 16, Figure 3). As Patent Owner may attempt to distinguish elements of the challenged claims based upon purportedly unique claim features, which are clearly described by Fobert, all grounds should be included for trial. Additionally, in the pending litigation Patent Owner asserted that: U.S. Patent No. 6,937,572 is entitled to a priority date of March 19, (Ex. 1032, p. 2.) Petitioner does not agree with the Patent Owner s claims of priority; however, if Patent Owner is successful in showing its alleged early conception date, and is further successful in demonstrating the requisite diligence for its alleged priority date, and successfully shows it was first to invent the claimed subject matter, the grounds raised below with respect to Fobert would not be 41

46 redundant of the grounds raised in Sections VI.A through VI.D with respect to Byers and Matsumoto. Accordingly, all grounds should be included for trial. 2. Fobert Fobert discloses an internet telephony network for managing voice packet data. (Ex. 1003, 1:7 9.) Fobert discloses a telephony network wherein a client terminal receives a call from a caller over a packet switched network. (Id. at 2:11 14.) The client terminal sends a request for the caller s call trace information, e.g., a call back number, geographical location information, and name. The request is sent to an address book database 21 and/or to a Lightweight Directory Access Protocol (LDAP) server. (Id. at 7:7 12.) The LDAP server stores and maintains all users call trace information. (Id. at 5:12 15, 5:65 6:3, 6:28 32, 6:51 55.) As seen in Figures 7 and 8, the client terminal receives the requested call trace information and then dynamically displays the caller s call trace information. (Id. at 7:10 16.) 42

47 (Id. at Fig. 7 & 8.) The client terminal s address book 21 then stores the caller s call trace information. (Id. at 6:28 32, 7:16 20.) Fobert discloses several embodiments wherein information and software programs stored in memory are utilized for display operations. (See, e.g., id. at 5:33 6:3, Fig. 1, Fig. 4 & 5.) 3. Claim Charts Claim 17. Fobert (Ex. 1003) Claim 17. [17A] A method that obtains call trace information, comprising: [17B] communicating over a packet switched network between a network compatible device and an end-point device, Fobert discloses a method that obtains call trace information, namely a method that retrieves information about the caller, identifying the caller. (Ex. 1003, 5:11.) See also Ex. 1007, 94. Fobert discloses voice communications between two users of a packet switched network. The invention features a client-server network for managing IP voice data packets. There is a client terminal for receiving IP voice data packets from a caller and a graphical display for conveying information to a client terminal user. (Ex. 1003, 2:11 14.) Client terminal 16 can include, for example, an internet protocol (IP) telephone, a cable television set top box having telephony capability, or a personal computer, each of which can communicate using internet protocol. (Ex. 1003, 4:13 16.) Once the user has been notified of the incoming call, the user can click[] ANSWER 34a, which connects the telephone call to client terminal 16. (Ex. 1003, 6:6 7.) [17C] generating a request for call trace information that See also Ex. 1007, In response to an incoming call, Fobert discloses querying either an address book database or an Lightweight Directory Access Protocol (LDAP) server 43

48 Claim 17. Fobert (Ex. 1003) for call trace information. pertains to the endpoint device, As discussed above, client terminal 18 performs a query to address book database 21 when an incoming call is detected. If the callers phone number is not found in address book database 21, client terminal controller 18 sends a query to LDAP server 23 within data network 24, as described in Block 44, FIG. 9. (Ex. 1003, 7:7 12.) (Ex. 1003, Figure 9.) [17D] subsequently receiving the call trace information that was requested, and See Ex. 1003, 6:47 55; see also Ex. 1007, 97. The call trace information is received from the address book database or LDAP server. [C]lient terminal controller 18 sends a query to LDAP server 23 within data network 24, as described in Block 44, FIG. 9. Referring now to FIG. 10, client terminal controller 18 (FIGS. 1 6) receives a reply from LDAP server 23 (FIGS. 1 6) and displays the caller s information on display screen 20. (Ex. 1003, 7:10 15.) (Ex. 1003, Figs. 9 & 10.) The information retrieval can be accomplished by accessing the user s own address book database 21 or by querying a Lightweight Directory Access Protocol (LDAP) server 23 via data network 24. (Ex. 1003, 5:12 15.) 44

49 Claim 17. Fobert (Ex. 1003) Caller information 30a 30d, as shown in FIG. 8, can automatically be retrieved from address book database 21 (FIGS. 1 6) when an incoming call is detected. (Ex. 1004, 6:22 24.) [17E] dynamically displaying at least a portion of the call trace information that was received. See also Ex. 1007, 98. The call trace information is dynamically displayed. [C]lient terminal controller 18 sends a query to LDAP server 23 within data network 24, as described in Block 44, FIG. 9. Referring now to FIG. 10, client terminal controller 18 (FIGS. 1 6) receives a reply from LDAP server 23 (FIGS. 1 6) and displays the caller s information on display screen 20 (FIGS. 1 7) via graphical user interface 22 (FIGS. 1 7), as described in Block 56. (Ex. 1003, 7:10 16.) (Ex. 1003, Figs. 9 & 10.) As applicants admitted, dynamic display is inherent as Fobert does not recite an intermediate step between receiving and displaying the call trace information. (Ex at 35.) See also Ex. 1007, Claim 18. Fobert (Ex. 1003) Claim 18. [18A] A method as in claim 17, 2 See Claim In a Certificate of Correction dated August 30, 2005, the preamble of claim 18 was changed from An apparatus to A method. (Ex at 1.) 45

50 Claim 18. Fobert (Ex. 1003) [18B] wherein the call trace information is selected from a group consisting of an Internet Protocol (IP) address, a geographical location of the end-point device, a type or class of the endpoint device, a call route, a topology of the route, a domain name server of the IP address and route, a directory number and name, a call back number, an advisement as to whether the IP address for the end-point device is mobile and an advisement as to what redirection may have occurred before the call was completed. Fobert discloses call trace information including at least a name, geographical location, and call back number. Caller information 30a-30d, as shown in FIG. 8, can automatically be retrieved from address book database 21. (Ex. 1003, 6:22 23.) That information includes at least (1) address 30d, i.e., the geographical location of the end-point device, (2) a call back number 30a, and (3) a name 30c. (Ex. 1003, 6:30 32, Fig. 8.) (Ex. 1003, Fig. 8.) See also Ex. 1007, 100. Claim 20. Fobert (Ex. 1003) Claim 20. [20A] A See Claim 18. method as in claim 18, [20B] further The user terminal stores and displays call trace comprising storing the information. call trace information. See claim 17. Moreover, Fobert discloses several embodiments wherein information and software programs stored in memory are utilized for display operations. (See, e.g., Ex at 5:33 6:3, Figs. 1, 4, and 5.) Thus, in the particular architecture disclosed by Fobert, display of the 46

51 Claim 20. Fobert (Ex. 1003) call trace information necessarily requires that it be stored in user terminal memory. (Ex. 1007, 99.) A caller s call trace information is received and automatically stored in an address book database. Moreover, for first time callers for which no information exists within address book database 21, the user can automatically update address book database 21 to add the caller s information such as information 30a, name 30c, and address 30d retrieved from LDAP server 23. (Ex. 1003, 6:27 31, Figs. 3 & 8.) See Ex. 1003, 4:2 4, 7: Call trace information is retrieved from an address book database or Lightweight Directory Access Protocol (LDAP) server which stores the call trace information. The client-server network can include a database from which the client terminal controller retrieves the information. The database can include an address book database or the database can include a Lightweight Directory Access Protocol Server. (Ex. 1003, 2:30 34.) See Ex. 1003, 3:52 54, 5:12 15; see also Ex. 1007, 97. F. Claim 19 is rendered obvious by Fobert in view of Mottishaw 1. Obviousness Argument Claim 19 depends from claim 18, and recites logging the call trace information. As explained above, data logging, including logging of call trace 47

52 information, was well known prior to March 18, 2000, the alleged conception date of the 572 Patent. (Supra at pp. 5 6, 15; Ex. 1007, ) It would have been obvious to one of ordinary skill in the art at the time of the 572 patent priority date to combine Fobert with the logging system disclosed in Mottishaw (described in detail above at pages 23 26). (Ex. 1007, ) Both Fobert and Mottishaw are from the same field of endeavor: telephony voice calls over a packet switched network. Compare Ex. 1003, 3:66 4:2 ( the present invention provides the user of an internet protocol telephony device the ability to originate, answer, and manage telephone calls from a personal computer ) with Ex. 1004, 1:5 9 ( method and apparatus for generating service detail records, and to monitoring systems for collecting data for these records from a network, such as a packet data network, which is used for example to carry multimedia telephony services. ); (Ex. 1007, 104.) Because both Fobert and Mottishaw concern telephony calls over a packet switched network one of ordinary skill would have looked to Mottishaw for beneficial teachings relevant to Fobert. (Ex. 1007, 105.) As explained more fully above, Mottishaw teaches numerous benefits of logging call trace information in a telephony network. (Supra at pp ; Ex. 1007, 105.) In addition, as explained above, one of ordinary skill would have been aware of logging as a widely used tool with a variety of uses. (Supra at p. 25; Ex. 1007, 106.) Adding Mottishaw s logging of call trace information to Fobert s 48

53 telephony system would be well within the technical skill of one of ordinary skill in the art. (Ex. 1007, 107.) Fobert teaches a centralized LDAP server which facilitates storage of data from various communication terminals. (Ex. 1003, 5:12 15, 7:9 20.) Fobert also teaches a client terminal 16, which can be an internet protocol (IP) telephone, a cable television set top box having telephony capability, or a personal computer. (Id. at 4:13 16.) Addition of well-understood data logging functionalities to any of these computerized devices would present no great technical challenges, and would not negatively impact the functionality of Fobert s telephony system. (Ex. 1007, 107.) Thus, It would have been obvious to a person of ordinary skill in the art at the time of the 572 patent s priority date to combine the teaching of Fobert with Mottishaw to incorporate the logging feature of Mottishaw into Fobert s packet switched telephony network. (Ex. 1007, ) 2. Claim Chart Claim 19. Fobert (Ex. 1003) in view of Mottishaw (Ex. 1004) Claim 19. [19A] A See Section VI.E, Claim 18. method as in claim 18, [19B] further Mottishaw logs call trace information in the form of comprising logging the service detail records. call trace information. As the Examiner found during prosecution, Mottishaw discloses logging call trace information, including database and call logs (e.g., DMI Figs. 1-2, col. 3, lines 48-67; col. 5, lines 25-44; col. 4, lines 30-42; col. 2, lines 16-20; Fig. 4). (Ex at 45.) 49

54 Claim 19. Fobert (Ex. 1003) in view of Mottishaw (Ex. 1004) Mottishaw s disclosure of logging call trace information is detailed above at pages 23, See Ex. 1004, Figs. 1, 2, and 4, 2:16 19, 3:41 67; 5:25 44, 4:30 42, 5:45 6:18; see also Ex. 1007, G. Claims and 20 are anticipated by Cruickshank 1. Statement of Non-redundancy The grounds raised in the following sections are meaningfully distinct from those above and rely upon a different prior art reference. The grounds detailed in Sections VI.A and VI.B rely upon Byers as the primary reference. The grounds detailed in Sections VI.C and VI.D rely upon Matsumoto as the primary reference. The grounds detailed in Sections VI.E and VI.F rely upon Fobert as the primary reference. The grounds detailed in Sections VI.G and VI.H rely upon Cruickshank as the primary reference. Whereas the grounds detailed in Sections VI.A and VI.B describe a group of network nodes that comprise the packet data network, each node with the ability to determine its own geographic location information and provide that information in response to a request from a requesting node (Ex. 1021, 1:51-64), the grounds detailed in Sections VI.C and VI.D describe communication between at least two VoIP terminals, wherein call trace information is exchanged directly between terminals (Ex. 1005, 4:1 7, Fig. 1), and the grounds detailed in Sections VI.E and VI.F describe a single client terminal 50

55 that receives call trace information by communicating with an address book database or LDAP server via a data network (Ex. 1003, 7:6 16, Fig. 3), the grounds detailed in Sections VI.G and VI.H describe an optional feature within a message notification system that allows a calling party, upon initiating a call to a called party, to obtain additional information about the called party. As Patent Owner may attempt to distinguish elements of the challenged claims based upon purportedly unique claim features, which are clearly described by Cruickshank, all grounds should be included for trial. Additionally, in the pending litigation Patent Owner asserted that: U.S. Patent No. 6,937,572 is entitled to a priority date of March 19, (Ex. 1032, p. 2.) Petitioner does not agree with the Patent Owner s claims of priority; however, if Patent Owner is successful in showing its alleged early conception date, and is further successful in demonstrating the requisite diligence for its alleged priority date, and successfully shows it was first to invent the claimed subject matter, the grounds raised below with respect to Cruickshank would not be redundant of the grounds raised in Sections VI.A through VI.F with respect to Byers and Matsumoto. Accordingly, all grounds should be included for trial. 2. Cruickshank Cruickshank (Ex. 1006) discloses a feature that allows a party making a call from a network compatible device to request, receive, and dynamically display call 51

56 trace information that pertains to the called party (end-point device). (Id. at 14:27 59.) Cruickshank accomplishes this by retrieving information from a user profile 30 which is stored within the user profile database 18 (Id. at 8:39 41), then presenting that information to the calling party. (Id. at 14:47 59.) The retrieved call trace information is then stored in a contact list database or as separate files in a directory. (Id. at 14:59 61.) Cruickshank discloses several embodiments wherein information and software programs stored in memory are utilized for display operations. (See, e.g., id. at 7:3 29, 8:20 38, 10:13 29, 11:53 12:34, Figs. 1, 5, and 7.) Thus, in the particular architecture disclosed by Cruickshank, display of the call trace information necessarily requires that it be stored in user terminal memory. (Ex. 1007, 114.) 3. Claim Charts Claim 17. Cruickshank (Ex. 1006) Claim 17. [17A] A method that obtains call trace information, comprising: [17B] communicating over a packet switched network between a network Cruickshank discloses a method that obtains call trace information, namely a feature that provid[es] a calling party with information associated with the called party which may not have been available to the calling party before the call was initiated. (Ex. 1006, 14:43 50.) See also Ex. 1007, 109. Cruickshank discloses terminal devices communicating over a packet switched network. In the embodiment shown in FIG. 1, the graphical notification system 10 is connected to network 12 which 52

57 Claim 17. Cruickshank (Ex. 1006) compatible device and an end-point device, interconnects with other communications devices such as source terminal device 14 and destination terminal device 16. Network 12 is, for purposes of illustration, an Ethernet-based local area network (LAN). Terminal devices 14 and 16 represent end-user communications devices, which each either include, or are connected in communication with, a display device for the display of graphical information transported over network 12. (Ex. 1006, 7:20 25, Fig. 1.) [17C] generating a request for call trace information that pertains to the end-point device, (Ex. 1006, Fig. 1.) It will be appreciated that a communication in the context of the present invention may also include communications involving other media types such as a voice call over IP. (Ex. 1006, 7:58 64.) See Ex. 1006, 7:34 40, 8:25 37, 12:39 42; see also Ex. 1007, 110. Cruickshank generates a request for call trace information that pertains to a called party. If the caller is a subscriber to called party identification services, then computer server 70 queries at step 182 the called party s user profile in user profile database 18. (Ex. 1006, 14:32 35, Fig. 8.) [17D] subsequently receiving the call See also Ex. 1007, Graphical and textual information about the called party is received by a caller s terminal. 53

58 Claim 17. Cruickshank (Ex. 1006) trace information that was requested, and [M]essaging server software 74 can direct computer server 70 to retrieve and transmit the graphical information to the caller's terminal for display (step 186) In addition to providing the calling party with graphical information, textual information about the called party can be retrieved by computer server 70 at step 186 and communicated to the calling party's terminal device 14. (Ex. 1006, 14:40 47; Fig. 8 at ) [17E] dynamically displaying at least a portion of the call trace information that was received. (Ex. 1006, Fig. 8.) See also Ex. 1007, The call trace information is dynamically displayed on the caller s terminal. [M]essaging server software 74 can direct computer server 70 to retrieve and transmit the graphical information to the caller's terminal for display (step 186) In addition to providing the calling party with graphical information, textual information about the called party can be retrieved by computer server 70 at step 186 and communicated to the calling party's terminal device 14. (Ex. 1006, 8: :40 47; Figure 8.) As applicants admitted, dynamic display is inherent as Cruickshank does not recite an intermediate step between receiving and displaying the call trace information. (Ex at 35.) The textual information presented to the calling party may include the called party's address, postal address, title, and alternative addressable communications numbers such as telephone numbers, fax numbers or cell phone numbers... 54