`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC., SAMSUNG ELECTRONICS CO., LTD.,
`and SAMSUNG ELECTRONICS AMERICA, INC.,
`Petitioner,
`
`
`
`v.
`
`SMART MOBILE TECHNOLOGIES LLC,
`Patent Owner.
`____________
`
`Case IPR2022-00807
`Patent 9,756,168
`____________
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`
`
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`I.
`
`II.
`
`TABLE OF CONTENTS
`
`Page
`INTRODUCTION ........................................................................................ 1
`
`NO REASONABLE LIKELIHOOD IS SHOWN THAT SAINTON
`AND BAKER TEACH THE “SERVER” (ALL
`CLAIMS/GROUNDS). ................................................................................. 3
`
`III. NO REASONABLE LIKELIHOOD IS SHOWN THAT SAINTON
`AND BAKER TEACH THE “USER” “PROFILES” STORED
`IN THE “SERVER” (ALL CLAIMS/GROUNDS). ................................10
`
`A. The Claimed “Profile[s]” Require User Specific Information
`And Being Stored At The Server. ....................................................... 11
`
`1.
`
`2.
`
`Claim 2’s “Profiles” Are Stored At The Remote Server
`And Expressly Are Of User Specific Information. ................... 11
`
`Claim 4’s “Profile” Is Similarly Stored At The Server
`And Includes User Specific Information. ................................. 13
`
`B.
`
`Sainton Teaches Away From Storing User Profiles At The Server
`As Claimed (Claim 2). ........................................................................ 14
`
`C. Baker Fails To Teach The Claimed “Profile(s)” (Claims 2 & 4). ...... 18
`
`IV. NO REASONABLE LIKELIHOOD IS SHOWN THAT SAINTON
`TEACHES “BOTH POWER OUTPUT AND CHANNEL
`BANDWIDTH AS ARE DYNAMICALLY CHANGED IN REAL
`TIME” (ALL CLAIMS/GROUNDS). ......................................................23
`
`A. The Claimed “Power Output And Channel Bandwidth” Are
`“Dynamically Changed” “In Real Time.” ........................................... 25
`
`B.
`
`C.
`
`Sainton’s Power Output Does Not Change “Dynamically.” .............. 29
`
`Sainton Fails To Teach Changing Its Power Output And Channel
`Bandwidth “In Real Time.” ................................................................. 31
`
`V.
`
`CONCLUSION ...........................................................................................33
`
`i
`
`
`
`TABLE OF AUTHORITIES
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`Page(s)
`
`COURT DECISIONS
`
`AstraZeneca AB v. Mylan Pharm. Inc.,
`19 F.4th 1325 (Fed. Cir. 2021) ...........................................................................13
`
`In re Magnum Oil Tools Int’l, Ltd.,
`829 F.3d 1364 (Fed. Cir. 2016) ..........................................................................23
`
`Profectus Tech. LLC v. Huawei Techs. Co.,
`823 F.3d 1375 (Fed. Cir. 2016) ..........................................................................13
`
`Renishaw PLC v. Marposs Societa’ Per Azioni,
`158 F.3d 1243 (Fed. Cir. 1998) ..........................................................................13
`
`Vitronics Corp. v. Conceptronic Inc.,
`90 F.3d 1576 (Fed. Cir. 1996) ............................................................................13
`
`
`
`STATUTES
`
`35 U.S.C. § 314(a) ..................................................................................................... 9
`
`35 U.S.C. § 316(e) ...................................................................................................23
`
`
`
`
`
`
`
`
`
`
`
`ii
`
`
`
`
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`EXHIBIT LIST
`
`2001
`
`2002
`
`2003
`
`2004
`
`2005
`
`Techopedia – Jini (available at
`https://www.techopedia.com/definition/1304/jini) [Techopedia Jini]
`
`Excerpts from The JiniTM Specification, Ken Arnold et al., [Jini
`Specification]
`
`Excerpts from A Collection of JiniTM Technology Helper Utilities
`and Services Specifications, Sun Microsystems, Inc. (2000) [A
`Collection of JINI Specifications]
`
`Excerpts from Microsoft Computer Dictionary, Fifth Edition (2002)
`[Microsoft Computer Dictionary]
`
`Excerpts from Newton’s Telecom Dictionary, 16th Edition (2000)
`[Newton’s Telecom Dictionary]
`
`iii
`
`
`
`I.
`
`INTRODUCTION
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`The Petition raises six grounds, each of which requires combining at least
`
`Sainton, Baker, and Mueller.1 The Petition requests cancellation of independent
`
`claim 2 and its dependents 3, 5, 19-23, and 25, and independent claim 4 and its
`
`dependents 28, 29, 32, and 34. The Petition should be denied because it fails, for
`
`at least the reasons below, to show a sufficient likelihood that Petitioner will
`
`prevail as to any claim.
`
`First, each challenged claim requires a “server” (in claim 2 and its
`
`dependents, “remote server”) configured to store software and applications for
`
`wireless devices. Petitioner argues that this limitation is rendered obvious by
`
`Sainton and Baker in combination because Baker’s lookup service 136 supposedly
`
`discloses the claimed “server.” However, Petitioner fails to show that Baker’s
`
`lookup service 136 is a “server” as claimed. In fact, the POSITA would
`
`understand that Baker’s technology expressly distinguishes its lookup service 136
`
`from a “server,” a fact that the Petition entirely fails to address. See Section II.
`
`Second, each challenged claim requires storing user “profile[s]” at the
`
`“server.” Petitioner argues that the “profile[s]” limitation is rendered obvious by
`
`1 Grounds 2-5 each require adding a fourth reference (Humpleman, Grube,
`
`Hsu, Camp, or Petty). These additional references are irrelevant to this Response.
`
`1
`
`
`
`Sainton, alone or in combination with Baker, because the person of ordinary skill
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`in this art at the time of the invention (“POSITA”) would supposedly have found it
`
`obvious based on Sainton’s teachings to modify this art so that it stored such
`
`“profiles” at a server, and Baker’s “register[ing]” “the requestor module…as a
`
`user” is equivalent to storing the profiles at a server. However, Sainton in fact
`
`teaches away from storing such “profiles” at a server, and Baker’s registration
`
`process does not create and store “profiles.” It is thus not shown that the POSITA
`
`would have been motivated, based on Sainton’s and Baker’s teachings, to modify
`
`the art to meet the limitation of storing such “profiles” at such a server as in the
`
`claimed invention. See Section III.
`
`Finally, each challenged claim requires “both power output and channel
`
`bandwidth as are dynamically changed in real time.” This requires the wireless
`
`device to, in response to the changes in the environment, adjust its power output
`
`and channel bandwidth, without the need for user intervention. Petitioner contends
`
`that this limitation is rendered obvious by Sainton-Mueller because, allegedly,
`
`Sainton discloses using “control signals” to change the power output for
`
`transmission based on network environment selected, and Mueller demonstrates
`
`the general knowledge that many different carrier network types have different
`
`channel bandwidths. However, Petitioner fails to show that, under Sainton’s
`
`teachings, Sainton’s “control signals” are generated in response to the changes in
`
`2
`
`
`
`the environment, or that Sainton’s wireless device can adjust in real time its power
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`output and channel bandwidth without the need for user intervention. See Section
`
`IV.
`
`For at least these reasons, institution of review should be denied.
`
`II. NO REASONABLE LIKELIHOOD IS SHOWN THAT SAINTON
`AND BAKER TEACH THE “SERVER” (ALL CLAIMS/GROUNDS).
`
`Claim 2 requires “a remote server configured to store wireless device
`
`software for a plurality of different functions or applications for use by a plurality
`
`of wireless devices.” Similarly, Claim 4 requires “a server…configured to store
`
`software for a plurality of wireless devices and for a plurality of applications for
`
`the plurality of wireless devices.” Ex. 1001 [’168] cls. 2, 4 (emphases added).
`
`Petitioner argues that “Sainton combined with Baker” renders obvious these
`
`“server” limitations. Pet., 27-29 (claim 2 and dependents), 51-53 (same) (claim 4
`
`and dependents). Petitioner first argues that “Sainton contemplates updating the
`
`wireless device’s library over-the-air via a carrier….” Id., 28. Petitioner does not
`
`argue that Sainton expressly teaches the “server” claimed. Instead, Petitioner relies
`
`only upon Baker for the “server” limitations, arguing that “Baker’s ‘lookup
`
`service 136” “is a source of service objects for Sainton’s library updates for added
`
`functions” and allegedly “‘may reside on a separate device’ from the requesting
`
`device (i.e., Sainton’s wireless device), and is therefore ‘remote’” as certain of the
`
`3
`
`
`
`claims require. Id. (first emphasis in original, second emphasis added). However,
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`Petitioner fails to demonstrate that the POSITA would consider Baker’s lookup
`
`service 136 to be a “server” as claimed. Petitioner fails to address the fact that
`
`Baker’s disclosures using lookup service 136 are directed toward a “Jini” system,
`
`and that technology distinguishes lookup service 136 from a server.
`
`Petitioner’s argument that “Baker’s ‘lookup service 136’ is a ‘network
`
`server’” points to column 7, lines 37-38 of Baker for support. Pet., 26. The
`
`following figure demonstrates how Petitioner construes Baker:
`
`Pet., 27 (Petitioner’s annotations). However, a closer examination of Baker reveals
`
`that there is no showing that the POSITA would consider Baker’s lookup service
`
`136 as a “server” as recited in the claims.
`
`
`
`4
`
`
`
`Baker expressly teaches that the network system it discloses is a Jini
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`network system. Ex. 1006 [Baker] 7:43-46. Based on this disclosure in Baker, the
`
`POSITA would understand that the architecture of Baker’s network system is
`
`divided into three main parts: Client, Server, and Lookup Service. Ex. 2001
`
`[Techopedia Jini]. Thus, Jini distinguishes its “Server” from its “Lookup Service.”
`
`Yet it is the Jini lookup service in Baker that the Petition purports to read on the
`
`“server” in the claims.
`
`A Jini system like the one in Baker would have been built around the
`
`Lookup Service, which is where services advertise their availability so that a client
`
`may find them. Ex. 2002 [Jini Specification] 5.
`
`Each Jini system is built around one or more lookup services. The
`lookup service is where services advertise their availability so that you
`can find them. There may be one or more lookup services running in
`a network.
`
`When a service is booted on the network, it uses a process called
`discovery to find the local lookup services. The service then registers
`its proxy object with each lookup service. The proxy object is a Java
`object, and
`its
`types—the
`interfaces
`it
`implements and
`its
`superclasses—define the service it is providing. For example, a proxy
`object for a printer will implement a Printer interface. If the printer is
`also capable of receiving faxes, the proxy object will also implement
`the FaxReceiver interface.
`
`5
`
`
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`
`
`A client program asks for services by the Java language type the client
`will use. A client wanting a printer will ask the lookup service for a
`service that implements the Printer interface. When the lookup
`service returns the printer’s proxy object, the client will automatically
`download the code for that object if it doesn’t have it already.
`
`
`
`The client issues printer requests by invoking methods on the proxy
`object. The proxy communicates with the printer as it needs to in
`order to execute the requests. The Jini system does not define what
`the protocol between the proxy and its service should be; that is
`defined by the printer and its proxy object.
`
`6
`
`
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`
`
`Id., 5-6. According to the above description, the lookup service of a Jini system
`
`does not provide a service to a requesting client; rather, it merely allows the
`
`requesting client to download a proxy object, which enables the requesting client to
`
`communicate with the service providing device (i.e., the Jini system’s server). See
`
`also Ex. 2003 [A Collection of Jini Specifications] 10-11 (describing how the
`
`client may request the invocation of the methods provided by the server (remote
`
`server/remote object) via a proxy).
`
`Similar description of the architecture of a Jini system is found in
`
`Techopedia, which describes the Lookup Service of a Jini network system as
`
`follows: “Lookup Service: Services for resources such as printers, storage devices
`
`and speakers, which are attached to the server and made available to clients over
`
`the network”. Ex. 2001 [Techopedia Jini] (emphasis added). Techopedia provides
`
`a separate description for “server,” describing it as “Server: The system to which
`
`the resources are attached.” Id.
`
`Thus, the “Server” and the “Lookup Service” of the Jini network system are
`
`expressly two separate major parts of the system. There is no evidence that the
`
`7
`
`
`
`POSITA, knowing that Baker’s network system is a Jini system, would understand
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`that the “Lookup Service” is the server in Baker: instead, the fact that Baker is Jini
`
`technology indicates that the POSITA would understand that the lookup service in
`
`Baker is a different and separate part of the Jini network system from the server or
`
`servers in the system. Such understanding would follow from the description of
`
`the Jini “Lookup Service” above, which is described as being “attached” to the Jini
`
`system’s server. The word “attached” further emphasizes the separate nature of the
`
`“Lookup Service” and the “Server”—if the “Lookup Service” is the “Server,” there
`
`would be no need for the Jini network system to “attach” the “Lookup Service” to
`
`the “Server.” Ex. 2001 [Techopedia Jini].
`
`Although the Petition does not even attempt to address Baker’s description
`
`of its system as Jini technology, let alone explain how that description can be
`
`reconciled with deeming Baker’s Jini lookup device to be its server, inspection of
`
`Baker’s descriptions of its system confirm that no reason is shown for the POSITA
`
`to disregard Baker’s description of its system as being a Jini system and deem its
`
`lookup service 136 to be the “server.” Petitioner cites Baker at 7:37-38 as
`
`allegedly supporting its assertion that “Baker’s ‘lookup service 136’ is a ‘network
`
`server.’” Pet., 26. Baker states that “[t]he lookup service 136 may reside on a
`
`separate device such as a network server.” Ex. 1006 [Baker] 7:37-38 (emphasis
`
`added). However, the word “reside” does not indicate that Baker’s “lookup service
`
`8
`
`
`
`136” is the same as Baker’s “network server.” Rather, this is consistent with
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`Techopedia’s description, Ex. 2001 [Techopedia Jini], of Jini’s lookup service
`
`being “attached” to Jini’s server. There is no need for the “lookup service 136” to
`
`“reside” on the “network server” if the lookup service 136 is the network server. If
`
`Baker taught that the lookup service 136 was the network server, it would have
`
`used words indicating, for example, that the lookup service 136 was the network
`
`server.
`
`Petitioner had the burden to show in the Petition that the proposed
`
`combination teaches every limitation of the claims. The Petition’s assertion that
`
`Baker’s “lookup service 136” is the claimed “server,” however, does not match
`
`Baker’s description of its system as a Jini system, in which the lookup service and
`
`server are separate and distinct, and the Petition offers no argument or evidence
`
`that the POSITA would, despite that mismatch, disregard Jini’s separation of the
`
`“lookup service” and the “server” and find Baker’s lookup service 136 to be the
`
`claimed “server.” Rather, contrary to Petitioner’s assertion, the POSITA would
`
`understand that Baker’s lookup service 136 is not the server. Therefore, the
`
`proposed grounds do not meet the threshold for institution of review under 35
`
`U.S.C. § 314(a).
`
`9
`
`
`
`III. NO REASONABLE LIKELIHOOD IS SHOWN THAT SAINTON
`AND BAKER TEACH THE “USER” “PROFILES” STORED IN THE
`“SERVER” (ALL CLAIMS/GROUNDS).
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`Even assuming arguendo that the “server” limitation is met, the Petition’s
`
`grounds fail to show a threshold likelihood that the POSITA would have found
`
`obvious from the cited teachings in Sainton and Baker the recited user “profiles”
`
`stored in the server.
`
`Claim 2 recites “the remote server stores profiles of user specific
`
`information.” In a similar fashion, claim 4 recites “the software is associated with
`
`a user and the device stored in a profile, wherein the server is configured to store
`
`software….” Ex. 1001 [’168] cls. 2, 4. As further explained below, the “profile[s]”
`
`as recited in claims 2 and 4 require user specific information—which could be, for
`
`example, user name, password, browsing history, etc.—to be stored at the server.
`
`See Section III.A.
`
`Petitioner argues that the claimed user “profile(s)” are rendered obvious by
`
`Sainton and/or Sainton-Baker. First, Petitioner argues that it would have been
`
`obvious in view of the combination to add the storage of Sainton’s “[user]
`
`profiles…at a remote server,” as it allegedly “allows different carriers to access
`
`user criteria to estimate potential demand, and thus enable carriers to incentivize or
`
`disincentivize customers to achieve a desired load in their own networks.” Pet.,
`
`30-31. Petitioner also argues that Sainton-Baker renders obvious storing user
`
`10
`
`
`
`“profile(s).” Petitioner reasons that “[b]ecause [Baker’s] requestor module is
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`registered as a user of the service object, it would have been obvious that the server
`
`maintains a profile for the user (requestor module) of the service object.” Pet., 31-
`
`32; see also Pet., 52. Petitioner fails to substantiate these arguments.
`
`First, contrary to Petitioner’s assertion, the record shows that Sainton
`
`teaches away from storing user profiles at a server as claimed, so the POSITA
`
`would not be motivated by Sainton, alone or in combination, to do so. See Section
`
`III.B. Second, the record further shows that a user profile is not created when
`
`Baker’s requestor module is registered as a user of the service object. Accordingly,
`
`Baker also fails to teach storing user profiles at the claimed server. See Section
`
`III.C. Thus, neither Sainton nor Baker, alone or in combination, is shown to teach
`
`or render obvious the user “profile” limitations recited in claims 2 and 4.
`
`A. The Claimed “Profile[s]” Require User Specific Information And
`Being Stored At The Server.
`
`The user “profile” limitations require user specific information and being
`
`stored at the server.
`
`1.
`
`Claim 2’s “Profiles” Are Stored At The Remote Server And
`Expressly Are Of User Specific Information.
`
`Claim 2 expressly recites that “the remote server stores profiles of user
`
`specific information.” Ex. 1001 [’168] cl. 2. It thus expressly requires the
`
`“profiles” of claim 2 to be stored at the remote server, and that the “profiles” are of
`
`11
`
`
`
`user specific information. The statement is consistent with the description of the
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`specification, which states that “[a] CT/MD 202 can store profiles and other user
`
`specific information on the Server C 214.” Ex. 1001 [’168] 3:57-58; id., 7:33-34
`
`(similar). By using the term “and other,” the specification confirms that the
`
`“profiles,” too, include user specific information.
`
`The above is also consistent with the plain meaning of “profile” within the
`
`context of information technology. For example, one dictionary defines “(user)
`
`profile” as “contain[ing] such information as the person’s access restrictions,
`
`mailbox location, type of terminal, and so on.” Ex. 2004 [Microsoft Computer
`
`Dictionary] 544, 424. Petitioner appears to acknowledge, and does not appear to
`
`dispute, that “profile(s)” includes user specific information, as it states in the
`
`Petition that “Sainton discloses storing specific criteria for a particular user in a
`
`user profile.” Pet., 30.
`
`Thus, the POSITA would understand that the “profiles” of claim 2 contain
`
`user specific information (which could be, for example, the person’s access
`
`restrictions, mailbox location, and type of terminal) and be stored at the remote
`
`server.
`
`12
`
`
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`Claim 4’s “Profile” Is Similarly Stored At The Server And
`Includes User Specific Information.
`
`2.
`
`Claim 4 recites that “the software is associated with a user and the device
`
`stored in a profile, wherein the server is configured to store software….” Ex. 1001
`
`[’168] cl. 4.
`
`The specification describes the user “profile,” as discussed in Section III.A.1,
`
`as including user specific information. That is confirmed by the recited language
`
`that “the software is associated with a user and the device stored in a profile.”
`
`Furthermore, the POSITA would understand that claim 4 requires its “profile” be
`
`stored at the server, as it expressly requires that its “server is configured to store”
`
`software, and that “the software is associated with a user and the device stored in a
`
`profile.”
`
`It is noted that the meaning given to a claim term must be consistent with the
`
`use of the claim term in the specification and drawings. See, e.g., Vitronics Corp. v.
`
`Conceptronic Inc., 90 F.3d 1576, 1582-83 (Fed. Cir. 1996); Renishaw PLC v.
`
`Marposs Societa’ Per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998); AstraZeneca
`
`AB v. Mylan Pharm. Inc., 19 F.4th 1325, 1329 (Fed. Cir. 2021); Profectus Tech.
`
`LLC v. Huawei Techs. Co., 823 F.3d 1375, 1380-81 (Fed. Cir. 2016). Here,
`
`the ’168’s specification states that “[a] CT/MD 202 can store profiles and other
`
`user specific information on the Server C 214.” Ex. 1001 [’168] 3:57-58; id., 7:33-
`
`13
`
`
`
`34 (similar). As exemplified by the above description, in the described
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`embodiments the “profile” is stored at the server. Consistent with the description
`
`of the specification, the “profile” of claim 4 should be interpreted as being stored at
`
`the server.
`
`Petitioner appears to acknowledge such interpretation. The Petition states
`
`that Sainton-Baker renders obvious the limitation “wherein the software is
`
`associated with a user and the device stored in a profile” as “it was generally
`
`obvious to maintain profiles for multiple users at a remote server for centrally
`
`managing content distribution.” Pet., 52.
`
`Accordingly, it is undisputed that the POSITA would understand claim 4’s
`
`“profile” as containing user specific information and being stored at the server.
`
`B.
`
`Sainton Teaches Away From Storing User Profiles At The Server
`As Claimed (Claim 2).
`
`Petitioner argues that “it would have been obvious to store multiple
`
`[Sainton’s] profiles for multiple devices at a remote server,” because “[d]oing so
`
`helps achieve Sainton’s stated goal of changing pricing dynamically ‘to maintain a
`
`desired system load level,’” and that “centralizing multiple user profiles allows
`
`different carriers to access user criteria to estimate potential demand,” thus
`
`“enable[ing] carriers to incentivize or disincentivize customers to achieve a desired
`
`14
`
`
`
`load in their own networks.” Pet., 30-31 (citing Ex. 1020 [Schlang], Ex. 1031
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`[Obhan]).
`
`Sainton is concerned with switching between different wireless
`
`communication networks “based on a user determined criteria.” Ex. 1005 [Sainton]
`
`2:40-52; see also id., Abstract, 16:32-43. The criteria “are stored in a user profile
`
`in the memory of circuit 1.” Id., 17:51-53. As acknowledged by Petitioner,
`
`Sainton stores its profile at (the circuit 1 of) the wireless device. Furthermore, it is
`
`clear that Sainton intends its criteria be stored at the circuit 1 of the wireless device,
`
`rather than at a separate server. Sainton’s goal is to assist the wireless device in
`
`selecting a preferred wireless network service. Id., 2:26-32 (“no one has yet
`
`disclosed a truly self adaptive, omni-modal wireless product which enables an end
`
`user to access conveniently various wireless services in accordance with a
`
`selection process which is sufficiently under the control of the end user”); 2:35-38
`
`(“A fundamental objective of the subject invention is to … provid[e] a truly omni-
`
`modal wireless product and method which is adaptive to the selectively variable
`
`desires of the end user.”). To achieve this goal, Sainton’s user profile must be
`
`stored at the wireless device so that the wireless device may apply the user
`
`determined criteria when selecting a preferred wireless network service. If the user
`
`profile/user determined criteria is stored at a server rather than at the wireless
`
`device, the wireless device will not be able to access and apply the user profile/user
`
`15
`
`
`
`determined criteria during the selection process (before it is connected to the
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`internet through the wireless service). It would, therefore, make no obvious sense
`
`to the POSITA to store Sainton’s user profile/user determined criteria at the server.
`
`Petitioner cites Schlang and Obhan to support its contention that it is
`
`obvious to store Sainton’s user profile at the claimed server. However, Petitioner
`
`does not identify from either Schlang or Obhan motivation for the POSITA to store
`
`Sainton’s profile(s) at the claimed server. First, Schlang contains only one
`
`sentence describing that “The [mobile telephone switching office (MTSO)] 20
`
`switches calls between wireline and mobile subscribers, controls signaling to the
`
`mobile stations M1-M5, compiles billing statistics, stores subscriber service
`
`profiles, and provides for the operation, maintenance and testing of the system.”
`
`Ex. 1020 [Schlang] 1:64-2:2. Schlang, however, does not explain what kind of
`
`benefit could be obtained if its “subscriber service profiles” are stored at its MTSO
`
`20 (the alleged [remote] server). Considering that Sainton’s architecture requires
`
`the “user profiles” be stored at the wireless device, and Schlang’s lack of
`
`disclosure regarding the possible benefits of storing its “subscriber service profiles”
`
`at its MTSO 20, the POSITA would not view storing Sainton’s “user profiles” at
`
`the claimed server to be obvious.
`
`Petitioner argues that storing Sainton’s “user profiles” at a server as claimed
`
`“helps achieve Sainton’s stated goal of changing pricing dynamically ‘to maintain
`
`16
`
`
`
`Case IPR2022-00807
`Patent 9,756,168
`
`a desired system load level.’” Pet., 30-31. However, Sainton’s disclosure does not
`
`support this assertion. Specifically, Sainton discloses:
`
`Alternatively, individual carriers may broadcast pricing information
`on individual command channels. Pricing can be changed on a
`dynamic basis to maintain a desired system load level. In fact, in one
`preferred embodiment, an automated price negotiation can be
`performed in which the circuit 1 transmits an indication of the type
`and amount of information which is to be transmitted, and the
`carrier responds by quoting a price for the transmission. … As part
`of this scheme, radio carriers may implement a dynamic demand
`curve evaluation program in which system load and profitability are
`constantly monitored. The evaluation program may also monitor the
`percentage of requested quotes which are not accepted. In this way,
`the radio carrier’s system can dynamically adjust prices to maximize
`revenue to the carrier at all times, based on a real-time model of the
`current demand curve for airtime service in the area.
`
`Ex. 1005 [Sainton] 19:45-64 (emphases added). According to the description
`
`above, the pricing changes are triggered by an “automated price negotiation,” in
`
`which the circuit 1 of the wireless device first transmits an indication of the type
`
`and amount of information which is to be transmitted, and then the carrier responds
`
`by quoting a price for the transmission. Whether or not the user profiles are stored
`
`at the server (or remote server) does not affect this load-adjustment mechanism,
`
`because the entire process starts after the wireless device informs the carrier(s) of
`
`17
`
`
`
`the type and amount of information which is to be transmitted. Furthermore, the
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`carrier(s) also does not apply the user profiles (or user defined criteria) to
`
`determine the price offered to the user. Thus, the POSITA would not be motivated
`
`by this art to store Sainton’s user profiles at the claimed server, because doing so
`
`would not help in “maintain[ing] a desired system load level.”
`
`Petitioner cites Obhan to support its contention, but Obhan does not cure the
`
`flaw of Petitioner’s argument. In particular, the “potential demand data” relied
`
`upon by Petitioner has nothing to do with Sainton’s “automated price negotiation”
`
`mechanism. See Ex. 1031 [Obhan] 4:63-5:5 (“The current demand data 118 and
`
`potential demand data 120 indicate the current subscriber loading and the potential
`
`subscriber loading”), 5:55-65. Thus, it is not shown that the POSITA would
`
`recognize any benefit in storing the user profiles at the server as claimed, as it
`
`would not help in “maintain[ing] a desired system load level” under Sainton’s
`
`“automated price negotiation” mechanism.
`
`Accordingly, Sainton does not render obvious that the claimed server “stores
`
`profiles of user specific information.”
`
`C. Baker Fails To Teach The Claimed “Profile[s]” (Claims 2 & 4).
`
`Petitioner further argues that Sainton-Baker renders obvious storing
`
`“profiles” as claimed. Specifically, Petitioner argues that in Baker’s system, “the
`
`requestor is registered as a user of the matched module” “to keep track of service
`
`18
`
`
`
`module users.” Pet., 31. According to Petitioner, “[b]ecause [Baker’s] requestor
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`module is registered as a user of the service object, it would have been obvious that
`
`the [remote] server maintains a profile for the user (requestor module) of the
`
`service object.” Id. Furthermore, the Petition contends that it was well-known for
`
`a remote server to store profiles to track distributable content. Id. Thus, the
`
`Petition insists, the limitation of storing profiles at the remote server (without
`
`distinguishing between the server of claim 2 or claim 4) was rendered obvious by
`
`“Baker’s teachings of storing profiles of users (e.g., requestor modules) of service
`
`objects.” Id., 32.
`
`Petitioner’s argument, however, fails to appreciate or address the fact that
`
`Baker’s lookup service 136 (the alleged server) does not store a user profile when
`
`“the requestor is registered as a user of the matched module.” A “profile” or “user
`
`profile,” as understood by the POSITA, contains user specific information such as
`
`the person’s access restrictions, mailbox location, type of terminal, and so on. See
`
`Section III.A.
`
`Baker, however, only describes the registration of the requestor module in
`
`one sentence, stating that “[i]n step 314 the requestor is registered as a user of the
`
`matched module….” Ex. 1006 [Baker] 14:14-16. Among other problems with this
`
`theory, the other portions of Baker discussing registration are directed towards the
`
`registration of the service provider, not the requestor. Compare id., 14:12-19, with
`
`19
`
`
`
`id., 7:58-8:7. Thus, Baker simply fails to disclose creating and storing a “(user)
`
`Case IPR2022-00807
`Patent 9,756,168
`
`
`profile” when “the requestor is registered as a user.” Baker’s requestor module is a
`
`device. See, e.g., id., Fig. 12 (“Register requestor module as a module user”). The
`
`“user” of the claims, in contrast, is a natural person.
`
`The POSITA would not equate a human user and a non-human device. For
`
`example, the ’168 Patent recites in its Background Of The Invention section that
`
`“[t]here is often a proliferation of mobile devices that must be carried by a user.
`
`For example, a user may need a device or remote for the public airwaves (cell
`
`phone), another for the local or office network and yet another for the
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
