`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`In re U.S. Patent No. 7,516,192
`
`Trial Number: IPR2013-00469
`
`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
`
`Page
`
`INTRODUCTION ..........................................................................................1
`I.
`OVERVIEW OF THE ’192 PATENT ...........................................................1
`II.
`III. CLAIM CONSTRUCTION ...........................................................................9
`A.
`“Script Program” ................................................................................10
`IV. OVERVIEW OF THE ASSERTED REFERENCES ..................................13
`A. Wright.................................................................................................14
`B.
`Goodman ............................................................................................18
`C. Wahlquist............................................................................................21
`GROUND 1 OF THE PETITION SHOULD NOT BE CONSIDERED
`PURSUANT TO 37 C.F.R. § 42.104(B)(2) .................................................24
`VI. NO INTER PARTES REVIEW SHOULD BE INITIATED BECAUSE
`THE PRIOR ART DOES NOT INVALIDATE ANY CLAIM...................27
`Overview Of Reasons for Denying Inter Partes Review ..................27
`A.
`B.
`The Prior Art Does Not Teach a Customized Script Program for
`Presenting Messages or Queries and for Receiving Responses.........28
`1. Wright Does Not Teach the Claimed Script Program .............29
`2.
`Goodman Does Not Teach the Claimed Script Program.........31
`3. Wahlquist Does Not Teach the Claimed Script Program........32
`Additional Reasons No Review Should Be Instituted for
`Ground 1.............................................................................................34
`Additional Reasons No Review Should Be Instituted for
`Ground 2.............................................................................................37
`1.
`Goodman and Wright Do Not Teach Storing the Generic
`Script Program in a Database...................................................38
`Goodman and Wright Do Not Teach Transmitting a
`Customized Script in Response to Receipt of an
`Identification Code...................................................................39
`A Person of Ordinary Skill in the Art Would Not Have
`Combined Goodman and Wright in the Manner Asserted ......44
`
`V.
`
`C.
`
`D.
`
`2.
`
`3.
`
`-i-
`
`
`
`TABLE OF CONTENTS
`(continued)
`
`Page
`
`E.
`
`Additional Reasons No Review Should Be Instituted for
`Ground 3.............................................................................................47
`1. Wahlquist Is Not Directed to Communication Systems
`for Remote Monitoring of Individuals.....................................48
`Goodman and Wahlquist Do Not Teach Generating a
`Customized Script Program by Customizing a Generic
`Script Program .........................................................................51
`A Person of Ordinary Skill in the Art Would Not Have
`Combined Goodman and Wahlquist in the Manner
`Asserted....................................................................................57
`VII. CONCLUSION.............................................................................................60
`
`2.
`
`3.
`
`-ii-
`
`
`
`TABLE OF AUTHORITIES
`
`Page(s)
`
`Cases
`In re Bigio,
`381 F.3d 1320 (Fed. Cir. 2004) ..........................................................................48
`
`In re Clay,
`966 F.2d 656 (Fed. Cir. 1992) ............................................................................59
`
`Heart Failure Techs., LLC v. Cardiokinetix, Inc.,
`IPR2013-00183, 2013 Pat. App. LEXIS 5602 (PTAB July 31, 2013)...............37
`
`In re Klein,
`647 F.3d 1343 (Fed. Cir. 2011) ..............................................................28, 48, 59
`
`KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007)............................................................................................28
`
`Largan Precision Co., Ltd. v. Fujifilm, Corp.,
`2012 Pat. App. LEXIS 2916 (BPAI 2012) .........................................................46
`
`Liberty Mutual Ins. Co. v. Progressive Casualty Ins. Co.,
`CBM2012-00003, 2012 Pat. App. LEXIS 7236 (PTAB Oct. 25, 2012)......26, 37
`
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) (en banc)............................................................9
`
`In re Robertson,
`169 F.3d 743 (Fed. Cir. 1999) ................................................................39, 42, 52
`
`Statutes
`
`35 U.S.C. § 102..................................................................................................24, 25
`
`35 U.S.C. § 103(a) ............................................................................................passim
`
`35 U.S.C. § 314..........................................................................................................1
`
`Other Authorities
`
`37 C.F.R. § 42.100(b) ................................................................................................9
`
`-iii-
`
`
`
`37 C.F.R. § 42.104 .............................................................................................25, 34
`
`M.P.E.P. § 2141.01(a)........................................................................................28, 48
`
`M.P.E.P. § 2112 .................................................................................................39, 52
`
`Microsoft Press Computer Dictionary, pp. 422-423 (Ex. 1009) .............................12
`
`-iv-
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (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 20-37 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.”
`
`1
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`(Ex. 1001, 1:66-2:4.) Thus, the ’192 patent teaches away from using personal
`
`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.)
`
`2
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`Thus, the inventor of the ’192 patent invented a system and method for
`
`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
`
`3
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`set of potential queries to be answered by the patient, a desired monitoring device
`
`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-00469 (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-
`
`26.) 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-00469 (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-00469 (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 20-36 of the ’192 patent are generally directed to a method for
`
`communicating with at least one individual. The claims generally recite the steps
`
`of generating a generic script program in a computer, generating a customized
`
`script program in the computer by customizing the generic script program,
`
`transmitting the customized script program to a remotely situated apparatus, and
`
`7
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`storing the generic script program and any responses received from the remotely
`
`situated apparatus in one or more databases. The claims further generally recite
`
`that the customized script program includes (1) a display command to present to
`
`the individual messages, queries, and/or response choices, and (2) an input
`
`command to receive responses.
`
`(Ex. 1001, 22:25-24:14.) Claim 37 of the ’192
`
`patent is generally directed to an apparatus for communicating with a computer
`
`remotely situated from the apparatus and generally recites many of the same
`
`features of a customized script program. (Ex. 1001, 24:15-47.)
`
`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.)
`
`8
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`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);
`
`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.
`
`Patent Owner 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. Patent Owner 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.” The term “data merge
`
`9
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`program,” however, does not appear in any of the challenged claims. Bosch
`
`therefore submits that the term does not require construction in this proceeding.1
`
`In addition, Cardiocom’s proposed construction for at least “script program”
`
`does not comport with claim construction standards and fails 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
`
`construction offered by Bosch below.2
`
`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)
`
`1 The term “data merge program” is used in claims 1-19 of the ’192 patent, which
`
`Cardiocom has challenged in a separate petition assigned Trial Number IPR2013-
`
`00468. Bosch disputes Cardiocom’s proposed construction and addresses the
`
`proper construction of “data merge program” in its Preliminary Response filed in
`
`that proceeding.
`
`2 Bosch will address Cardiocom’s proposed constructions for “pointer” and “script
`
`assignor” as may be necessary or appropriate if inter partes review is instituted.
`
`10
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`The claims recite a “script program.” For example, claim 20 recites “the
`
`customized script program includes (i) a display command . . . and (ii) an input
`
`command.”
`
`(Ex. 1001, 22:38-45 (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
`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:
`
`11
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`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
`
`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,
`
`12
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`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.”
`
`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 at
`
`least a
`
`customized script program for presenting messages or queries and for receiving
`
`responses as required by the claims.3
`
`In addition, as an independent basis for
`
`3 Specifically, claim 20 recites “the customized script program includes (i) 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 (ii) an
`
`input command to receive responses when the script program includes one or more
`
`queries to be presented” (Ex. 1001, 22:38-45) and claim 37 recites “the stored
`
`customized script program when executed causes the apparatus to communicate at
`
`13
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`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.
`
`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
`
`least one of (i) one or more messages, (ii) one or more queries, (iii) one or more
`
`response choices corresponding to the one or more queries, or any combination
`
`thereof to the individual [and] to receive the responses to the one or more queries,
`
`if present, from the individual” (Ex. 1001, 24:39-44).
`
`14
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`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,
`
`executing a “script”4 that may “go to another question based on the previous
`
`answer(s).” (Ex. 1002, 3:41-51, 7:14-20.) “Thus, complex skip patterns may be
`
`utilized without burdening the user about which question is next, what questions
`
`are to be left blank or skipped, and so forth.” (Ex. 1002, 7:20-23.)
`
`More generally, Wright teaches a system with “a forms creation and forms
`
`completion mode.” (Ex. 1002, 6:30-32.) Wright teaches that “if a new form is
`
`necessary, or if a previous form needs to be revised or customized, a forms creator
`
`4 While Wright uses the term “script,” what Wright calls a “script” differs from the
`
`generic and customized script programs claimed in the ’192 patent for numerous
`
`reasons set forth herein. Thus, though this Preliminary Response refers to “scripts”
`
`in the context of Wright, that should be understood as different from the claimed
`
`“script program.”
`
`15
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`or forms designer creates the new form . . . by use of a forms creation program.”
`
`(Ex. 1002, 6:33-39.) After the form is built, “form descriptors or field description
`
`records, which define each of the form’s fields,” may be transferred to a portable
`
`computer.
`
`(Ex. 1002, 6:40-43.) Wright further teaches that a “forms engine” on
`
`the portable computer “displays one question or statement (and if appropriate, a
`
`corresponding set of possible answers or responses) at a time,” and, when the user
`
`answers each question, executes the script for that question.
`
`(Ex. 1002, 7:6-10,
`
`7:14-20.) Wright further teaches that, after a user completes a particular form, the
`
`collected data is stored in the portable computer and may optionally be sent to a
`
`host computer for further processing. (Ex. 1002, 7:33-37.)
`
`The system of Wright differs from the system described and claimed in the
`
`’192 patent an important respect: unlike the system of the ’192 patent, the system
`
`of Wright does not use script programs to present queries and response choices to
`
`an individual. Instead, Wright teaches using a “script” between each question-and-
`
`answer pair to handle skip patterns or to perform other functions, such as data
`
`validation. The questions and answer choices are not themselves part of the script.
`
`Specifically, Wright teaches that a form consists of a series of numbered
`
`“fields,” which are defined by “field description records,” which in turn consist of
`
`“attributes.” (Ex. 1002, 6:40-45, 8:10-13, 8:46-47, 9:11-12, 9:56-58, 10:14-15.)
`
`The attributes within a field description record include number, offset, prompt,
`
`16
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`answers, and script.
`(Ex. 1002, 9:56-58, 9:61-65, 10:14-21, Figs. 2b & 2c.) For
`
`example, the following excerpt from Figure 2b shows several different attributes
`
`and the contents of each:
`
`(Ex. 1002, Fig. 2b (excerpt).) In particular, the foregoing excerpt makes clear that
`
`Wright’s script does not contain the prompt or answers, which are separate
`
`attributes.
`
`Wright further makes clear that its script is not used to display queries and
`
`answer choices in describing the operation of the forms engine. Specifically,
`
`Wright teaches that only “[i]f the field type is not script” will “the forms engine
`
`124 move[] to a ‘draw field’ function 316 that generates a screen display for the
`
`current field being processed.” (Ex. 1002, 14:66-15:2 (emphasis added).) It is the
`
`draw field function that displays the prompt from the prompt field of the current
`
`field description record.
`
`(Ex. 1002, 17:31-45.) After generating the screen
`
`17
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`display, the forms engine collects input from the user and saves it into the form
`
`data array.
`
`(Ex. 1002, 15:9-55.) Wright teaches that only after the data is saved
`
`does “the forms engine 124 proceed[] to the ‘execute script’ function 354.” (Ex.
`
`1002, 15:58-61.) Thus, the script of Wright does not display queries or receive
`
`responses from the user as claimed in the ’192 patent. Instead, the script of Wright
`
`executes after the query has been displayed and any responses already received.
`
`Thus, Wright does not teach a customized script program for presenting messages
`
`or queries and for receiving responses, as claimed in claims 20-37.
`
`B. Goodman
`
`Goodman is directed to “a system, methods and apparatus for monitoring a
`
`person’s health, and more particularly to a comprehensive patient management
`
`system.” (Ex. 1003, 1:11-13.) Goodman was considered by the examiner during
`
`prosecution of the ’192 patent. (Ex. 1001, Page 3.)
`
`Goodman discloses a “personal health network” that includes (1) a host
`
`computer and (2) a data processor and message device in the possession of a
`
`patient. (Ex. 1003, 2:44-51.) Goodman teaches that algorithms, developed based
`
`on a treatment plan for the patient, may be “programmed into an appropriately
`
`configured message device.” (Ex. 1003, 2:54-58.) Goodman also teaches that
`
`“[t]he message device 20 is a portable device, of suitable shape and size to be
`
`carried in the pocket, purse or briefcase of a patient. Preferably the form factor and
`
`18
`
`
`
`Patent Owner’s Preliminary Response
`IPR2013-00469 (Patent No. 7,516,192)
`industrial design of the message device 20 are optimized for acceptance by the
`
`intended user, including children and senior citizens.” (Ex. 1003, 4:23-27.) The
`
`message device may prompt
`
`the patient
`
`to measure and enter
`
`relevant
`
`physiological data as dictated by the treatment plan, and results may b