`
`
`DECLARATION OF JOHN DAY
`
`
`I, John Day, declare as follows:
`
`
`(1.)
`
`I have been asked to consider the validity of claims 1-6, 8-11, 13-15,
`
`23-25, 29-31, and 34 in view of various prior art. In particular, I have been asked
`
`to consider the validity of claims 1-3, 13, 14, 23, and 24 of the U.S. Pat. No.
`
`7,191,233 (hereafter the “‘233 Patent” – Ex. 1001) in view of two prior art
`
`references: U.S. Pat. No. 5,008,930 to Gawrys, et al (hereafter “Gawrys” – Ex.
`
`1002) and U.S. Pat. No. 5,796,812 to Hanlon, et al. (hereafter “Hanlon” – Ex.
`
`1003). I have also been asked to consider the validity of claims 4-6, 8-11, 15, 25,
`
`29-31, and 34 of the ‘233 patent in view of four prior art references: Gawrys,
`
`Hanlon, U.S. Pat. No. 5,550,906 to Chau, et al (hereafter “Chau” – Ex. 1006) and
`
`U.S. Pat. No. 5,737,592 to Nguyen, et al (hereafter “Nguyen” – Ex. 1007). I
`
`provide my testimony below.
`
`
`QUALIFICATIONS
`
`(2.)
`
`I have a long history in the communications field, which I summarize
`
`below. I have been involved in modern networking since 1970, when the Illiac IV
`
`project was the 12th node on ARPANET. I was part of the group that wrote 3
`
`operating systems for the PDP-11 to interface a variety of peripherals to the ‘Net. I
`
`also participated in the Network Working Group, which developed the host-based
`
`1
`
`Unified Patents Inc., Ex. 1005, pg. 1
`
`
`
`protocols. In particular, I contributed to FTP, and also wrote a “File Access
`
`Protocol,” which was implemented and used on the ‘Net. (FTP moves whole files;
`
`File Access allowed moving parts of files.) I was involved in putting the first Unix
`
`system on the ‘Net in the summer of 1975 and had one of the earliest if not the
`
`earliest TCP/IP implementations on Unix. I also was involved stripping down
`
`Unix to run on an LSI-11 (a single board PDP-11) with a plasma screen and touch,
`
`this “intelligent terminal” was used with a land-use planning application for the 6
`
`counties around Chicago that used databases on both coasts. The ‘intelligent
`
`terminal’ was also fielded at CINCPAC and within the Department of Defense
`
`(“DoD”) for military logistics applications. During this period, I also did
`
`considerable work on distributed databases and published one of two fundamental
`
`algorithms for updating multiple copies of databases, which involves session
`
`transfer. Starting in 1975, I participated in the International Network Working
`
`Group (INWG), a colleague concentrated on the Transport Protocol proposal. I put
`
`my efforts into designing an extensible Virtual Terminal Protocol, and on Formal
`
`Description Techniques for protocols. In the late 1970s and early 1980s, my team
`
`and I built a Network Front End for Department of Defense mainframe computers,
`
`based on a Host Front-End Protocol that we designed, specified, and implemented.
`
`In 1978, I was invited to the second meeting of the work on OSI (Open Systems
`
`Interconnection). That led to my becoming the Rapporteur of the OSI Reference
`
`2
`
`Unified Patents Inc., Ex. 1005, pg. 2
`
`
`
`Model and chair of the US ANSI committee on OSI Architecture. This required
`
`involvement with the protocol developments at all layers. I initiated the work on
`
`OSI Security and brought people in to work on it, was Rapporteur for Naming and
`
`Addressing, and oversaw the inclusion of connectionless (datagrams) into the OSI
`
`Reference Model and the OSI protocol standards, a task that required considerable
`
`political negotiation. All of this work involved session transfer.
`
`(3.)
`
`During my employment by Codex Motorola in the 1980s, I oversaw
`
`the architecture for several LAN Products, developed the Network Management
`
`architecture that was used not only for our products, but also for the GM
`
`MAP/TOP effort to promote Factory and Office Automation and the OSI
`
`Management Framework, also known as the TMN standards or the X.7xx series of
`
`Recommendations in ITU. The integrated Network Management product we
`
`fielded in 1986 on Apollo workstations was quite advanced and in some regards
`
`still has not been surpassed by current products. The work on the OSI Reference
`
`Model and the resolution of questions on the Model as documented in the
`
`Commentaries on the OSI Reference Model which I maintained for TC97/SC16
`
`and SC21 as well as the work on the 7498-3, OSI Naming and Addressing are
`
`mainly concerned with ensuring that all of the constructions necessary to build
`
`arbitrary distributed systems including creating application-sessions independent of
`
`the underlying communication infrastructure, moving these application-sessions
`
`3
`
`Unified Patents Inc., Ex. 1005, pg. 3
`
`
`
`between processes and between processes in different systems, and multi-endpoint
`
`or multi-peer sessions.
`
`(4.)
`
`In the late 1980s, I initiated the revision of the OSI Application Layer
`
`Structure to make it recursive, i.e. networked applications could invoke other
`
`networked applications or incorporate them as building blocks. This work involved
`
`session transfer. This also involved a new edition of the Application Association
`
`Control Service Element (ACSE), which created application connections, to
`
`support recursion. This in essence lays the groundwork for quite sophisticated
`
`distributed applications. In the mid-1990s, I was editor for a revision of HDLC to
`
`include elements to increase its robustness for use in harsh environments and also
`
`wrote the Utilities Communication Architecture for the effort to create standards
`
`for the utilities industry, as well as various distributed application and network
`
`issues for the Federal Aviation Administration and for ICAO (the International
`
`Civil Aviation Organization). The work on the OSI Application Layer Structure
`
`and the ACSE service and protocol cover the more detailed constructions and those
`
`that go beyond the issues of naming and addressing to ensure that arbitrary
`
`distributed systems could be constructed using these standards. This would
`
`include, but was not limited to, creating application-sessions independent of the
`
`underlying communication infrastructure, moving these application-sessions
`
`between processes and between processes in different systems, and multi-endpoint
`
`4
`
`Unified Patents Inc., Ex. 1005, pg. 4
`
`
`
`or multi-peer sessions, as well as integrating the syntax negotiation mechanisms of
`
`the Presentation Layer, and the Functional Units of the OSI Session Layer into the
`
`resulting recursive structure of the Application Layer.
`
`(5.)
`
`I am currently an adjunct professor of Computer Science at Boston
`
`University, teaching graduate level advanced and introductory classes related to
`
`networking and operating systems, and am the author of the 2008 book Patterns in
`
`Network Architecture: A Return to Fundamentals. I continue to work in the
`
`networking/communications field.
`
`(6.)
`
`Over the past 40+ years, I have gained an in depth experience with all
`
`levels of networking, including session transfer.
`
`SUMMARY OF THE ‘233 PATENT
`
`(7.)
`
`In short, the ‘233 Patent describes transferring an on-going session
`
`from one device to another device while maintaining that session. While a first
`
`device is communicating with a server, the user may select a second device to
`
`receive the session. The session with the first device may be discontinued and any
`
`subsequent messages on the transferring session may be blocked from reaching the
`
`first device. The server may then transfer the session to a second device to
`
`continue the session. Ex. 1001, Abstract.
`
`(8.)
`
`Claim 1, for example, contains the following features:
`
`Conducting a session with a first device;
`
`5
`
`Unified Patents Inc., Ex. 1005, pg. 5
`
`
`
`Specifying a second device;
`
`Discontinuing the session with the first device; and
`
`Transmitting a session history of said first device from said first device to a
`
`session transfer module after the session with the first device is discontinued;
`
`and
`
`Resuming the session on the second device with the session history.
`
`As I will discuss in much greater detail below, all of the features of this claim as
`
`well as the other claims that I have analyzed were well known to those of ordinary
`
`skill in the art for many years before the earliest priority date of the ‘233 Patent,
`
`which I understand to be September 17, 2001. For the purposes of my analysis
`
`below, I will use this date as the priority date of the patent.
`
`CLAIM INTERPRETATION
`
`(9.)
`
`In proceedings before the USPTO, I understand that the claims of an
`
`unexpired patent are to be given their broadest reasonable interpretation in view of
`
`the specification from the perspective of one skilled in the field. I have used this
`
`standard as well as the ordinary meaning of the claim terms in my analysis below
`
`for all of the claim terms. However, there are a number of terms used in the claims
`
`that deserve some discussion in this context, and I discuss them below.
`
`
`
`Device: One of ordinary skill in the art would understand this term to mean
`
`“any communication enabled device.” This would include cell phones, computers,
`
`6
`
`Unified Patents Inc., Ex. 1005, pg. 6
`
`
`
`etc. This definition is consistent with the broad use of the term in the specification.
`
`The following quotes show that the term device is used for practically any
`
`communications-enabled device, from a mobile phone and pager to a laptop and
`
`desktop regardless of whether such devices communicate via wireless or wired
`
`communications:
`
`In today’s information intensive society, it is not uncommon for a user
`to have several communication-enabled devices (e.g., a cellular
`phone, a pager, a wireless personal digital assistant). A typical user
`may have a desktop computer system to perform information
`transactions (or sessions) such as sending/receiving electronic mail
`(“e-mail”), browsing the Internet for information and communicating
`via instant messaging. Ex. 1001, at 1:15-22.
`
`As a result, many users have turned to a variety of untethered and
`lighter weight devices to perform these information transactions while
`the user is mobile. Laptop computers with wireless modems are an
`example, as are enhanced text pagers, wireless handheld devices,
`personal digital assistants (PDA), and wireless mobile phones with
`integrated displays. Ex. 1001, at 1:29-35.
`
`Along with wireless handhelds, personal digital assistants (“PDAs”)
`and Wireless Application Protocol (“WAP”) telephones have also
`been configured to perform similar information transactions but
`formatted to conform to the limitations of the respective graphical
`interfaces, as well as other limitations, of each type of device. With
`
`7
`
`Unified Patents Inc., Ex. 1005, pg. 7
`
`
`
`
`
`the wide variety of devices, a user may have many options in which to
`conduct a software application session. In fact, many users often
`have multiple communication-enabled devices. Ex. 1001, at 1:44-52.
`
`However, a user may be conducting a session on a first device and
`wish to switch to a second device. This decision may be based on a
`variety of factors such as proximity to the second device, mobility of
`the second device, safety concerns, a preference for a particular type
`of graphical user interface, modality of interaction with the user
`interface, or other additional capabilities of the second device, etc.
`Ex. 1001, at 1:53-59.
`
`In addition to transferring from device to device, the data might
`need to be changed, either in format, for instance from HTML to
`WML, or in modality, for instance from voice to text or text to voice.
`Ex. 1001, at 2:8-12.
`
`The client software of the wireless/wired client devices, 120 and 125
`may be further configured to provide a selection of devices that a
`transferring session may be redirected thereto. Ex. 1001, at 4:53-56.
`
`The retrieved device profile is utilized by the session transfer module
`220 to direct the data handler module 160 to reformat or convert the
`stored messages into a data format compatible and/or modality (e.g.,
`WML for WAP devices, HDML, for pre-WAP telephones, HTML for
`desktop browsers, VoiceXML for voice browsers, etc.) with the
`redirected device. Ex. 1001, at 8:7-13.
`
`8
`
`Unified Patents Inc., Ex. 1005, pg. 8
`
`
`
`
`Session: One of ordinary skill in the art would understand this term to mean
`
`
`
`“information exchange between two communicating devices.” This definition is
`
`consistent with its use in the specification, which uses the term very broadly:
`
`For simplicity and illustrative purposes, the principles of the present
`invention are described by referring mainly to an exemplary
`embodiment thereof. Although an embodiment of the invention may
`be practiced in an instant messaging environment or a Web browsing
`environment, one of ordinary skill in the art will readily recognize that
`the same principles are equally applicable to, and can be implemented
`in, any session-oriented environments, and that any such variation
`does not depart from the true spirit and scope of the present invention.
`Ex. 1001, at 2:54-63.
`
`The client may be configured to provide the software (e.g., utilities,
`application specific software, etc.,) to support the session services
`designated for each type of wireless/wired client devices, 120 and
`125. Ex. 1001, at 4:36-40.
`
`These services may include session-based services such instant
`messaging, database querying, and other similar services. The
`supporting applications of these session based-services may be
`provided by an application server 140. The application server 140
`may be configured to provide an application such as instant messaging
`application, a Web application, a database querying application, and
`other similar applications. The application server 140 may be
`
`9
`
`Unified Patents Inc., Ex. 1005, pg. 9
`
`
`
`implemented by any number of commercially available servers or
`high performance computers. Because the specific type of session to
`be used in the present invention will vary according to individual
`needs, the present invention is not limited to any specific type of
`session and may thus utilize any type of session that may be provided
`to a user which may reasonably accomplish the goals of the present
`invention. Ex. 1001, at 5:23-37 (emphasis added).
`
` A
`
` session-based service may be an instant messaging service,
`messaging service, a database query, a Web browsing session, and the
`like. Ex. 1001, at 5:46-48
`
`Session History: One of ordinary skill in the art would understand this term
`
`
`
`to mean “information associated with a session.” The specification uses several
`
`terms synonymous with session history, such as session state, session data, and
`
`transaction history. For example, claims 4, 5, and 6 refer to “said session data”
`
`which can only refer to claim 1’s “session history.” (I discuss below that I believe
`
`that this is a mistake and that one of ordinary skill in the art would recognize that
`
`the patent drafter intended this to be “session history.”) Also, the specification
`
`refers to receiving the “session history” and then refers to this session history as
`
`the “state of the session” when it discloses converting the “state of the session” to a
`
`state compatible with the redirected device:
`
`10
`
`Unified Patents Inc., Ex. 1005, pg. 10
`
`
`
`
`
`Ex. 1001, at Fig 3.
`
`In step 315, the session transfer module 220 may be configured to
`receive a transaction or session history from the transferring device.
`The session history may be stored temporarily in a memory space
`allocated by the session transfer module 220 in the session server 105.
`Ex. 1001, at 7:62-66 (emphasis added).
`
`In step 325, the state of the session is converted to a state compatible
`with the redirected device by the session transfer module 220
`according the device profile. For example, the redirected device may
`have a different user preference settings, data preferences, modality,
`and/or command library. Ex. 1001, at 8:14-19 (emphasis added).
`
`The specification then refers to this converted “state of the session” as the
`
`“converted session”:
`
`11
`
`Unified Patents Inc., Ex. 1005, pg. 11
`
`
`
`If the session transfer module 220 detects the activation of the
`redirected device, in step 340, the session transfer module 220 pushes
`the converted session to the redirected device over the network 100 as
`a normal session with the converted transaction log. Subsequently,
`the session transfer module 220 returns to an idle state, in step 345.
`Ex. 1001, at 8:31-37 (emphasis added).
`
`The specification discloses message history as an example of session history:
`
`The session transfer module may be further configured to access a
`device profile from a device profile database to convert the blocked
`messages as well as the messages comprising the prior message
`history (or session history) into a format compatible with the
`redirected device, where the format may include parameters such as
`data format, modality, etc. Ex. 1001, at 3:29-36.
`
`The following quote shows that a transaction history can be a session history:
`
`The session transfer module 220 may be configured to optionally
`accept a transaction (or session) history of the transferring device
`during the redirection process. Ex. 1001, at 7:27-30.
`
`Moreover, the specification discloses that the session history may be complete or
`
`only partial:
`
`The session transfer module may be configured to direct a data
`handler module to reformat the session history to conform to the data
`format and/or modality compatible according to the redirected device
`profile in response to the receipt of the session history. Subsequently,
`
`12
`
`Unified Patents Inc., Ex. 1005, pg. 12
`
`
`
`the session transfer module may be further configured to transmit the
`reformatted session history to the redirected device. Thus, a user may
`be provided with a complete history of the session at the redirected
`device. Ex. 1001, at 3:48-55.
`
`Thus, a user may be provided with a complete history of the session at
`the redirected device. Alternatively, the session transfer module 220
`may be configured to transmit a portion of the session history that is
`compatible with the memory requirements of the redirected device.
`This particular feature may be a user preference setting and/or a
`network administrative setting. Ex. 1001, at 7:38-45.
`
`From the above quotations, one of ordinary skill in the art would understand that
`
`the term “session history” is used interchangeably with transaction history, session
`
`state, session data and message history. Moreover, the message history may be a
`
`complete history or only a partial history. Based on this broad use as well as the
`
`patent’s applicability to many different kinds of sessions, one of ordinary skill in
`
`the art would understand this term to mean “information associated with a
`
`session.”
`
`
`
`Session Data (claims 4, 5, 6) – Claims 4, 5, and 6 refer to “said session
`
`data” although the claim from which it depends, claim 1, does not mention
`
`“session data” only “session history.” Given the understanding that one of
`
`ordinary skill would have of the “session history,” which I discuss above, I believe
`
`13
`
`Unified Patents Inc., Ex. 1005, pg. 13
`
`
`
`that one of ordinary skill would understand that the term “session data” was
`
`intended to be and is interchangeable with “session history.” I will assume this as
`
`part of my analysis below.
`
`ANTICIPATION
`
`(10.)
`
`I have been informed that claims may be found invalid as anticipated.
`
`I understand this to mean that a claim is invalid if there is a single prior art
`
`reference that discloses each limitation of the claim either expressly or inherently.
`
`INHERENCY
`
`(11.)
`
`I understand a limitation to be inherently disclosed in a prior art
`
`reference if it is necessarily present in the reference.
`
`OBVIOUSNESS
`
`(12.)
`
`I have been informed that a patent claim can be found unpatentable as
`
`obvious where the differences between the subject matter sought to be patented
`
`and the prior art are such that the subject matter as a whole would have been
`
`obvious at the time the invention was made to a person having ordinary skill in the
`
`relevant field. I understand that an obviousness analysis involves a consideration
`
`of (1) the scope and content of the prior art; (2) the differences between the
`
`claimed invention and the prior art; (3) the level of ordinary skill in the pertinent
`
`field; and (4) secondary considerations of non-obviousness.
`
`ONE OF ORDINARY SKILL IN THE ART
`
`14
`
`Unified Patents Inc., Ex. 1005, pg. 14
`
`
`
`(13.)
`
`I have been informed that “a person of ordinary skill in the relevant
`
`field” is a hypothetical person to whom an expert in the relevant field could assign
`
`a routine task with reasonable confidence that the task would be successfully
`
`carried out. I have been informed that the level of skill in the art is evidenced by
`
`the prior art references. The prior art discussed herein demonstrates that a person
`
`of ordinary skill in the field, at the time of the ‘233 Patent’s earliest priority date,
`
`had a detailed understanding of communications and networking, including
`
`transferring an on-going communication session from one device to another. In
`
`fact, a review of the file history of the ‘233 Patent shows that one of ordinary skill
`
`in the art was well aware of virtually all of the features of the claims. Specifically,
`
`the Examiner believed in the Notice of Allowance that the only difference over the
`
`prior art was that the session history was transferred after the session with the first
`
`device was discontinued:
`
`Belfiore et al., US Pat. App. No. 2002/0059425 A1, teaches the
`invention substantially as claimed. . . .
`However, the prior art of record fails to teach or suggest individually
`or in combination a system in which a mid-session transfer of a
`session is achieved by transmitting a session history from a first
`device to a session transfer module after said session is discontinued
`on the first device. Ex. 1004, at 5.
`
`15
`
`Unified Patents Inc., Ex. 1005, pg. 15
`
`
`
`As I will discuss below, the transfer of a session history after the session is
`
`discontinued with the first device was also well known. Thus, one of ordinary skill
`
`in the art was well aware of all the features of the claims.
`
`(14.)
`
`Based on my experience I have an understanding of the capabilities of
`
`a person of ordinary skill in the relevant field. I have supervised and directed
`
`many such persons over the course of my career. Further, I had those capabilities
`
`myself for four decades when the ‘233 Patent was filed and still do.
`
`STATE OF THE ART AS OF 2001
`
`(15.)
`
`The basic idea of the ‘233 Patent–session transfer–has a long history
`
`in the field of networking and, in fact, is so well known that many occurrences
`
`have undoubtedly gone unpublished or even undocumented, because such
`
`technology is simply a routine task to one of ordinary skill in the art for many
`
`years before 2001.
`
`(16.)
`
`The earliest occurrence of this kind of ability to move a session from a
`
`first device to a second device was with the “teleconferencing” application
`
`protocol (today we would call it “instant messaging”) developed in 1972 by James
`
`Calvin then at Bolt, Beranek, and Newman (BBN) for use on the ARPANET. This
`
`system was demonstrated at ICCC ’72 and there were several papers in the
`
`conference on “teleconferencing” of this sort. There were discussions and some
`
`documents written that also treated this work in the ARPANET User’s Interest
`
`16
`
`Unified Patents Inc., Ex. 1005, pg. 16
`
`
`
`Group (USING, 1974) and in the ARPA funded project, the National Software
`
`Works (1977). Papers were published on this latter effort and the technical reports
`
`were generally available.
`
`(17.)
`
`Considerable attention to this problem was given in the OSI standards
`
`effort between 1978 and 1995, including the development of the OSI Session
`
`Protocol (ISO 8326,8327; X.215X.225:1987), OSI Presentation Protocol (ISO
`
`8822, 8823; X.216, X.217: 1992); Abstract Syntax standards (ISO8824, 8825;
`
`X.208, X.209: 1990), Application Control Service Element protocol (ISO 8649,
`
`8650; X.217, X.227: 1988), Application Layer Structure (ISO 9545, X.207:1989,
`
`1993), and Naming and Addressing addendum of the OSI Reference Model (ISO
`
`7498-3, X.650 :1988). All of this work was well known to those skilled in the field
`
`and they would have known how to construct what is described in the ‘233 Patent
`
`with the tools provided. These standards were developed to enable what’s
`
`described and claimed in the ‘233 Patent. In the Internet, the Session Initiation
`
`Protocol (RFC 2543;1999) is a signaling protocol developed by the IETF starting
`
`in 1996 for controlling sessions. While primarily focused on multimedia (voice
`
`and video), it can be used for a session with any kind of data. SIP is defined
`
`specifically to cover many claims of this patent, as well as many other
`
`configurations.
`
`17
`
`Unified Patents Inc., Ex. 1005, pg. 17
`
`
`
`(18.)
`
`Session transfer had been in practice for over two decades by 2001.
`
`Anyone with ordinary skill in the art came up with variations on the ‘233 Patent
`
`based on the previous work cited above or mere common sense. For example, the
`
`ability to forward a call in the PSTN was well known through Jim Calvin’s early
`
`teleconferencing program to more formal means laid out in international standards.
`
`The ability to reformat session information was widely understood in the early
`
`ARPANET as indicated by the use of a “canonical form” in Telnet (1973) and FTP
`
`(1973). The role of the Network Virtual Terminal (NVT) and the Network Virtual
`
`File System (NVFS) respectively in these protocols, which was much written
`
`about, including the properties that these conversions or re-formatting had to have.
`
`One disadvantage of early approach was that the conversion to the canonical form
`
`was always used. This constraint was relaxed and generalized with standardization
`
`of the OSI Presentation Protocol that allowed correspondents to negotiate the
`
`format of the data to be transferred. This has been a well-understood problem with
`
`many solutions for at least 20 years before 2001. In fact, all the features of the
`
`challenged claims were well-known to those of ordinary skill in the art before
`
`2001.
`
`(19.) My analysis of claims 1-3, 13, 14, 23, and 24 of the ‘233 Patent relies
`
`upon two patents: Gawrys from 1991 and Hanlon from 1998. The combination of
`
`18
`
`Unified Patents Inc., Ex. 1005, pg. 18
`
`
`
`Gawrys and Hanlon disclose all the features of these claims in the context of
`
`telephony and ISDN.
`
`GAWRYS – U.S. PAT. NO. 5,008,930 (ISSUED APRIL 16, 1991)
`
`(20.)
`
`Gawrys (Ex. 1002) discloses virtually all of the claimed features of
`
`the challenged claims, although it doesn't explicitly disclose that the session history
`
`is transferred after the session with the first device is discontinued. Hanlon
`
`discloses this feature.
`
`(21.)
`
`Gawrys discloses a customer service system where an agent receives a
`
`call from a customer that called a 1-800 number over an ISDN network. The first
`
`agent, at a first agent terminal, answers the call and can obtain caller related
`
`information from the communications system and then transfers the voice and
`
`collected data to another agent or supervisor "for continuing the call." Ex. 1002, at
`
`4:41-48; 1:7-16. In this manner, Gawrys transfers an integrated voice/data call
`
`including call-related data between a first and a second agent terminal. Ex. 1002,
`
`at Abstract; cl. 1. Gawrys' Fig. 4 provides more detail:
`
`19
`
`Unified Patents Inc., Ex. 1005, pg. 19
`
`
`
`
`
`(22.)
`
`The first agent terminal 141 receives a call from caller 12. This
`
`session includes a voice call, caller data displayed in a phone window 53, and host
`
`application data displayed in one or more host application windows 56, 57. Ex.
`
`1002, at Abstract. The host application data is obtained by querying host computer
`
`system 18 using the caller's phone number to retrieve various information, such as
`
`20
`
`Unified Patents Inc., Ex. 1005, pg. 20
`
`
`
`account information or other information associated with the caller. Ex. 1002, at
`
`4:67-5:41. When a call must be transferred, the first agent at first agent terminal
`
`141 presses a transfer key whereupon the first agent terminal sends an indication to
`
`the PBX 13 that the voice and data are to be transferred and then sends the data in
`
`the form of a UUI to the PBX for transferring to the second agent 142. The UUI
`
`includes the information in the phone window 53 as well as an index. The PBX
`
`transfers the UUI to the second agent, and the second agent uses the index to query
`
`the host database system 18 to receive the same information as was displayed in
`
`windows 53, 56 and 57 of the first agent. Ex. 1002, at 9:38-10:36.
`
`HANLON – U.S. PAT. NO. 5,796,812 (ISSUED AUGUST 18, 1998)
`
`(23.)
`
`Similar to Gawrys, Hanlon (Ex. 1003) also discloses call transferring
`
`from one party to another where both the call is transferred as well as call-specific
`
`data over an ISDN network. Ex. 1003, at 1: 46-50. To transfer call-specific data,
`
`the re-directing party transmits an out-of-band message containing data to the
`
`network. The network forwards the data to the target party. The data may effect a
`
`data transfer. Ex. 1003, at Abstract. The data is transferred in the form of a UUI
`
`and may include caller-specific information entered by the caller (address, phone
`
`number, account number, etc.) or information generated by the re-directing party,
`
`such as account balance. Ex. 1003, at 3:32-43. Upon requesting a call transfer, the
`
`21
`
`Unified Patents Inc., Ex. 1005, pg. 21
`
`
`
`call is redirected, discontinuing the session, and the call-specific data is then
`
`transferred:
`
`However, the UUI IE need not necessarily be sent as part of the
`message incorporated within the set-up of a call to the target party 16
`or associated with call termination. Rather, the UUI IE containing the
`call-specific data could be sent as part of a message generated by the
`re-directing party 14 to effect data transfer after call re-direction. As
`discussed, the re-directing party 14 requests band call re-direction
`request by entering an out-of band request. After the call is re-directed
`pursuant to the request of the re-directing party 14, the re-directing
`party may transfer the call-specific data to the target party 16 by
`sending a data-transfer message containing the call-specific data to the
`TS 24 for transmission via the TS 26 to the TS 29. Ex. 1003, at 4:8-
`15 (emphasis added).
`
`REASONS TO COMBINE
`
`(24.)
`
`One of ordinary skill in the art would be motivated to combine Hanlon
`
`with Gawrys because the systems are directed to the same problem and are very
`
`similar. Both patents are directed to call transferring including session information
`
`from one party to another over an ISDN network. The patents are therefore
`
`directed to the same problem, call transfer. The technology of each patent is
`
`remarkably similar because both deal with voice/data call transfer over an ISDN
`
`network.
`
`22
`
`Unified Patents Inc., Ex. 1005, pg. 22
`
`
`
`(25.)
`
`Specifically, one of ordinary skill would add "the session
`
`discontinuation before session history transfer" feature of Hanlon to Gawrys to
`
`ensure session integrity. If the session with the first device continued after the
`
`session history were transferred to the second device, then when the session
`
`resumed on the second device, the session history would not reflect the latest state
`
`of the session on the first device, resulting in a resumption of the session that may
`
`not behave properly. A more robust session transfer system would discontinue the
`
`session on the first device before transmitting the session history to the second
`
`device, thus ensuring a smooth transfer. The benefits and need to discontinue the
`
`session on the first device before transmitting the session history to the second
`
`device would be readily apparent to one of ordinary skill in the art.
`
`THE COMBINATION OF GAWRYS AND HANLON
`
`(26.)
`
`Gawrys discloses virtually all of the claim elements of the challenged
`
`claims. For example, it conducts a session with a first device (the first agent
`
`terminal), it specifies a second device (a second agent terminal), it discontinues the
`
`session on the first device, it transmits a session history from the first device to the
`
`second device using a session