throbber

`
`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket