IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`In re U.S. Patent No. 7,516,192
`
`Trial Number: IPR2013-00468
`
`Filed:
`
`Issued:
`
`July 14, 2006
`
`April 7, 2009
`
`Inventors: Stephen J. Brown
`
`Assignee: Robert Bosch Healthcare Systems,
`Inc.
`
`Title:
`
`NETWORKED SYSTEM FOR INTERACTIVE
`COMMUNICATION AND REMOTE MONITORING OF
`INDIVIDUALS
`
`Mail Stop PATENT BOARD,
`Patent Trial and Appeal Board
`United States Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`UNDER 35 U.S.C. § 313 and 37 C.F.R. § 42.107
`
`

`

`TABLE OF CONTENTS
`
`V.
`
`Page
`INTRODUCTION ..........................................................................................1
`I.
`OVERVIEW OF THE ’192 PATENT ...........................................................1
`II.
`III. CLAIM CONSTRUCTION ...........................................................................8
`A.
`“Script Program” ................................................................................10
`B.
`“Data Merge Program”.......................................................................12
`IV. OVERVIEW OF THE ASSERTED REFERENCES ..................................16
`A. Wright.................................................................................................17
`B.
`Goodman ............................................................................................21
`C. Wahlquist............................................................................................24
`GROUND 1 OF THE PETITION SHOULD NOT BE CONSIDERED
`PURSUANT TO 37 C.F.R. § 42.104(B)(2) .................................................28
`VI. NO INTER PARTES REVIEW SHOULD BE INITIATED BECAUSE
`THE PRIOR ART DOES NOT INVALIDATE ANY CLAIM...................30
`Overview Of Reasons for Denying Inter Partes Review ..................30
`A.
`B.
`The Prior Art Does Not Teach a “Data Merge Program
`Configured to Generate a Customized Script Program by
`Customizing a Generic Script Program.”...........................................32
`1. Wright Does Not Teach the Claimed Data Merge
`Program....................................................................................32
`Goodman Does Not Teach the Claimed Data Merge
`Program....................................................................................34
`3. Wahlquist Does Not Teach the Claimed Data Merge
`Program....................................................................................36
`The Prior Art Does Not Teach “the Customized Script
`Program…Includes (i) a Display Command…and (ii) an Input
`Command.”.........................................................................................42
`1. Wright Does Not Teach the Claimed Script Program
`Including a Display Command and an Input Command .........43
`
`2.
`
`C.
`
`-i-
`
`

`

`2.
`
`2.
`
`2.
`
`Goodman Does Not Teach the Claimed Script Program
`Including a Display Command and an Input Command .........44
`3. Wahlquist Does Not Teach the Claimed Script Program
`Including a Display Command and an Input Command .........45
`Additional Reasons No Review Should Be Instituted for
`Ground 1.............................................................................................46
`Additional Reasons No Review Should Be Instituted for
`Ground 2.............................................................................................48
`1.
`Goodman and Wright Do Not Teach a Database for
`Storing the Generic Script Program........................................49
`A Person of Ordinary Skill in the Art Would Not Have
`Combined Goodman and Wright in the Manner Asserted ......50
`Additional Reasons No Review Should Be Instituted for
`Ground 3.............................................................................................52
`1. Wahlquist Is Not Directed to Communication Systems
`for Remote Monitoring of Individuals.....................................53
`A Person of Ordinary Skill in the Art Would Not Have
`Combined Goodman and Wahlquist in the Manner
`Asserted....................................................................................57
`VII. CONCLUSION.............................................................................................60
`
`D.
`
`E.
`
`F.
`
`TABLE OF CONTENTS
`(continued)
`
`Page
`
`ii
`
`

`

