Paper No. 6
`
`Trials@uspto.gov
`571-272-7822 Entered: July 30, 2019
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`UNIFIED PATENTS INC.
`Petitioner,
`
`v.
`
`SMTM TECHNOLOGIES, LLC
`Patent Owner.
`____________
`
`Case IPR2019-00434
`Patent 8,958,853 B1
`____________
`
`
`
`Before NEIL T. POWELL, GEORGIANNA W. BRADEN, and
`SHARON FENICK Administrative Patent Judges.
`
`FENICK, Administrative Patent Judge.
`
`
`
`DECISION
`Denying Institution of Inter Partes Review
`35 U.S.C. § 314(a)
`
`
`
`
`
`I. INTRODUCTION
`
`Unified Patents Inc. (“Petitioner”) filed a Petition requesting inter
`
`partes review of claims 1–7 (“the challenged claims”) of U.S. Patent
`
`No. 8,958,853 B1 (Ex. 1001, “the ’853 patent”). Paper 1 (“Pet.”). Patent
`
`
`
`Trials@uspto.gov
`571-272-7822 Entered: July 30, 2019
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`UNIFIED PATENTS INC.
`Petitioner,
`
`v.
`
`SMTM TECHNOLOGIES, LLC
`Patent Owner.
`____________
`
`Case IPR2019-00434
`Patent 8,958,853 B1
`____________
`
`
`
`Before NEIL T. POWELL, GEORGIANNA W. BRADEN, and
`SHARON FENICK Administrative Patent Judges.
`
`FENICK, Administrative Patent Judge.
`
`
`
`DECISION
`Denying Institution of Inter Partes Review
`35 U.S.C. § 314(a)
`
`
`
`
`
`I. INTRODUCTION
`
`Unified Patents Inc. (“Petitioner”) filed a Petition requesting inter
`
`partes review of claims 1–7 (“the challenged claims”) of U.S. Patent
`
`No. 8,958,853 B1 (Ex. 1001, “the ’853 patent”). Paper 1 (“Pet.”). Patent
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`Owner SMTM Technologies, LLC (“Patent Owner”) did not file a
`
`Preliminary Response. See Paper 5, 1. We have jurisdiction under 35
`
`U.S.C. § 314.
`
`Upon consideration of the Petition, Petitioner has failed to
`
`demonstrate a reasonable likelihood that it would prevail in showing the
`
`unpatentability of at least one challenged claim of the ’853 patent.
`
`Accordingly, Petitioner’s request to institute inter partes review is denied.
`
`II. BACKGROUND
`
`A. Related Matters and Real Parties in Interest
`
`Petitioner states that the ’853 patent was asserted in SMTM
`
`Technology, LLC v. Apple Inc., Case No. 3:18-cv-04111 (N.D. Cal.) and
`
`SMTM Technology, LLC v. Microsoft Corp., Case No. 3:15-cv-02396 (N.D.
`
`Cal.). Pet. 1–2. Patent Owner states that there are no related matters. Paper
`
`5, 1 (Patent Owner’s Mandatory Notices).
`
`Petitioner identifies only itself as the real party in interest. Pet. 1.
`
`Patent Owner also identifies only itself as the real party in interest. Paper 5,
`
`1.
`
`B. Overview of the ’853 Patent
`
`The ’853 patent relates to “a mobile device including functionality for
`
`suppressing communications to a user and systems for verifying that a user
`
`was not receiving communications during a particular period of time.”
`
`Ex. 1001, 1:50–54, 6:57–60. This is done to prevent distracted driving. Id.
`
`at 1:22–28, 2:2–3, 19–21, 37–39, 6:60–64. The suppressed communications
`
`may be, for example, notifications of incoming phone calls, text messages,
`
`or emails, or notifications from mobile device applications. Id. at 1:55–58,
`
`1:66–2:1. Thus, when the device is in inactive mode, normal user
`
`2
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`notifications of communication events, such as ringing, vibration, or screen
`
`activation, are suppressed. Id. at 1:66–2:1, 2:19–23, 42–45, 3:6–12.
`
`Additionally, optionally, when a communication is received at the
`
`mobile device, the mobile device sends an “away message” to the sender of
`
`a communication, “in order to reassure senders that they will receive a
`
`response at the earliest convenient opportunity.” Id. at 1:66–2:8, 2:24–25,
`
`3:16–25. The user can configure the away message or choose from among
`
`several away messages before the device enters inactive mode. Id. at 3:29–
`
`32.
`
`A user can customize the behavior of the mobile device during
`
`inactive mode using a graphical user interface on the mobile device. Id. at
`
`8:26–37, 9:15–25. Figure 5c, reproduced below, depicts a mobile device
`
`with an interface showing a custom message selection screen including
`
`example “away messages.” Id. at 6:26–28.
`
`Figure 5c shows an away message selection screen 560, which allows
`
`the user to select a specific away message to be used from away
`
`
`
`3
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`messages 575. Id. at 8:36–38. The away message selection screen can be
`
`used to enable a user to create custom “away messages” and select a
`
`message to be transmitted to the sender of a communication when the
`
`mobile device is in inactive mode. Id. at 8:24–38.
`
`Figure 3, reproduced below, is “a flow chart illustrating a method
`
`carried out by a mobile device to provide for an inactive mode.” Id. at 6:8–
`
`9.
`
`
`
`4
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`As shown above in Figure 3, the method provides five sequential
`
`steps: placing a device into inactive mode (301); detecting an incoming
`
`communication (302), suppressing notification (303); transmitting an away
`
`message to the sender of the communication (304); and, upon completion of
`
`the inactive mode, notifying the user of missed communications (305). Id.
`
`at 7:37–49, 8:4–6, 8:14–16, 8:24–26, 8:53–55.
`
`The inactive mode may be activated in different ways: through a user
`
`activating a button on a user interface; according to a pre-set schedule; when
`
`driving directions functionality of a mobile device is being used; upon
`
`pairing of the mobile device with a vehicle; by a remote user; or when the
`
`mobile device enters a particular location. Id. at 2:29–42, 3:4–5, 5:9–12,
`
`5:19–24, 7:47–67. “[A]ny input that may indicate that the user is not to be
`
`distracted may be used to place the device in inactive mode.” Id. at 7:67–
`
`8:2.
`
`C. Illustrative Claim
`
`Of the challenged claims, claim 1 is independent. Claim 1 is
`
`reproduced below, with bracketed notations, corresponding in part to
`
`notations in the petition,1 added for reference.
`
`1. [a] A mobile device, comprising:
`
`a wireless communication module;
`
`[b] a
`
`controlling
`processor,
`communication module; and
`
`the wireless
`
`[c] a memory controlled by the processor, the
`memory including instructions that when
`
`
`1 Petitioner does not provide a label for one limitation of claim 1, we
`reference it with the notation “[*]”.
`
`5
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`the processor cause
`executed by
`processor to perform the steps of:
`
`the
`
`interface
`[d] providing a graphical user
`through which a user customizes one
`or more functions of the mobile device
`when placed in an inactive mode;
`
`[e] receiving a user selection to automatically
`initiate the inactive mode in response
`to the pairing of the mobile device with
`a vehicle;
`
`[f] receiving a user selection of an away
`message to use when the mobile device
`is in inactive mode;
`
`[*] in response to the pairing of the mobile
`device and the vehicle, automatically
`initiating a process to place the mobile
`device in inactive mode;
`
`[g] when the mobile device is in inactive
`mode, in response to receiving a
`communication
`from
`the wireless
`communication module, transmitting
`the user selected away message via the
`wireless module and suppressing one
`or more sound, visual, or vibration
`communication cues that would have
`accompanied the communication had
`the mobile device not been in inactive
`mode.
`
`Ex. 1001, 12:36–61.
`
`6
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`D. Evidence Relied Upon
`
`Reference
`
`Riemer et al.
`(“Riemer”)
`Guba et al.
`(“Guba”)
`Olincy et al.
`(“Olincy”)
`Chaudhri et al.
`(“Chaudhri”)
`
`Publication Date
`
`Exhibit
`
`US 2010/0216509 A1
`
`Aug. 26, 2010
`
`1007
`
`US 2011/0009107 A1
`
`Jan. 13, 2011
`
`1008
`
`US 2011/0151838 A1
`
`June 23, 2011
`
`1010
`
`US 2013/0332721 A1
`
`Dec. 12, 2013
`
`1011
`
`Petitioner also relies upon the Declaration of Scott Andrews.
`
`(Ex. 1005).
`
`E. Asserted Grounds of Unpatentability
`
`Petitioner asserts the following grounds of unpatentability:
`
`References
`
`Claim(s) Challenged
`
`Riemer and Guba
`
`Guba, Olincy, and Chaudhri
`
`Guba, Olincy, Chaudhri, and Riemer
`
`1–7
`
`1–7
`
`3
`
`III. DISCUSSION
`
`A. Person of Ordinary Skill in the Art
`
`Petitioner asserts that the proper level of ordinary skill in the art is of
`
`someone with “at least an undergraduate degree or equivalent in electrical
`
`engineering, computer engineering, or computer science, or a master’s
`
`degree in information science,” with the caveat that relevant practical
`
`experience could offset less or different education. Pet. 17; see also
`
`Ex. 1005 ¶ 28 (Declarant testifies to a slightly different level of skill in the
`
`art, which we determine to be essentially equivalent to that in the Petition).
`
`7
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`For purposes of this Decision, we adopt Petitioner’s provided
`
`definition for the level of skill of a person of ordinary skill in the art as
`
`reasonable and consistent with the prior art. See Okajima v. Bourdeau, 261
`
`F.3d 1350, 1355 (Fed. Cir. 2001) (the prior art may reflect an appropriate
`
`level of skill in the art).
`
`B. Claim Construction
`
`We apply the same claim construction standard that is applied in civil
`
`actions under 35 U.S.C. § 282(b), which is articulated in Phillips v. AWH
`
`Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc). See Changes to the Claim
`
`Construction Standard for Interpreting Claims in Trial Proceedings Before
`
`the Patent Trial and Appeal Board, 83 Fed. Reg. 51340 (Oct. 11, 2018)
`
`(applicable to inter partes reviews filed on or after November 13, 2018).
`
`Under Phillips, claim terms are afforded “their ordinary and customary
`
`meaning.” Phillips, 415 F.3d at 1312. “[T]he ordinary and customary
`
`meaning of a claim term is the meaning that the term would have to a person
`
`of ordinary skill in the art in question at the time of the invention.” Id. at
`
`1313. “Claim construction begins with the words of the claim, which ‘must
`
`be read in view of the specification, of which they are a part.’” Wi-Lan, Inc.
`
`v. Apple, Inc., 811 F.3d 455, 462 (Fed. Cir. 2016) (quoting Phillips, 415
`
`F.3d at 1312–15).
`
`Only terms that are in controversy need to be construed, and then only
`
`to the extent necessary to resolve the controversy. Vivid Techs., Inc. v. Am.
`
`Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).
`
`1. “inactive mode”
`
`Petitioner proposes we construe “inactive mode” to include “any
`
`mode ‘that indicates that the user is not to be distracted.’” Pet. 17–18 (citing
`
`8
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`Ex. 1001, 2:43–44; Ex. 1005 ¶¶ 83–84). We note that the portion of the
`
`’853 patent quoted in Petitioner’s claim construction and cited in support
`
`(“any input that indicates that the user is not to be distracted may be used to
`
`place the device into inactive mode”) does not describe inactive mode, but
`
`rather describes the input that triggers the initiation of inactive mode.
`
`Ex. 1001, 2:28–45 (emphasis added). Petitioner additionally cites five
`
`portions of the ’853 patent Specification that describe inactive mode, four of
`
`which discuss suppressing notification of incoming communications. Pet.
`
`18 (citing Ex. 1001, 1:66–2:3 (“[a] user may enable an inactive mode of the
`
`device to suppress notification of incoming [communications]”), 2:19–3:5
`
`(“suppressing notification of the user of the one or more incoming
`
`communications”), 6:57–60 (“[a] user . . . may enable an inactive mode of
`
`the device . . . to suppress notification of incoming [communications]”),
`
`7:37–46 (after a device is placed in inactive mode “suppressing notification
`
`of the user . . . of the one or more incoming communications”). The fifth
`
`cited portion is directed to different situations in which the device may exit
`
`the inactive mode. Id. (citing Ex. 1001, 3:33–47). This fifth portion is
`
`followed immediately by a description relating that, when inactive mode is
`
`completed, notifications of communications previously suppressed are
`
`provided to the user. Ex. 1001, 3:48–52.
`
`After reviewing the words of the claim in view of the Specification of
`
`the ’853 patent, including specifically the citations provided in the Petition
`
`and discussed above, we find that the correct construction of “inactive
`
`mode” at least encompasses a mode in which user notifications relating to
`
`incoming communications are suppressed. We determine this term does not
`
`otherwise require construction for the purposes of this decision.
`
`9
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`2. Additional terms
`
`We determine at this time that no other terms require construction in
`
`order to complete our analysis.
`
`C. Overview of the Prior Art
`
`1. Riemer
`
`Riemer describes a portable device that includes a safety feature
`
`preventing some forms of use of the device when the device is moving.
`
`Ex. 1007, (57). “The device may be a cell phone configured to disable
`
`transmission and reception of voice/text, conceal its display screen, and
`
`disable incorporated features and functions, if the cell phone is moving
`
`faster than walking speed or the movement is uncharacteristic of walking.”
`
`Id. Riemer describes a device entering “safe mode,” in which the behavior
`
`of a portable electronic device is modified and certain functionality disabled,
`
`when the device is traveling at driving speed or when user defined safety
`
`thresholds are met. Id. ¶ 28.
`
`For example, when a user is driving and an incoming communication
`
`such as a call or text is received, any visual or audio alerts may be
`
`suppressed until the user has stopped driving. Id. ¶ 32. To determine that a
`
`user of a device is in a motor vehicle that is being driven, information
`
`including GPS system information, cell site information, handset and/or
`
`network based information, or vehicle equipment may be used. Id. ¶¶ 36,
`
`87–89. “Other location based detection services can be used to determine
`
`when the user is in a motor vehicle, including connection with a cradle or
`
`charger, connection with a BLUETOOTH system in a motor vehicle,
`
`connection with a personal navigation device, activation of some other type
`
`10
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`of key or token mechanism associated with the vehicle, or the like.” Id.
`
`¶ 36.
`
`In one embodiment, a preferences panel can be used to modify the
`
`functions of safe mode. Id. ¶¶ 131–132, Figs. 5–6. Auto-reply options
`
`allow the user to auto-reply to incoming calls and text messages, including
`
`customizing content in the auto-reply messages. Id. ¶ 131. “The user can
`
`also specify whether the portable electronic device should engage in safe
`
`mode manually or automatically using speed detection.” Id. ¶ 132.
`
`2. Guba
`
`Guba provides an application enforcing a rules-based policy that
`
`controls the use of functions on a mobile device, including disabling or
`
`interrupting certain functions when the vehicle is in motion above a
`
`threshold speed. Ex. 1008, (57). Functions that may be blocked or
`
`interrupted may include sending or receiving phone calls, sending or
`
`receiving text messages, sending or receiving emails, Internet browsing, or
`
`launching of applications on the device. Id. ¶ 19. A default policy may be
`
`used, or an account administrator may customize a policy. Id. ¶¶ 30, 83–89.
`
`The customization allows, for example, for a modifiable time period for
`
`which a vehicle must be stopped before communications and functionality is
`
`restored, how fast a vehicle must be moving before functionality is
`
`disallowed, and whether certain communications functionality remains
`
`uninterrupted even if the vehicle is moving. Id. ¶ 89.
`
`When installed, an application checks for a connection between the
`
`mobile device and an on-board diagnostic port of the vehicle, and, if the
`
`application detects such a connection, “the application monitors and
`
`enforces communication policy, which may be based on the speed of the
`
`11
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`vehicle, the location of the vehicle, whether the vehicle is ‘on,’ what gear the
`
`vehicle is in, what day of the week, what time of the day, and the like.” Id.
`
`¶ 119. Based on such data, the policy determines whether to enter “blocking
`
`mode” (in which communications notifications may be suppressed) or,
`
`alternatively, to remain in “non-blocking mode.” Id. ¶¶ 19, 97, 117, 121,
`
`124.
`
`D. Alleged Unpatentability of Claim 1 over Riemer and Guba
`
`1. Combination of Riemer and Guba
`
`Petitioner argues that claim 1 is unpatentable as obvious over a
`
`combination of Riemer and Guba. Pet. 18–39. Petitioner also argues that
`
`one of ordinary skill in the art would have had motivation and a reasonable
`
`expectation of success in the combination. Id. at 18–20.
`
`Petitioner discusses certain limitations of claim 1, in an attempt to
`
`show how Riemer, Guba, or their combination would have taught or
`
`suggested each limitation. We address these limitations here in order,
`
`excepting limitations [e] and [*] of claim 1, which we address last.
`
`2. Claim 1 –limitations [a], [b], and [c] – “[a] A mobile
`device, comprising: a wireless communication module, [b] a
`processor, controlling the wireless communication module;
`and [c] a memory controlled by the processor, the memory
`including instructions that when executed by the processor
`cause the processor to perform the steps of:”
`
`Petitioner describes Riemer’s disclosures of a portable electronic
`
`device, which is in one embodiment a cell phone, processing performed
`
`within the device, and programming of the device for disabling
`
`communications functionality and argues that these render obvious elements
`
`[a], [b], and [c] of claim 1 as obvious. Pet. 20–26 (citing Ex. 1007 ¶¶ 32, 39,
`
`58, 62, 167, 173; Ex. 1005 ¶¶ 110–116, 121–123).
`
`12
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`Additionally, Petitioner argues, with respect to limitations [b] and [c]
`
`that Guba also teaches or suggests a processor and associated memory as in
`
`those limitations. Pet. 23–24, 26 (citing Ex. 1008 ¶ 36; Ex. 1005 ¶¶ 117–
`
`120, 124–126).
`
`3. Claim 1 – limitations [d] and [f] – “the memory including
`instructions that when executed by the processor cause the
`processor to perform the steps of:” “[d] providing a
`graphical user interface through which a user customizes
`one or more functions of the mobile device when placed in
`an inactive mode” and “[f] receiving a user selection of an
`away message to use when the mobile device is in inactive
`mode”
`
`For element [d] of claim 1, Petitioner argues that Riemer’s graphical
`
`user interface allowing users to customize the functions of the mobile device
`
`when it is placed in safe driving mode teaches or suggests the claimed
`
`“providing a graphical user interface.” Pet. 27–30 (citing Ex. 1007 ¶¶ 131–
`
`132, Figs. 5, 6; Ex. 1005 ¶¶ 127–131). Petitioner, referencing its claim
`
`construction for “inactive mode,” argues that Riemer’s safe driving mode is
`
`an inactive mode because it “indicates that a user is not to be distracted.” Id.
`
`at 27 (citing Ex. 1005 ¶ 127). While we have not adopted Petitioner’s
`
`proposal for claim construction, we determine that Riemer’s safe driving
`
`mode is an inactive mode, as Riemer teaches that in the safe driving mode
`
`user notifications relating to incoming communications are suppressed. See
`
`supra § III.B; Ex. 1007 ¶¶ 32, 131; Pet. 63–64; Ex. 1005 ¶¶ 105, 106, 110,
`
`121, 145.
`
`For element [f] of claim 1, user selection of an away message,
`
`Petitioner argues that the element is taught or suggested in the description of
`
`the customization provided by Riemer’s graphical user interface optionally
`
`13
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`“includ[ing] customization of content in auto-reply messages.” Pet. 36–37
`
`(quoting Ex. 1007 ¶ 131; citing Ex. 1005 ¶ 141).
`
`4. Claim 1 – limitation [g] –“the memory including
`instructions that when executed by the processor cause the
`processor to perform the steps of:” “[g] when the mobile
`device is in inactive mode, in response to receiving a
`communication from the wireless communication module,
`transmitting the user selected away message via the wireless
`module and suppressing one or more sound, visual, or
`vibration communication cues that would have accompanied
`the communication had the mobile device not been in
`inactive mode”
`
`Addressing limitation [g], Petitioner cites Riemer’s teachings
`
`regarding transmitting an “auto-reply message” for unanswered calls during
`
`safe driving mode, and silencing announcements of inbound phone calls in
`
`that mode. Pet. 38–39 (citing Ex. 1007 ¶¶ 32, 131–132, Fig. 5; Ex. 1005
`
`¶¶ 127–131).
`
`5. Claim 1 – limitation [e] – “the memory including
`instructions that when executed by the processor cause the
`processor to perform the steps of:” “[e] receiving a user
`selection to automatically initiate the inactive mode in
`response to the pairing of the mobile device with a vehicle”
`
`a. Riemer and limitation [e]
`
`Petitioner argues that Riemer teaches or suggests limitation [e] of
`
`claim 1 in teaching or suggesting “triggers for engaging in safe mode,”
`
`which include location-based triggers, and that one such trigger is the
`
`pairing of a mobile phone to a motor vehicle. Pet. 30–33. Petitioner further
`
`argues that “Riemer discloses that a . . . trigger to automatically activate safe
`
`driving mode can be pairing a cell phone with a vehicle.” Pet. 32 (citing Ex.
`
`1007 ¶¶ 36, 142). However, the cited paragraphs do not contain this
`
`14
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`disclosure. In paragraph 36, Riemer describes detecting that a motor vehicle
`
`is being driven:
`
`For example, an embodiment operates when a motor
`vehicle is being driven. An embodiment detects when the device
`is in a moving vehicle from an initial stopped position, at the
`beginning of a user's journey.
` This detection may be
`accomplished by several means, including by known GPS
`systems, by processing location information from cell site
`information, by a combination of handset and network based
`information, by network based information alone, by vehicle
`equipment, by equipment added on to the vehicle, or even by
`manual entry. Other location based detection services can be
`used to determine when the user is in a motor vehicle, including
`connection with a cradle or charger, connection with a
`BLUETOOTH system in a motor vehicle, connection with a
`personal navigation device, activation of some other type of key
`or token mechanism associated with the vehicle, or the like.
`
`Ex. 1007 ¶ 36.
`
`Paragraph 36 describes an embodiment relating to the use of safe
`
`mode when “when a motor vehicle is being driven,” detecting that “a device
`
`is in a moving vehicle from an initial stopped position,” using various
`
`means, such as by GPS or cell site information. Id. (emphasis added).
`
`Paragraph 36 then describes ways to “determine when a user is in a motor
`
`vehicle,” including through the pairing of the user’s device with a motor
`
`vehicle. Id. (emphasis added). This does not disclose, teach, or suggest that
`
`pairing is a sufficient trigger for safe mode, however, as Petitioner asserts. It
`
`only discloses that pairing can be used as part of a determination that the
`
`user is in a moving vehicle.
`
`Riemer contains several discussions relating to distinguishing between
`
`a device that is moving and a device that is in a motor vehicle that is moving
`
`or that is being driven by the user. See, e.g., id. ¶¶ 9, 12, 77 (“[A] portable
`
`15
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`electronic device . . . may be configured such that the speed detecting and/or
`
`blocking functions may be enabled only when the user is in a car or is
`
`driving a car.”), 80, 104. Riemer describes that a check of the travelling
`
`speed of the device may be needed only when the device is paired, e.g.,
`
`using a hands-free interface with a Bluetooth device. Id. ¶ 92. In light of
`
`these disclosures, paragraph 36 cannot be seen to teach or suggest triggering
`
`the safe mode upon pairing, as Petitioner argues, but rather using pairing to
`
`determine if a user is in a motor vehicle as part of an embodiment that
`
`detects “when a motor vehicle is being driven.” Id. ¶ 36.
`
`Paragraph 142 is similarly unavailing. Riemer discloses an
`
`embodiment in which “a set consisting of one or more thresholds which
`
`trigger . . . safe driving mode . . . may be customized with a safety policy
`
`through a dashboard”2 with triggers associated with certain speeds or based
`
`on the current day and time. Id. ¶ 141. Paragraph 142 describes that “[t]he
`
`dashboard may provide speed, timer, and date controls” in this embodiment.
`
`Read in context, the dashboard allowing a user or an administrator to specify
`
`“various triggers and thresholds for engaging in safe mode” of
`
`paragraph 142 may be read as describing triggers and thresholds beyond
`
`these speed or day/time triggers, but not as teaching or suggesting that “a
`
`trigger to automatically activate safe driving mode can be pairing a cell
`
`phone with a vehicle” as Petitioner asserts.
`
`
`2 Riemer’s “dashboard” is not a vehicle dashboard, but rather the user
`interface – the “device, web or network based application or interface for
`user and administrator control” of safe driving mode policies for a portable
`electronic device. Ex. 1007 ¶ 115.
`
`16
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`b. Guba and limitation [e]
`
`Alternatively, Petitioner argues that Guba teaches or suggests
`
`limitation [e]. Pet. 33–35.
`
`Petitioner argues that “Guba discloses automatically initiating its
`
`communication policy when a legitimate and authorized connection is
`
`detected” – in other words, “in response to the pairing of the mobile device
`
`with a vehicle,” as in limitation [e] of claim 1. Id. at 33 (citing Ex. 1008
`
`¶ 119) (emphasis added). Petitioner further argues that “Guba’s disclosure is
`
`clear that the communication policies, applications, and functions” allow for
`
`customization, including customization of “triggers for automatically
`
`activating safe driving mode.” Id. at 34 (citing Ex. 1008 ¶¶ 30, 116–117).
`
`However, the claim limitation requires automatic initiation not of
`
`“communication policies” but rather of inactive mode. Guba’s initiation of
`
`communication policy does not necessarily entail automatically activating a
`
`safe driving mode. To the contrary, in Guba, the analogue to the ’853
`
`patent’s inactive mode, in which “user notifications relating to incoming
`
`communications are suppressed”,3 is Guba’s blocking mode, in which
`
`certain functionality of the mobile device is interrupted. Ex. 1008 ¶¶ 67,
`
`124; see supra § III.B.1. Blocking mode is not disclosed as automatically
`
`initiated in Guba in response to the pairing of the mobile device with the
`
`vehicle. Ex. 1008 ¶¶ 89, 92. Rather, in Guba, blocking may begin if certain
`
`conditions are met after a communication policy setting such conditions has
`
`
`3 We note that the Guba’s blocking mode would be the correct analogue to
`“inactive mode” even were we to accept Petitioner’s claim construction that
`“inactive mode” is a mode “that indicates that the user is not to be
`distracted.” Pet. 17.
`
`17
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`been initiated, including conditions such as speed over a certain threshold
`
`value. Id. ¶¶ 19, 97, 121, 124, Fig. 5 (element 505, upon initiation,
`
`“blocking mode is set to ‘off’” (id. ¶ 121)); Fig. 8 (element 865, “blocking
`
`mode is implemented for all functions not allowed while the vehicle is in
`
`motion above the threshold value” (id. ¶ 124)). Before such conditions are
`
`met, functionality is not disallowed. Id. ¶¶ 89, 92, 124. While the policies
`
`illustrated in Guba are exemplary, there is no support for Petitioner’s
`
`assertion that Guba teaches or suggests automatically initiating blocking
`
`upon the pairing of a mobile device with a vehicle. See Pet. 34.
`
`Petitioner additionally argues, without citation to any support, that
`
`“[a] [person of ordinary skill in the art at the time of the invention] would
`
`have understood that Guba’s disclosure of enabling a safety policy in
`
`response to connection between the mobile device and the vehicles wireless
`
`OBD interface teaches or suggests the claimed automatic initiation of an
`
`inactive mode in response to pairing of a mobile device with a vehicle.” Id.
`
`Yet, again, “a safety policy” being enabled does not teach or suggest
`
`initiation of an inactive mode, but rather, in Guba, describes or enacts
`
`conditions under which inactive mode would be applied. Petitioner puts
`
`forward insufficient evidence that one of ordinary skill would have found
`
`Guba to teach or suggest that one condition that would cause automatic
`
`initiation of inactive mode would be the pairing of the mobile device with a
`
`vehicle.
`
`c. Limitation [e] - Conclusion
`
`Petitioner argues, based on its assertions regarding the teachings and
`
`suggestions of Riemer and Guba relating to limitation [e], that one of
`
`ordinary skill would have found it obvious to provide an option in a user
`
`18
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`interface to select such a trigger. Pet. 32–36. As detailed above, we do not
`
`see support for Petitioner’s assertions regarding Riemer and Guba’s
`
`teachings or suggestions relating to the automatic initiation of inactive mode
`
`in response to the pairing of a mobile device with a vehicle. Thus, Petitioner
`
`fails to demonstrate a reasonable likelihood that it will prevail in showing
`
`that the combination of Riemer and Guba teaches or suggests this limitation.
`
`6. Claim 1 – limitation [*] – “the memory including
`instructions that when executed by the processor cause the
`processor to perform the steps of:” “[*] in response to the
`pairing of the mobile device and the vehicle, automatically
`initiating a process to place the mobile device in inactive
`mode”
`
`Petitioner entirely fails to address this limitation, other than to assert
`
`that it was one of three bases cited by the Examiner as a point of novelty in
`
`the Notice of Allowability and Examiner’s Amendment for the ’853 patent.
`
`Pet. 5 (citing Ex. 1006, 14–15).
`
`This limitation describes “a process to place the mobile device in
`
`inactive mode” – this “process” is never addressed by Petitioner. Any
`
`distinction between this limitation [*] and limitation [e], or any relationship
`
`this limitation [*] has to limitation [e] is not addressed by Petitioner. To the
`
`extent that Petitioner’s arguments relating to limitation [e] would be relied
`
`on for this limitation, the issues noted above with Petitioner’s arguments are
`
`reiterated.
`
`Therefore, we find Petitioner fails to demonstrate a reasonable
`
`likelihood that it will prevail in showing that the combination of Riemer and
`
`Guba teaches or suggests this limitation.
`
`19
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`7. Conclusion
`
`Accordingly, for the reasons discussed above, Petitioner has failed to
`
`demonstrate a reasonable likelihood of showing claim 1 is unpatentable over
`
`the combination of Riemer and Guba.
`
`E. Alleged Unpatentability of Claims 2–7 over Riemer and Guba
`
`Petitioner’s analysis of dependent claims 2–7 relies on the analysis of
`
`claim 1, from which these claims depend, directly or indirectly. Pet. 39–50.
`
`Accordingly, for the reasons discussed above, Petitioner has failed to
`
`demonstrate a reasonable likelihood that it will prevail in showing claims 2–
`
`7 are unpatentable over Riemer and Guba.
`
`F. Alleged Unpatentability of Claims 1–7 over Guba, Olincy, and
`Chaudhri and Unpatentability of Claim 3 over Guba, Olincy,
`Chaudhri, and Riemer
`
`Petitioner’s analysis of limitation [e] of claim 1 in its ground asserting
`
`that claim 1 is obvious over a combination of Guba, Olincy, and Chaudhri
`
`repeats substantially the same assertions regarding Guba as in the ground
`
`relating to the combination of Reimer and Guba. Compare Pet. 33–34 with
`
`id. at 56–57. Thus, Petitioner fails to demonstrate a reasonable likelihood
`
`that it will prevail in showing that the combination of Guba, Olincy, and
`
`Chaudhri teaches or suggests limitation [e]. See supra § III.D.5.b.
`
`Additionally, Petitioner again fails to address limitation [*] of claim 1 in any
`
`way, and fails to demonstrate a reasonable likelihood that it will prevail in
`
`showing that the combination of Guba, Olincy, and Chaudhri teaches or
`
`suggests limitation [*]. See supra § III.D.6.
`
`Therefore, Petitioner has failed to demonstrate a reasonable likelihood
`
`of showing claim 1 is unpatentable over the combination of Guba, Olincy,
`
`and Chaudhri. Petitioner’s analysis of dependent claims 2–7 relies on the
`
`20
`
`
`
`IPR2019-00434
`Patent 8,958,853 B1
`
`
`analysis of the claim 1, from which these claims depend, directly or
`
`indirectly. Pet. 67–74. Accordingly, for the reasons discussed above,
`
`Petitioner has failed to demonstrate a reasonable likelihood that it will
`
`prevail in showing claim
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