`TABLE OF AUTHORITIES
`
`Page(s)
`
`Cases
`Accent Packaging, Inc. v. Leggett & Platt, Inc.,
`707 F.3d 1318 (Fed. Cir. 2013) ..........................................................................15
`
`Am. Seating Co. v. Freedman Seating Co.,
`450 F. Supp. 2d 765 (W.D. Mich. 2006)............................................................39
`
`Heart Failure Techs., LLC v. Cardiokinetix, Inc.,
`IPR2013-00183, 2013 Pat. App. LEXIS 5602 (PTAB July 31, 2013)...............48
`
`In re Klein,
`647 F.3d 1343 (Fed. Cir. 2011) ..............................................................31, 53, 59
`
`KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007)............................................................................................31
`
`Largan Precision Co., Ltd. v. Fujifilm, Corp.,
`2012 Pat. App. LEXIS 2916 (BPAI 2012) .........................................................52
`
`Liberty Mutual Ins. Co. v. Progressive Casualty Ins. Co.,
`CBM2012-00003, 2012 Pat. App. LEXIS 7236 (PTAB Oct. 25, 2012)......30, 48
`
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) (en banc)............................................................9
`
`In re Robertson,
`169 F.3d 743 (Fed. Cir. 1999) ............................................................................35
`
`Statutes
`
`35 U.S.C. § 102........................................................................................................28
`
`35 U.S.C. § 103(a) ............................................................................................passim
`
`35 U.S.C. § 314..........................................................................................................1
`
`-iii-
`
`

`

`TABLE OF AUTHORITIES
`(continued)
`
`Page(s)
`
`Other Authorities
`
`37 C.F.R. § 42.100(b) ................................................................................................8
`
`37 C.F.R. § 42.104(b) ..................................................................................28, 29, 46
`
`M.P.E.P. § 2112. ......................................................................................................35
`
`M.P.E.P. § 2141.01(a)........................................................................................31, 54
`
`Microsoft Press Computer Dictionary, pp. 422-423 (Ex. 1009) .............................11
`
`Microsoft Press Computer Dictionary, p. 296 (Ex. 2003).......................................13
`
`-iv-
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`
`I.
`
`INTRODUCTION
`
`Patent Owner Robert Bosch Healthcare Systems, Inc. (“Bosch” or “Patent
`
`Owner”) respectfully requests that the Board decline to initiate inter partes review
`
`of claims 1-19 of U.S. Patent No. 7,516,192 (“the ’192 patent”), because Petitioner
`
`Cardiocom, LLC (“Cardiocom”) has failed to show that
`
`it has a reasonable
`
`likelihood of prevailing with respect to any of the challenged claims. 35 U.S.C.
`
`§ 314. First, Cardiocom fails to meet its initial burden to show that each element
`
`was known in the prior art. Second, where Cardiocom relies on obviousness under
`
`35 U.S.C. § 103(a), Cardiocom fails to show that a person of ordinary skill in the
`
`art would have combined the references as Cardiocom now proposes. In addition,
`
`Cardiocom improperly relies on non-analogous art for Ground 3.
`
`II. OVERVIEW OF THE ’192 PATENT
`
`The ’192 patent describes a system for
`
`remotely monitoring and
`
`communicating with individuals, particularly patients with chronic health
`
`conditions.
`
`(Ex. 1001, 1:39-65, 2:35-39.) Prior attempts to monitor patients
`
`remotely had included the use of personal computers and modems to establish
`
`communication between patients and healthcare providers; however, the inventor
`
`of the ’192 patent found that “computers are too expensive to give away and the
`
`patients who already own computers are only a fraction of the total population.”
`
`(Ex. 1001, 1:66-2:4.) Thus, the ’192 patent teaches away from using personal
`
`1
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`computers to monitor patients.
`
`Another prior attempt was to use interactive telephone or video response
`
`systems; however, the inventor found that such systems were disadvantageous in
`
`that “they either require a patient to call in to a central facility to be monitored or
`
`require the central facility to call the patient according to a rigid monitoring
`
`schedule.”
`
`(Ex. 1001, 2:13-22.)
`
`In the first situation, only compliant patients
`
`would actually call regularly, while non-compliant patients would “wait until an
`
`emergency situation develops before contacting their healthcare provider, thus
`
`defeating the purpose of the monitoring system.” (Ex. 1001, 2:23-28.) On the
`
`other hand, if the system calls each patient according to a schedule, “it is intrusive
`
`to the patient’s life and resistance to the monitoring grows over time.” (Ex. 1001,
`
`2:28-30.) The inventor further observed that “it is difficult to identify each patient
`
`uniquely using these systems,” and “these systems are generally incapable of
`
`collecting medical data from monitoring devices.” (Ex. 1001, 2:30-34.) Thus, the
`
`’192 patent also teaches away from using interactive telephone or video systems
`
`and, instead, identifies “a need for a simple and inexpensive system for remotely
`
`monitoring patients,” “for easily communicating information to the patients,” and
`
`“to encourage patient’s compliance with a prescribed treatment plan.” (Ex. 1001,
`
`2:35-39.)
`
`Thus, the inventor of the ’192 patent invented a system and method for
`
`2
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`remote patient monitoring that does not require a personal computer or the patient
`
`to initiate phone calls. Embodiments of the system include a server, accessible via
`
`a workstation, and multiple remotely programmable apparatus for monitoring
`
`patients. (Ex. 1001, 4:18-33, Fig. 1.) The specification further describes that the
`
`server may transmit script programs to the remote apparatus and receive patient
`
`responses and measurements from the apparatus.
`
`(Ex. 1001, 4:62-5:3, 9:21-39.)
`
`The remote apparatus, which may be located in a patient’s home, for example,
`
`executes the received script program to interact with the patient.
`
`(Ex. 1001, 5:7-
`
`12.) For example, the remote apparatus may display or otherwise transmit a series
`
`of queries to the patient, or prompt the patient to connect a monitoring device and
`
`take measurements therefrom.
`
`(Ex. 1001, 10:16-47.) The remote apparatus may
`
`include input buttons that enable the patient
`
`to provide responses to the queries, which
`
`are recorded by the apparatus and later
`
`transmitted to the server.
`
`(Ex. 1001, 5:21-
`
`25, 10:16-24, 10:58-66.)
`
`In certain embodiments, the server includes a script generator that generates
`
`script programs from script information entered through a workstation, such as by
`
`a healthcare provider. (Ex. 1001, 6:34-41.) This script information may include a
`
`set of potential queries to be answered by the patient, a desired monitoring device
`
`3
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`from which to collect measurements, and/or a set of
`
`statements
`
`to be
`
`communicated to the patient. (Ex. 1001, 6:46-56, 13:19-21.)
`
`The script generator may convert the script information into a script program that
`
`can be executed by the remote apparatus. (Ex. 1001, 6:38-41.)
`
`As illustrated in Figures 6A-6B, the script program can include display
`
`commands to display the queries and response choices, input commands to receive
`
`responses to the queries, and collect commands to collect device measurements
`
`from the monitoring device. (Ex. 1001, 7:1-8:7.) The ’192 patent also describes
`
`exemplary display and input commands, among others, in Table 1:
`
`4
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`(Ex. 1001, 7:22-27.) For example, the display and input commands can be used
`
`for queries to the patient as shown in the following excerpt from Figure 6A:
`
`(Ex. 1001, Fig. 6A (excerpt).)
`
`In certain embodiments, when the remote apparatus connects to the server,
`
`the server transmits a new script program to the remote apparatus for execution.
`
`(Ex. 1001, 9:39-46, 10:66-11:3.) This is one of a number of advantages over the
`
`prior art because a healthcare provider can easily change the queries, prompts to be
`
`displayed, and other operational details of the remote apparatus simply by
`
`transmitting a new script program, without having to manipulate the remote
`
`apparatus directly. (Ex. 1001, 11:15-25.)
`
`The ’192 patent also discloses embodiments that use unique identification
`
`codes to associate script programs with individual patients. For example, each
`
`patient to be monitored may be provided with his or her own remote apparatus,
`
`which has the patient’s unique identification code stored therein. (Ex. 1001, 9:22-
`
`27.) The server may include a script assignor that is used to assign script programs
`
`to the patients based on script assignment information entered through a script
`
`assignment screen.
`
`(Ex. 1001, 8:8-14.) For example, a healthcare provider may
`
`5
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`use a script assignment screen to select a script program to be assigned and patients
`
`to whom the script program is to be assigned.
`
`(Ex. 1001, 8:15-19.) The script
`
`assignor creates for each selected patient a respective pointer to the selected script
`
`program and stores the pointer in a patient look-up table.
`
`(Ex. 1001, 8:21-25.)
`
`Then, when a remote apparatus connects to the server, the remote apparatus may
`
`transmit the patient’s unique identification code, and the server may use the
`
`identification code to retrieve the assigned script program. (Ex. 1001, 9:28-46.)
`
`The script program can also be customized to an individual. For example,
`
`“the queries and statements may be customized to each individual by merging
`
`personal data with the script programs, much like a standard mail merge
`
`application.” (Ex. 1001, 12:58-61.) In these embodiments, the individual may be
`
`identified using a unique identification code, such as in the manner discussed in the
`
`previous paragraph.
`
`(Ex. 1001, 12:61-64.) A server may store personal data
`
`relating to one or more individuals; such data may include the name of the
`
`individual, the name of the treating physician, test results, and appointment dates.
`
`(Ex. 1001, 12:64-13:2.) A script program may include one or more insert
`
`commands specifying data to be inserted into statements or queries in the script
`
`program.
`
`(Ex. 1001, 13:22-29.) The insert commands instruct a data merge
`
`program to retrieve the specified data from the database and to insert the data into
`
`the statement or query. (Ex. 1001, 13:24-26)
`
`6
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`For example, a healthcare provider may enter the following statement to be
`
`included in the script program:
`
`<<INSERT PATIENT_NAME>>, YOUR LAB RESULTS FOR
`HEMOGLOBIN ARE <<INSERT HbA1c_RESULT>>
`
`(Ex. 1001, 13:19-21, Fig. 19.) A script generator may generate a generic script
`
`program from the information that is entered.
`
`(Ex. 1001, 13:33-35.) After a
`
`generic script program is generated, a server may receive script assignment
`
`information, such as in the manner described above.
`
`(Ex. 1001, 13:45-51.) For
`
`each individual selected, a data merge program may retrieve from a database the
`
`data specified in the insert commands and insert the data into the appropriate
`
`statements or queries in the generic scrip program to create a custom script
`
`program for the corresponding individual.
`
`(Ex. 1001, 13:51-60.) Each custom
`
`script program may be stored in a database and assigned to the corresponding
`
`individual by creating a pointer and storing the pointer with the individual’s unique
`
`identification code. (Ex. 1001, 13:60-67.)
`
`Claims 1-19 of the ’192 patent are generally directed to a monitoring system
`
`for communicating with at least one individual. The claims generally recite a
`
`computer configured to communicate with a remotely situated apparatus; a user
`
`interface for entering, authoring, or selecting messages, queries, or response
`
`choices to be presented to the individual; a data merge program configured to
`
`7
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`generate a customized script program by customizing a generic script program; and
`
`a database accessible by the data merge program for storing the generic script
`
`program and responses received from the remotely situated apparatus. The claims
`
`generally further recite that the custom script program is to be executed by the
`
`remotely situated apparatus and includes (1) a display command to present to the
`
`individual
`
`the messages, queries, and/or response choices, and (2) an input
`
`command to receive responses. (Ex. 1001, 20:51-22:24.)
`
`During prosecution,
`
`the Examiner included the following statement of
`
`reasons for allowing the claims of the ’192 patent:
`
`The prior [sic] of record fail to disclose generating a customized script
`program by customizing a generic script program, wherein the
`customized script program is to be executed by the remotely situated
`apparatus and includes a display command to present to the individual
`at least one of the one or more messages, the one or more queries, the
`one or more response choices corresponding to the one or more
`queries or any combination thereof and an input command to receive
`responses when the script program includes one or more queries to be
`presented.
`
`(Ex. 1007, Notice of Allowability, Page 2.)
`
`III. CLAIM CONSTRUCTION
`
`In an inter partes review, patent claims are given their “broadest reasonable
`
`construction in light of the specification of the patent.” 37 C.F.R. § 42.100(b);
`
`8
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`Phillips v. AWH Corp., 415 F.3d 1303, 1316 (Fed. Cir. 2005) (en banc). The
`
`prosecution history is also relevant to identify the correct construction of claim
`
`terms. Phillips v. AWH Corp., 415 F.3d at 1317. Extrinsic evidence may also be
`
`relevant to establish the meaning of terms, but such evidence is only relevant to the
`
`extent it is consistent with the specification and file history. Id. at 1319.
`
`Bosch proposes construction of certain claim terms below pursuant to the
`
`broadest reasonable interpretation consistent with the specification standard. The
`
`proposed claim constructions are offered for the sole purpose of this proceeding
`
`and thus do not necessarily reflect appropriate claim constructions to be used in
`
`litigation and other proceedings wherein a different claim construction standard
`
`applies. Bosch may further address the proper construction of these and other
`
`terms as may be necessary or appropriate if inter partes review is instituted.
`
`Cardiocom has proposed constructions for the terms: “script program;” “data
`
`merge program;” “script assignment unit;” and “pointer.” Cardiocom’s proposed
`
`constructions for at least “script program” and “data merge program,” however, do
`
`not comport with claim construction standards and fail to take into account the
`
`relevant provisions from the specification, prosecution history, and extrinsic
`
`evidence, and therefore should be rejected in favor of the appropriately tailored
`
`constructions offered by Bosch below.
`
`9
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`A.
`“Script Program”
`
`Claim Term Bosch Proposed Construction Cardiocom Proposed Construction
`“script
`“a set of instructions or
`“a program including at least one
`program”
`commands written in a
`text
`command
`and
`can
`be
`language that can be
`interpreted and performed by a
`interpreted and executed by
`device,
`such
`as
`a
`computer”
`another program”
`(Petition, 12)
`
`The claims recite a “script program.” For example, claim 1 recites “the
`
`customized script program is to be executed by the remotely situated apparatus and
`
`includes (i) a display command…and (ii) an input command.” (Ex. 1001, 20:64-
`
`21:4 (emphasis added).) To the extent that any construction is necessary, Bosch
`
`submits that a “script program” is “a set of instructions or commands written in a
`
`language that can be interpreted and executed by another program.” This proposed
`
`construction is the broadest reasonable interpretation that can be supported by the
`
`specification of the ’192 patent. In contrast, Cardiocom’s proposed construction is
`
`unreasonably overbroad, as it would purport to encompass any program so long as
`
`it contained a “text command.”
`
`The specification of the ’192 patent describes a script program as follows:
`
`In the preferred embodiment, each script program 40 created by script
`generator 50 conforms to the standard file format used on UNIX
`systems. . . . Every line in the script program 40 is terminated by a
`linefeed character {LF}, and only one command is placed on each
`line. . . . Table 1 shows an exemplary listing of script commands used
`
`10
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`in the preferred embodiment of the invention. . . . it will be apparent to
`one skilled in the art many other suitable scripting languages and sets
`of script commands may be used to implement the invention.
`
`(Ex. 1001, 7:1-10, 7:51-55 (emphasis added).) Thus, a script program would be
`
`understood to contain script commands that are part of a scripting language.
`
`Further, the specification describes how a script program is executed:
`
`The microprocessor 76 also includes built-in read only memory
`(ROM), which stores firmware for controlling the operation of the
`apparatus 26. The firmware includes a script interpreter used by the
`microprocessor 76 to execute the script programs 40. The script
`interpreter interprets script commands, which are executed by the
`microprocessor 76. Specific techniques for interpreting and executing
`script commands in this manner are well known in the art.
`
`(Ex. 1001, 5:53-60 (emphasis added).) Thus, script commands in a script program
`
`are interpreted and executed by other software (the script interpreter).
`
`Bosch’s proposed construction is also supported by the extrinsic evidence
`
`submitted by Cardiocom. Specifically, the Microsoft Press Computer Dictionary,
`
`cited by Cardiocom and its expert, defines a script as “a program consisting of a set
`
`of instructions to an application or utility program. The instructions usually use the
`
`rules and syntax of the application or utility.”
`
`(Ex. 1009, 422-423 (emphasis
`
`added).) Like the specification and Bosch’s proposed construction, this definition
`
`conveys that a script program contains instructions/commands that are written in
`
`11
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`the language/syntax of another program/application to be executed by that
`
`program/application.
`
`Cardiocom, however, proposes the construction “a program including at
`
`least one text command and can be interpreted and performed by a device, such as
`
`a computer.” (Petition, 12.) Contrary to the specification and extrinsic evidence,
`
`Cardiocom’s proposed construction fails to mention that a script program is
`
`executed by another program, not simply by a device.
`
`In addition, Cardiocom’s
`
`proposed construction uses the phrase “text command,” which appears in neither
`
`the ’192 patent nor the proffered dictionary definition.
`
`It
`
`is unclear what
`
`Cardiocom means by “text command,” and Cardiocom fails to explain why a
`
`“script program” would necessarily include a “text command.”
`
`B.
`
`“Data Merge Program”
`
`Claim Term Bosch Proposed Construction Cardiocom Proposed Construction
`“data merge
`“software that takes data and
`“a software module that combines
`program”
`inserts the data into a script
`two or more sets of items into one”
`program or other template”
`(Petition, 13)
`
`The claims recite a “data merge program.” For example, claim 1 recites “a
`
`data merge program configured to generate a customized script program by
`
`customizing a generic script program.” (Ex. 1001, 20:62-63 (emphasis added).)
`
`To the extent that any construction is necessary, Bosch submits that a “data merge
`
`program” is “software that takes data and inserts the data into a script program or
`
`12
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`other template.” Bosch’s proposed construction is the broadest reasonable
`
`interpretation that can be supported by the claims and specification of the ’192
`
`patent.
`
`In contrast, Cardiocom’s proposed construction is unreasonably broad
`
`because it completely eliminates all of the context provided by the specification by
`
`failing to reflect the fundamental characteristic of the claimed data merge program,
`
`which is disclosed and would be understood to be analogous to a mail merge
`
`application.
`
`The ’192 patent discloses that “[t]he data merge program 55 is designed to
`
`retrieve selected data from table 46 and to insert the data into statements in generic
`
`script programs 40, thus creating custom script programs 41.” (Ex. 1001, 13:7-10.)
`
`The ’192 patent further discloses that the embodiment including a data
`
`merge program “shows how the queries and statements may be customized to each
`
`individual by merging personal data with the script programs, much like a standard
`
`mail merge application.” (Ex. 1001, 12:58-61 (emphasis added).) As indicated by
`
`the ’192 patent, “mail merge” had an understood meaning in the art at the time of
`
`the invention. The Microsoft Press Computer Dictionary, for example, defines
`
`“mail merge” as “a mass-mail facility that takes names, addresses, and sometimes
`
`pertinent facts about recipients and merges the information into a form letter or
`
`another such basic document.” (Ex. 2003, 296.) The ’192 patent discloses that the
`
`data merge program operates in similar fashion to a mail merge program, except
`
`13
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`the data merge program is used to customize a script program instead of a form
`
`letter. Specifically, the ’192 patent states:
`
`the script generator 50 generates a generic script program . . . [T]he
`generic script program is similar to the script program shown in FIG.
`6A-6B, except that the display commands specify statements to be
`displayed rather than queries. Further, the statements include insert
`commands specifying data to be inserted into the script program. . . .
`
`Each custom script program 41 is preferably created by using the
`selected generic script program as a template. For each individual
`selected, the data merge program 55 retrieves from the database 38 the
`data specified in the insert commands. Next, the data merge program
`55 inserts the data into the appropriate statements in the generic script
`program 40 to create a custom script program 41 for the individual.
`
`(Ex. 1001, 13:33-40, 13:54-60.) Thus, the disclosed data merge program takes
`
`data and inserts it into a template, such as generic script program.
`
`Cardiocom, however, proposes the construction “a software module that
`
`combines two or more sets of items into one.”
`
`(Petition, 13.) This proposed
`
`construction is too broad in light of the claim language and the function of the data
`
`merge program described in the specification. Cardiocom incorrectly relies on the
`
`generic computer
`
`science term “merging,” which Cardiocom defines as
`
`“combining two or more sets of items into one, usually in a specified sequence.”
`
`(Petition, 13.) Cardiocom’s construction, and this generic definition, fail
`
`to
`
`account for the language of the claims, which recites that “data” is merged by the
`
`14
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`“data merge program.” Cardiocom improperly substitutes the vague term “item”
`
`for
`
`the well-understood term “data.”
`
`For
`
`this reason alone, Cardiocom’s
`
`construction must be rejected. Furthermore, the ’192 patent refers to the “data
`
`merge program” as being like a “mail merge application,” which is more specific
`
`than merging generally. In light of the parallels in function between the disclosed
`
`“data merge program” and a “mail merge,” it
`
`is not reasonable to adopt a
`
`construction as broad as Cardiocom’s, which includes “merging” of any “items”
`
`and not only “data,” and includes any kind of “merging” and not only merging data
`
`into a template.
`
`Cardiocom’s proposed construction should also be rejected because, even
`
`though it is too broad, it nonetheless fails to cover the disclosed embodiment. See
`
`Accent Packaging, Inc. v. Leggett & Platt, Inc., 707 F.3d 1318, 1326 (Fed. Cir.
`
`2013) (“[A] claim interpretation that excludes a preferred embodiment from the
`
`scope of the claim is rarely, if ever, correct.”). The specification discloses that
`
`“[t]he data merge program 55 is designed to retrieve selected data from table 46
`
`and to insert the data into statements in generic script programs 40, thus creating
`
`custom script programs 41.” (Ex. 1001, 13:7-10 (emphasis added).)
`
`In contrast,
`
`Cardiocom’s proposed construction requires that
`
`the data merge program
`
`“combine[] two or more sets of items into one.” This fails to cover the disclosed
`
`embodiment in two ways: First, Cardiocom’s proposed construction requires “two
`
`15
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`or more sets of items.” But the specification refers only to “retriev[ing] selected
`
`data,” not multiple sets of items. Second, Cardiocom’s proposed construction
`
`requires “combin[ing]…sets of items into one [set of items].” But the specification
`
`discloses that the data merge program inserts data into a generic script program to
`
`create a custom script program; accordingly, the result of the merge is a custom
`
`script program, not a combined set of items. The generic script program is not a
`
`“set of items,” but rather is like a template that can be populated with data. Thus,
`
`Cardiocom’s proposed construction is contradicted by the specification and must
`
`be rejected.
`
`IV. OVERVIEW OF THE ASSERTED REFERENCES
`
`Cardiocom’s proposed grounds for challenge rely on three references: (1)
`
`U.S. Patent No. 5,704,029 to Wright, Jr. (“Wright”); (2) U.S. Patent No. 5,827,180
`
`to Goodman (“Goodman”); and (3) U.S. Patent No. 5,367,667 to Wahlquist et al.
`
`(“Wahlquist”). However, each of these references fails to teach certain claim
`
`elements including at least a “data merge program” and a “customized script
`
`program…includ[ing] (i) a display command…and (ii) an input command.” In
`
`addition, as an independent basis for rejecting Grounds 2 and 3, there is no reason
`
`for a person of ordinary skill in the art to have combined these references as
`
`Cardiocom proposes because they teach away from each other and involve non-
`
`analogous art.
`
`16
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No. 7,516,192)
`A. Wright
`
`Wright is directed to “business forms and, more particularly, to systems for
`
`electronically creating and completing a business form.”
`
`(Ex. 1002, 1:19-21.)
`
`Unlike the ’192 patent, Wright does not teach monitoring and communicating with
`
`patients. Wright is directed to “a system which (1) inexpensively creates new and
`
`modifies existing forms, (2) automatically handles skip patterns, (3) performs error
`
`validation as the form is filled out, (4) reduces error by limiting the presentation of
`
`information to a survey taker, and (5) is mobile.” (Ex. 1002, 3:1-5.)
`
`Thus, Wright teaches that two important aspects of its system are the ability
`
`to handle “skip patterns” and to limit the information presented to a survey taker.
`
`Wright explains the problem of “skip patterns” as follows:
`
`Many forms, especially questionnaires, contain complex sequences of
`jumps to other parts of the form in the questionnaire depending on
`information filled in. For instance, if a question asks for gender, the
`subsequent skip instruction could be “If you answered male to the
`previous question, go to question 10” and the answer to question 10
`may also be the subject of a skip instruction. These instructions are
`collectively known as skip patterns. Often times survey takers will
`become lost trying to follow the skip pattern and will answer a
`question that should not be answered.
`
`(Ex. 1002, 2:7-17.) Wright teaches handling skip patterns by presenting a single
`
`item or question at a time to the survey taker and, in between items or questions,
`
`17
`
`

`

`Patent Owner’s Preliminary Response
`IPR2013-00468 (Patent No