Docket No.: 2210287-00131
UNITED STATES PATENT AND TRADEMARK OFFICE
PATENT: 8,719,617
INVENTORS: JIONGJIONG GU, FENG LIANG, LINFEI SHEN, SHUFENG SHI, KAI WEN
FILED: October 31, 2011
ISSUED: May 6, 2014
TITLE: METHOD AND DEVICE FOR REALIZING IP MULTIMEDIA SUBSYSTEM DISASTER TOLERANCE
___________________________________________
BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________________________________________
T-Mobile US, Inc. and T-Mobile USA, Inc.
Petitioners
v.
Huawei Technologies Co. Ltd. Patent Owner
Case IPR2017-00697
PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 8,719,617
UNDER 35 U.S.C. § 312 AND 37 C.F.R. § 42.104
U.S. Patent 8,719,617 Petition for Inter Partes Review
i
TABLE OF CONTENTS
I. INTRODUCTION ........................................................................................... 1
II. MANDATORY NOTICES ............................................................................. 1
A. Real Parties-in-Interest .......................................................................... 1
B. Related Matters ...................................................................................... 1
C. Counsel .................................................................................................. 1
D. Service Information ............................................................................... 2
III. CERTIFICATION OF GROUNDS FOR STANDING .................................. 2
IV. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED .................... 2
A. Prior Art Patents and Printed Publications ............................................ 2
B. Level of Ordinary Skill in the Art ......................................................... 3
C. Relief Requested .................................................................................... 4
V. OVERVIEW OF THE ’617 PATENT ............................................................ 4
A. Background IMS Technology ............................................................... 4
1. IMS Core Components ............................................................... 6
2. IMS Information Flows ............................................................... 7
B. Purported Problem and Solution of the ’617 Patent ........................... 12
C. Summary of the Prosecution History .................................................. 17
VI. CLAIM CONSTRUCTION .......................................................................... 19
A. “restoration data” / “restoring data” .................................................... 19
VII. GROUNDS FOR CHALLENGE .................................................................. 21
A. Overview of Prior Art ......................................................................... 23
B. Ground 1: Claims 1, 5, and 7 Are Invalid As Obvious Over the Combination of Phan-Anh and S2-060216 ......................................... 27
1. Overview of Phan-Anh ............................................................. 28
2. Overview of S2-060216 ............................................................ 33
3. The 3GPP Documents Qualify As Prior Art to the ’617 Patent ................................................................................................... 36
4. Claim 1 ...................................................................................... 40
U.S. Patent 8,719,617 Petition for Inter Partes Review
ii
5. Claim 5 ...................................................................................... 51
6. Claim 7 ...................................................................................... 56
7. Reasons to Combine Phan-Anh and S2-060216 ....................... 58
C. Ground 2: Claims 1, 4, 5, 7, and 10 Are Invalid As Obvious Over Phan-Anh Combination With S2-060216 and TS 23.228................... 60
1. Claims 1, 5, and 7...................................................................... 61
2. Claims 4 and 10 ......................................................................... 62
D. Ground 3: Claims 1, 4, 5, 7, and 10 Are Invalid As Obvious Over Phan-Anh In View of TR 23.821, S2-060216 and TS 23.228 ............ 62
VIII. CONCLUSION ............................................................................................ 64
U.S. Patent 8,719,617 Petition for Inter Partes Review
1
I. INTRODUCTION
U.S. Patent No. 8,719,617 (“the ’617 patent,” Ex. 1001) claims as inventive
the straightforward application of well-known, decades-old, checkpointing
recovery techniques to the context of an IMS network. Not only was the core idea
old, but others, including Ericsson and Nokia, already had publicly proposed the
very same techniques for IMS networks before the priority date of the ’617 patent.
II. MANDATORY NOTICES
A. Real Parties-in-Interest
T-Mobile US, Inc. and T-Mobile USA, Inc. (“Petitioners”) and Nokia
Solutions and Networks US LLC and Nokia Solutions and Networks OY are the
real parties-in-interest and submit this inter partes review Petition (“Petition”) for
review of certain claims of U.S. Patent No. 8,719,617 (“’617 patent”).
B. Related Matters
The following litigation matter would affect or be affected by a decision in
this proceeding: Huawei Technologies Co. Ltd. v. T-Mobile US, Inc. et al., Case
No. 2:16-cv-00052-JRG-RSP (E.D. Tex. Jan. 15, 2016). Petitioners have or soon
will file inter partes review petitions for U.S. Patent Nos. 8,625,527; 8,531,971;
8,069,365; and 8,638,750, which are also asserted in cases between the same
parties in litigation before the same court.
C. Counsel
Lead Counsel: Peter M. Dichiara (Registration No. 38,005)
U.S. Patent 8,719,617 Petition for Inter Partes Review
2
Backup Counsel: Joseph F. Haag (Registration No. 42,612)
Backup Counsel: Evelyn C. Mak (Registration No. 50,492)
Backup Counsel: Kathryn D. Zalewski (pro hac vice to be requested)
D. Service Information
E-mail: [email protected], [email protected]
Post and Hand Delivery: WilmerHale, 60 State St., Boston MA 02109
Telephone: 617-526-6000
Petitioners consent to service by email.
III. CERTIFICATION OF GROUNDS FOR STANDING
Petitioners certify pursuant to Rule 42.104(a) that the ’617 patent is
available for inter partes review and that Petitioner is not barred or estopped from
requesting an inter partes review challenging the patent claims on the grounds
identified in this Petition.
IV. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED
Pursuant to Rules 42.22(a)(1) and 42.104(b)(1)-(2), Petitioners challenge
claims 1, 4, 5, 7, and 10 of the ’617 Patent (the “challenged claims”) and request
that each challenged claim be canceled.
A. Prior Art Patents and Printed Publications
Petitioners rely upon the patents and printed publications listed in the Table
of Exhibits, including:
U.S. Patent 8,719,617 Petition for Inter Partes Review
3
1. U.S. Patent No. 7,769,374 to Phan-Anh et al., filed March 12, 2001
(“Phan-Anh,” Ex. 1003).
2. 3GPP Technical Report 23.821 v1.0.1 (July 2000), 3rd Generation
Partnership Project, Architecture Principles for Release 2000 (“TR
23.821,” Ex. 1004).
3. S2-060216, Reassignment for S-CSCF during the terminated call
procedure, Huawei, 3GPP TSG SA WG2 #50, January 16-20, 2006
(“S2-060216,” Ex. 1005).
4. 3GPP Technical Specification 23.228 v7.2.0 (December 2005), IP
Multimedia Subsystem (IMS); Stage 2 (“TS 23.228,” Ex. 1007).
B. Level of Ordinary Skill in the Art
The ’365 patent relates to the field of communications technology in general,
and more specifically the operation of components of the IP Multimedia
Subsystem (IMS). At the time the ’365 patent was filed, a person of ordinary skill
in this field would have had at least a bachelor’s degree in computer science or
electrical engineering and 3-4 years of professional experience in communications
technology, or equivalent academic experience. Such a person would have been
familiar with the 3GPP standard in general and preferably to its specifications
related to IMS. (Ex. 1002, Decl. ¶¶ 21.)
U.S. Patent 8,719,617 Petition for Inter Partes Review
4
C. Relief Requested
Petitioners request that the Patent Trial and Appeal Board cancel the
challenged claims because they are unpatentable under 35 U.S.C. § 103 as set forth
in this Petition. This conclusion is supported by the declaration of Mr. Craig
Bishop (“Bishop Declaration,” Ex. 1002), filed herewith.
V. OVERVIEW OF THE ’617 PATENT
The ’617 patent describes methods and components for recovering a user
service in an IP multimedia subsystem (IMS) when a particular server in that
system (called the Serving Call Session Control Function, or S-CSCF) fails.1 (Ex.
1002, Decl. ¶44.)
A. Background IMS Technology
IMS is a well-known system first standardized by the 3rd Generation
Partnership Project (“3GPP”) from 2001through 2002, long before the priority date
of the ’617 patent. IMS was developed as a solution for IP-based multimedia
communications following an initial 3GPP study of an Architecture for All IP
Network, which itself started in 1999. (See Ex. 1008, SP-000289 (June 2000 Work
1 The ’617 issued from a continuation application that ultimately issued as U.S.
Patent No. 8,069,365. Petitioner also has filed a petition for inter partes review of
the ’365 patent, based on the same prior art. Accordingly, the discussion of the
’617 patent and prior art that follows is similar to that in the ’365 petition.
U.S. Patent 8,719,617 Petition for Inter Partes Review
5
Item description for IMS).)
IMS was designed to enable network operators to offer their subscribers
multimedia services based on and built upon Internet applications, services, and
protocols. (See id.) The IMS Core Network contains Session Initiation Protocol
(SIP) servers, called “control functions,” as well as a user database. IMS uses SIP
as the signaling mechanism between the control functions for establishing,
modifying, and ending sessions. (Ex. 1007 at 26 (signaling flows based on SIP).)
SIP was first standardized in 1999 and has been commonly used over Internet
Protocol networks since then. (See Ex. 1007 at 14.) The diagram below shows the
IMS core network components relevant to this Petition:
U.S. Patent 8,719,617 Petition for Inter Partes Review
6
(Ex. 1009, CSCF in VoLTE, located at
http://lteuniversity.com/get_trained/expert_opinion1/b/lpatterson/archive/2013/06/
12/cscf-in-volte-the-p-cscf-part-1-of-4.aspx.) (Ex. 1002, Decl. ¶45-49.)
1. IMS Core Components
IMS and its components were defined by the standards promulgated by
3GPP before the ’617 patent, and described in Technical Specification 23.228.
(Ex. 1002, Decl. ¶50.) In relevant part, an IMS core network includes three types
of Call Session Control Function (CSCF) and a Home Subscriber Server (HSS),
each of which was well known in the prior art before the patent:
P-CSCF: The proxy CSCF (“P-CSCF”) is the first point of contact
within the IMS for a mobile terminal (“UE”) requesting registration
with the IMS or requesting a service. The UE attaches to a P-CSCF
before it can register with IMS or communicate within IMS. For
example, the P-CSCF will forward requests from the UE to register
with IMS. It will also forward and receive requests for calls for the
UE. The UE remains attached to the same P-CSCF for the duration of
its registration. (See Ex. 1001, 1:39-45, Figs. 1, 2.)
I-CSCF: The interrogating CSCF (“I-CSCF”) is the first point of
contact within the IMS for the P-CSCF of a UE that is requesting
registration or is already registered. The I-CSCF will receive
U.S. Patent 8,719,617 Petition for Inter Partes Review
7
registration requests from the UE sent via a P-CSCF, and will assign a
Serving CSCF (S-CSCF) to the user during registration. It also will
receive all messages destined for users of that network, and will
determine where to forward those messages. (See id.)
S-CSCF: The serving CSCF (“S-CSCF”) is the heart of the IMS core
network. In addition to its SIP Server functionality, the S-CSCF acts
as a SIP registrar by registering the user, and instructing the HSS to
record the assigned S-CSCF information with the user’s profile. (See
id., 2:6-21, 2:36-40.) The S-CSCF provides session control services
for the UEs registered with it. Different S-CSCFs within an
operator’s network may have different capabilities. (See id., 1:46-62.)
HSS: The Home Subscriber Server is a master user database that was
first introduced during the 1999 study on the All-IP network. It
contains the subscription-related information (subscriber profiles).
(See id., 1:46-47, 2:35-36.)
(Ex. 1002, Decl. ¶50.)
2. IMS Information Flows
TS 23.228, the prior art standard which defines IMS, uses the term
“information flow” to refer to the interactions between components and illustrates
the flows with diagrams. (Ex. 1007 at 44.) The ’617 patent admits that the
U.S. Patent 8,719,617 Petition for Inter Partes Review
8
relevant information flows for IMS were known “in the prior art.” (Ex. 1001,
1:25-3:8.) As will be seen below, the purported invention uses these same flows
and the messages that implement them. (Ex. 1002, Decl. ¶¶51-54.)
For example, Figure 1 of the patent depicts an information flow for a user
who “subscribes and registers in the IMS network in the prior art,” and Figure 2
shows “setting up a session between a calling party and a called party registered in
the IMS in the prior art.” (Ex. 1001, 1:36-38, 2:44-46.) As Mr. Bishop confirms,
Figures 1 and 2 and the accompanying descriptions are identical in substance to
those shown in prior art TS 23.228 and version 7.0.0 of TS 29.228 (“TS 29.228,”
Ex. 1010), both published in December 2005. (Ex. 1007 at 44, 80-83; Ex. 1010 at
36, 39, 40.) Although the flows have many steps, at most only three or four steps
are relevant to the ’617 claims. (Ex. 1002, Decl. ¶55.)
Registration: In the first prior art information flow, the UE requests
registration and the I-CSCF assigns an S-CSCF to the UE. This flow, as specified
in TS 23.228 and TS 29.228, is shown in Figure 1 of the ’617 patent (highlighted
in color below):
U.S. Patent 8,719,617 Petition for Inter Partes Review
9
(Ex. 1001, Fig. 1, 1:36-38; Ex. 1007 at 44, Fig. 5.1; Ex. 1010 at Fig. A.4.1.1.) The
UE (the user equipment or mobile device) sends a register request message to the
P-CSCF, which forwards it to an I-CSCF (2. REGISTER). (Ex. 1001, 1:39-45; see
also Ex. 1007 at 44, Fig. 5.1.) (Ex. 1002, Decl. ¶56.)
The I-CSCF then assigns an S-CSCF to the user (yellow). To do so, the I-
CSCF “interrogates” the HSS by sending a User-Authorization-Request (“UAR”)
message to the HSS requesting information about the service processing
capabilities the S-CSCF must have to service the particular user requesting
U.S. Patent 8,719,617 Petition for Inter Partes Review
10
registration. (Ex. 1001, 1:46-53; Ex. 1010 at 10-11.) The HSS returns a User-
Authorization-Answer (“UAA”) message identifying the service processing
capabilities required by the user. (Ex. 1001, 1:53-58.) The I-CSCF then assigns an
S-CSCF “to the user according to the capability set requirements,” and forwards
the register request to the assigned S-CSCF (blue). (Id., 1:58-62, 2:12-15; Ex.
1007 at 45 (“the I-CSCF shall perform the new S-CSCF selection function based
on the capabilities returned”).) (Ex. 1002, Decl. ¶57.)
Thereafter, the S-CSCF records the assignment information in the HSS
(green). The S-CSCF sends a Server-Assignment-Request (“SAR”) interface
message to the HSS containing the name of the assigned S-CSCF and the identity
of the registered user. (Ex. 1001, 2:19-21.) The HSS stores the S-CSCF
information with the user information, and returns a Server-Assignment-Answer
(“SAR”) message containing subscriber information (including user profile) to the
S-CSCF. (Id., 2:19-21, 2:35-36; Ex. 1010 at 10-11.) The S-CSCF locally stores
“the subscription service data of the user, . . . the address of the P-CSCF where the
user passes through when getting access to the IMS network, and a contact address
of the user terminal.” (Id., 2:36-40; see also Ex. 1007 at 45, 47 (“The S-CSCF
shall store the P-CSCF address/name” and “information for the indicated user”).)
A registration timer is then started, which will force periodic re-registration upon
expiration to ensure that the user is still reachable. (Ex. 1001, 3:42-44.) (Ex. 1002,
U.S. Patent 8,719,617 Petition for Inter Partes Review
11
Decl. ¶58.)
Mobile Origination/Termination: After registration, the UE can make calls
(“mobile origination”) and receive calls (“mobile termination”). The general flow
for setting up a session is shown in Figure 2:
(Ex. 1001, Fig. 2, 2:44-46.) The calling UE sends a session setup request (i.e.,
INVITE) to its P-CSCF, which then “routes . . . the request to the S-CSCF with
which the calling party registers” (steps 1 and 2). (Id., 2:51-53.) The S-CSCF of
the calling UE then “routes the request message to the I-CSCF” in the called
party’s home network (step 3). (Id., 2:53-56.) The I-CSCF determines “the
address of the S-CSCF with which the called user registers” by sending a Location
Info Request (“LIR”) message to the HSS, which returns a Location Info Answer
(“LIA”) message containing the address (steps 4 and 5). (Id., 2:56-58; Ex. 1010 at
U.S. Patent 8,719,617 Petition for Inter Partes Review
12
20-21 (describing the LIR and LIA messages).) The I-CSCF forwards the session
setup request to the called UE via the S-CSCF and “the P-CSCF where the called
user passes through when getting access to the IMS network.” (Ex. 1001, 2:59-
3:3; Ex. 1002, Decl. ¶59.)
All the messages discussed above were specified in TS 29.228 prior to the
invention of the ’617 patent. (Ex. 1010 at 10-17, 20, 21.) (Ex. 1002, Decl. ¶60.)
B. Purported Problem and Solution of the ’617 Patent
The ’617 patent explains that, in “the prior art,” if the S-CSCF fails,
assignment of a new S-CSCF will not occur until re-registration is triggered via
expiration of the registration timer. (Ex. 1001, 3:4-7.) The patent explains that, for
this reason, “the service interruption duration of the user depends on the duration
of the registration cycle of the user.” (Id., 3:47-61.) A longer registration cycle
could result in a longer service interruption to the user, but a short cycle could
result in excessive re-registrations. (Id., 3:42-61.) (Ex. 1002, Decl. ¶61.)
The ’617 patent purports to address S-CSCF failures by restoring service
processing by an S-CSCF without requiring re-registration. (See Ex. 1001, 3:65-
67.) In the proposed method, the S-CSCF stores data for restoring a user service
request on the HSS during registration. If that S-CSCF fails, the stored data may
then be retrieved from the HSS and used by a newly-assigned S-CSCF to allow
service to continue without requiring a new registration. (Id., 4:6-20.) (Ex. 1002,
U.S. Patent 8,719,617 Petition for Inter Partes Review
13
Decl. ¶62.)
The first step in the claimed procedure is to back up the data that might be
needed in the event of an S-CSCF failure on the HSS. To do so, the ’617 patent
uses the same steps and the same messages as the prior art registration process,
described above, but with minor modification. These steps are depicted in Figure
5, which shows the registration flow “according to an embodiment of the present
invention” (highlighted in color):
(Ex. 1001, 7:24-25, Fig. 5). This process is almost identical to the prior art
U.S. Patent 8,719,617 Petition for Inter Partes Review
14
registration process, depicted in Figure 1, with step 16 slightly modified. (Id.,
7:24-29, Fig. 1.) At step 16, as in the prior art procedure, the S-CSCF sends an
SAR message including the S-CSCF and user identities to request the HSS to
“record[] the address of the S-CSCF with which the user registers.” (Id., 2:16-21,
2:35-36.) However, the SAR message also includes a new field containing “the
necessary data which is required when the user service processing is restored,”
which the HSS stores. (Id., 7:29-33 (“AVP User-Backup-Data”).) The so-called
“necessary data” (or “restoration data” as in the claims) is now backed up to the
persistent storage of the HSS and available to be used if needed. (Ex. 1002, Decl.
1002, ¶¶ 63-64.)
After registration, the S-CSCF may not be able to set up a subsequent call
due to failure of the S-CSCF. Figure 7a (annotated below) shows a scenario in
which the UE is the called party (mobile termination) and the I-CSCF in the user’s
network cannot contact the S-CSCF assigned to the user:
U.S. Patent 8,719,617 Petition for Inter Partes Review
15
(Ex. 1001, 13:18-46, Fig. 7(a).) After receiving the request to set up a call, the I-
CSCF determines which S-CSCF the UE is registered to by querying the HSS with
an LIR message (steps 2 and 3). (Id., 13:25-27, Fig. 7(a).) If the I-CSCF
determines that the assigned S-CSCF (S-CSCF1) has failed, it assigns a new one
(S-CSCF2) using the same prior art procedure—using UAR/UAA or LIR/LIA
messages—described above (steps 4-6). (Id., 13:29-39.) The S-CSCF2 then
“interrogates and acquires the subscription data and the backup data of the called
user from the HSS” using SAR/SAA messages. (Id., 13:54-58.) (Ex. 1002, Decl.
U.S. Patent 8,719,617 Petition for Inter Partes Review
16
¶65.)
Figures 6(c) and (d) and 7(b) and (c) depict a third type of failure situation in
which “the S-CSCF first fails and then restores from a failed status, but the service
data recorded by the S-CSCF is lost.” (Ex. 1001, 12:36-38.) Figure 7(c)
(annotated) shows this flow in a mobile termination scenario:
U.S. Patent 8,719,617 Petition for Inter Partes Review
17
(Id, Fig. 7(c).) This scenario uses the same procedures described above to
determine which S-CSCF is assigned to the user (i.e., LIR/LIA messages) and to
retrieve the backed-up data at the S-CSCF, but there is no need to assign a new S-
CSCF. (Id., 14:3-19.) (Ex. 1002, Decl. ¶ 66.)
C. Summary of the Prosecution History
The ’617 patent issued from U.S. Patent Appl. No. 12/428,810, filed on
October 31, 2011, which is a continuation of U.S. Patent No. 8,069,365 (“’365
patent”), filed on April 23, 2009, which is a continuation of PCT/CN2007/070943,
filed on October 23, 2007. The ’617 patent claims priority to two Chinese patent
applications: (1) CN 2006 1 0150721, filed October 24, 2006; and (2) CN 2007 1
0135727, filed August 10, 2007.
The applicants originally filed 28 claims, and the Examiner rejected all 28
claims on obviousness-type double patenting grounds in light of the ’365 patent.
(Ex. 1006, 6/17/13 Office Action at 2-6.) The Examiner also rejected claims 16
and 18 as anticipated by S2-060216, a proposal submitted to the 3GPP SA
Working Group 2, described in more detail below. (Ex. 1006, 6/17/13 Office
Action at 2-6.) Claim 16 was directed to an I-CSCF with specialized modules
“adapted to. . . judge . . . whether a serving CSCF (S-CSCF) currently providing a
service for a user fails or not,” “assign a new S-CSCF for the current user” if the S-
CSCF had failed, and “forward the session setup request to the newly assigned S-
U.S. Patent 8,719,617 Petition for Inter Partes Review
18
CSCF after finishing assigning the new S-CSCF.” (Id.) The Examiner found each
of these limitations disclosed in S2-060216. (Id. at 3-5.) Claim 18 added modules
adopted to “interrogate a capability requirement” and “assign the new S-CSCF to
the user according to the capability requirement” from a set of redundant S-CSCFs,
which the Examiner also found to be disclosed in S2-060216. (Id. 5-6.) In short,
the Examiner found that S2-060216 disclosed all limitations related to assignment
of a new S-CSCF to a user in the event of a failure of the original S-CSCF. (Ex.
1002, Decl. ¶¶ 68-69.)
The applicants canceled all 28 claims and submitted ten new claims, each of
which required (unlike original claims 16 and 18) receiving “restoration data”
“used for restoring the service that failed” from the storage entity, where the
restoration data had been “stored by the previous S-CSCF.” (Ex. 1027, 11/18/13
Reply.) The Examiner rejected eight of the ten claims on double-patenting
grounds, and found that the remaining two claims (issued claims 4 and 10would be
allowable if written in independent form. (Ex. 1028, 12/31/13 Office Action.) The
applicants also filed a terminal disclaimer, and the Examiner allowed the claims.
(Ex. 1029, 1/29/14 Terminal Disclaimer.) (Ex. 1002, Decl. ¶ 70.)
Though the S2-060216 proposal was before the Examiner during
prosecution, the other references cited in this Petition were not. This Petition
applies S2-060216 in the same way that the Examiner applied it to original claims
U.S. Patent 8,719,617 Petition for Inter Partes Review
19
16 and 18, i.e., as anticipating the process of selecting a new S-CSCF when the
original S-CSCF fails. The Examiner did not have any references before him that
disclosed storing restoration data during registration and then retrieving that
restoration data, upon failure of the S-CSCF, in order to restore service to the user.
As discussed below, Phan-Anh discloses that storing and retrieving procedure.
(Ex. 1002, Decl. ¶ 71.)
VI. CLAIM CONSTRUCTION
The challenged claims in inter partes review should be given their “broadest
reasonable construction in light of the specification.” 37 C.F.R. § 42.100(b).
Under this standard, any claim term not explicitly defined in the specification
should be given a broad meaning. In re ICON Health & Fitness, Inc., 496 F.3d
1374, 1379 (Fed. Cir. 2007).
A. “restoration data” / “restoring data”
The broadest reasonable interpretations of the terms “restoration data
wherein the restoration data is stored by the previous S-CSCF” and “restoring
data” are their ordinary and customary meanings.2
2 Claim 5 requires “restoration data” “wherein the restoration data is stored by the
previous S-CSCF,” and then later refers to “receiv[ing]” “the restoring data.” (Ex.
1001, claim 5.) The term “restoring data” appears to be a typographical error and
“restoration data” may have been intended. In any event, “restoring data” is a
U.S. Patent 8,719,617 Petition for Inter Partes Review
20
In the pending litigation between the parties, Patent Owner has asserted that
these terms require a specific construction. In particular, Patent Owner proposes
that the terms should be construed as “information necessary for the S-CSCF to
handle traffic for a registered user, which includes at least a SIP URL of a P-CSCF
assigned for a user device and a contact address of the user device.”3 (Ex. 1012,
Joint Claim Construction Statement, at 5 (“Joint Claim Chart”).) This is the same
meaning that the Patent Owner proposes for a different set of terms in the ’365
parent application, “necessary data which is required when a user service
processing is restored,” “necessary data,” and “backup necessary data.” (Id., at 2-
3.)
If the Patent Owner were to pursue the same or similar construction in this
proceeding, it should be rejected. The Patent Owner improperly seeks to import
limitations into the claims through its constructions. But the patent specification
does not contain any lexicography through which the inventors sought to define the shorthand reference to “restoration data wherein the restoration data is stored by
the previous S-CSCF.” (Ex. 1002, Decl. ¶ 73 n.2.)
3 The ’617 patent incorrectly refers to the address of the P-CSCF as a “SIP URL.”
The correct term is “SIP URI.” However, these terms were sometimes used
interchangeably during the development of IMS, and the term “SIP URL” can be
found in some of the early version of the standards. (Ex. 1002, Decl. ¶¶ 74 n.3.)
U.S. Patent 8,719,617 Petition for Inter Partes Review
21
terms. There is therefore no basis to deviate from the ordinary and customary
meaning of these terms. (Ex. 1002, Decl. ¶ 75.)
Moreover, the limitations that Patent Owner seeks to import into the terms
(in its proposals for litigation) are found in dependent claims 4 and 10. Importing
these limitations into the “restoration data” terms would render claims 1 and 7
identical in scope to their dependent claims, and violate the doctrine of claim
differentiation. (Ex. 1002, Decl. ¶ 76.) Ariosa Diagnostics v. The Board of
Trustees of the Leland Stanford Junior University, IPR2013-00308, Paper 40, at
12–13 (PTAB Nov. 19, 2014).
VII. GROUNDS FOR CHALLENGE
This Petition, supported by the Declaration of Mr. Craig Bishop filed
herewith, demonstrates that there is a reasonable likelihood that Petitioners will
prevail with respect to at least one challenged claim and that each of the challenged
claims is not patentable. See 35 U.S.C. § 314(a.)
Mr. Bishop has been a communications specialist for twenty-six years. Prior
to starting his consulting firm in 2013, he worked for Samsung, beginning in 1996
as Senior Standards Engineer and eventually became Director of Standards and
Industry Affairs. During his tenure at Samsung, he was involved in many different
3GPP and ETSI committees working on GPRS, UMTS, and IMS specifications.
(Ex. 1002, ¶¶ 2-11.)
U.S. Patent 8,719,617 Petition for Inter Partes Review
22
At the time of the ’617 patent, Mr. Bishop was working in, and had
extensive expertise in IMS and core network technology. In particular, Mr. Bishop
was an active delegate in the 3GPP Service and System Aspects Working Group 2
from 2005 – 2008, working on the IP Multimedia Subsystem. The work required a
sound working knowledge of the core IMS specifications, as well as other 3GPP
IMS and IETF (SIP) specifications, to ensure effective participation in meeting
discussions, assessment of third party contributions, and provision of
implementation guidance to Samsung developers. (Ex. 1002, Decl. ¶ 6.)
From 2008 until 2011, Mr. Bishop was a member of 3GPP SA1, initially
focusing on IMS issues, though later contributing across all topics of relevance to
Samsung. (Ex. 1002, Decl. ¶ 7.) Over the course of his work with 3GPP SA2 and
SA1 between 2006 and 2010, Mr. Bishop authored and submitted 99 meeting
contributions. Mr. Bishop also served as the main Samsung contact in 2009 on
VoLTE issues, working with to specify the IMS profile for voice and SMS that
was later to become GSMA Permanent Reference Document IR.92. Mr. Bishop is
a named inventor on 18 patents related to IMS and core network. (Ex. 1002, Decl.
¶¶ 7-10.)
Pursuant to Rule 42.104(b)(4)-(5), specific grounds for finding the
challenged claims invalid are identified below and discussed in the Bishop
Declaration.
U.S. Patent 8,719,617 Petition for Inter Partes Review
23
A. Overview of Prior Art
As explained above, the ’617 patent is directed to a recovery system and
methods in which a particular server node (called an S-CSCF) stores “restoration
data” to the HSS; a new S-CSCF is assigned to the user if the original S-CSCF
fails; and the new S-CSCF retrieves the stored restoration data so that processing
can continue. (Ex. 1002, Decl. ¶ 77.)
There was nothing new about the ’617 patent technique. As Mr. Bishop
explains, the ’617 patent claims are nothing more than a straightforward
application of well-known checkpointing type recovery techniques to IMS
networks.
Checkpointing is a basic recovery technique that has been known for
decades. For example, in 1982, Dr. Daniel Siewiorek explained in his textbook
“The Theory and Practice of Reliable System Design” that
In checkpointing, some subset of the system state is
saved at specific points (the checkpoint) during process
execution. The information to be stored is the subset of
system state (data, programs, machine state) that is
necessary to the continued successful execution and
completion of the process past the checkpoint, and which
is not backed up by other means.
(Ex. 1013, at 170.) Checkpointing is “most often implemented in software and
requires little or no extra hardware.” (Id.) (Ex. 1002, Decl. ¶ 79.)
U.S. Patent 8,719,617 Petition for Inter Partes Review
24
Checkpointing and similar recovery techniques have been used in cellular
and other types of networks since long before the ‘617 patent. To provide just a
few examples:
U.S. Patent No. 6,108,300, filed August 25, 1997, describes a
recovery technique for network devices. The primary network device
“sends configuration commands to secondary network device 310 . . .
so that secondary network device 310 may mirror the configuration of
300 for the purpose of substituting for primary network device 300 in
the event that primary network device 300 fails.” (Ex. 1014, Abstract,
6:43-54.)
U.S. Patent No. 6,885,861, filed August 24, 2001, describes “a
solution which facilitates mobility and service recovery when there is
a failure in a user’s terminal.” (Ex. 1015, 4:14-19.) “[T]the
information necessary for providing mobility and service recovery for
users’ communication services is maintained in a server,” such as the
HSS. (Id., 4:20-23, 6:10-15.) The HSS sends a message to the new
terminal that “includes information necessary for the communication
services to be received by the new user terminal.” (Id., 6:44-51.)
U.S. Patent No. 6,963,996, filed April 30, 2002, describes a recovery
procedure for failed Web servers “such that data communications
U.S. Patent 8,719,617 Petition for Inter Partes Review
25
between a client and server need not be repeated when a such a failure
occurs.” (Ex. 1016, 1:11-19.) A session integrity proxy “records
requests sent by the web client 104 and/or responses sent by the web
server 106.” (Id., 4:65-67.) “When a failure is detected at the web
server 106, the session integrity proxy 102 will restore some or all of
the requests and responses recorded during the session to another web
server 106.” (Id., 5:12-15.)
U.S. Patent No. 6,408,182, filed July 16, 1999, describes an
architecture for mobile switching centers (“MSC”) in GSM in which
mobile communications are sent to a backup MSC when the primary
MSC fails. (Ex. 1017, 1:58-2:7.) The backup MSC then “fetch[es]
the subscriber data from the subscriber’s Home Location Register
(HLR)” (the database of subscriber information in GSM) and stores it
at the backup MSC. (Id., 4:4-9.)
(Ex. 1002, Decl. ¶ 81.)
Not surprisingly, the same concept was proposed for the All-IP network that
preceded IMS and for the earliest IMS more than five years before the priority
date of the ’617 patent. For example, as discussed below, Phan-Anh, originally
assigned to Nokia, discloses storing data related to the location of the user in the
HSS during registration and retrieving it to restore processing if an S-CSCF failed.
U.S. Patent 8,719,617 Petition for Inter Partes Review
26
(Ex. 1002, Decl. ¶ 82.)
Similarly, multiple prior art submissions to 3GPP proposed the same
concept for assigning a new S-CSCF to the user in the analogous situation when
the first S-CSCF failed and was replaced (rather than failed and restarted). For
example, in 2002, Ericsson suggested this procedure in S2-022876, submitted to
the SA Working Group 2 for discussion at the meeting held on October 14-18,
2002. (Ex. 1018 at 2-3 (“An assigned S-CSCF could be down when contacted by
an I-CSCF. Further requests from the I-CSCF to the HSS (Cx-Query or Cx-
Location-Query) would result in the same S-CSCF name. The I-CSCF should have
the possibility to ask explicitly for the capabilities for the selection of a new S-
CSCF. . . . Re-assignments of S-CSCF due to failures in S-CSCFs shall take place
both during re-registrations and session initiations to unregistered users.”).)
Huawei subsequently proposed a more detailed procedure in early 2006 in S2-
060216, as discussed below, but those details were simply an application of the
known Cx interface messages to Ericsson’s proposal. (Ex. 1002, Decl. ¶ 84.)
Finally, Nokia Siemens Networks filed a European patent application
covering the very same restoration procedure as disclosed in the 2006 Chinese
application to which the ’617 patent claims priority on the same day that the
Chinese application was filed. (See Ex. 1011, Cover and claim 1.) This
“simultaneous invention” further confirms the obviousness of the claims.
U.S. Patent 8,719,617 Petition for Inter Partes Review
27
B. Ground 1: Claims 1, 5, and 7 Are Invalid As Obvious Over the Combination of Phan-Anh and S2-060216
Claims 1, 5, and 7 are obvious over the combination of Phan-Anh in view of
S2-060216. As discussed above, S2-060216 was cited by the Examiner during
prosecution as anticipating two of the original claims of the ’617 patent
application. There the Examiner found that, just like the two rejected claims, S2-
060216 disclosed an I-CSCF “adapted to” “judge . . . whether a serving CSCF (S-
CSCF) currently providing a service for a user fails or not,” “assign a new S-CSCF
for the current user” if the S-CSCF had failed, and “forward the session setup
request to the newly assigned S-CSCF after finishing assigning the new S-CSCF.”
(Ex. 1006, 6/17/13 Office Action at 2-6.) The two rejected claims were canceled
and replaced with new ones that had new limitations in which the S-CSCF received
“restoration data” “used for restoring the service that failed” from the storage
entity, where the restoration data had been “stored by the previous S-CSCF.” (Ex.
1027, 11/18/13 Amendment at 2-4.) As explained below, Phan-Anh (which was
not before the Examiner during prosecution), in combination with S2-060216,
teaches the purportedly novel limitations directed to assigning a new S-CSCF and
the storing and retrieving restoration data. (Ex. 1002, Decl. ¶¶ 86-88.)
Phan-Anh was filed on March 12, 2001, published on September 12, 2002 as
U.S. Patent Publication No. US20020128008 A1, and is prior art to the ’617 patent
under 35 U.S.C. § 102(a) and (e). Phan-Anh incorporates TR 23.821 by reference
U.S. Patent 8,719,617 Petition for Inter Partes Review
28
in its entirety. (Ex. 1003, 1:16-20.) TR 23.821 is a 3GPP Technical Report
uploaded to the public 3GPP server on June 28, 2000. S2-060216 is a 3GPP Tdoc
uploaded to the public 3GPP server on January 10, 2006. As discussed below, TR
23.821 and S2-060216 are prior art to the ’617 patent under 35 U.S.C. § 102(b).
(See Ex. 1002, Decl. ¶ 89.)
As explained below, Phan-Anh discloses storing restoration data on the HSS
during registration and retrieving that data to restore a service after an S-CSCF
fails and restarts. S2-060216 discloses assigning a new S-CSCF when the
previously-assigned S-CSCF fails. (Ex. 1002, Decl. ¶ 90.) As shown below, the
figures found in both references as compared to the figures in the ’365 patent
specification, demonstrate that Phan-Anh and S2-060216 contained substantively
identical disclosures to those in the ’365 patent. It is therefore not surprising that
the ’365 patent claims read on these references, as demonstrated in the element by
element analysis of the Grounds Sections.
1. Overview of Phan-Anh
Like the ’617 patent, Phan-Anh teaches a recovery procedure to be used
when the S-CSCF restarts and has lost data associated with the user. Phan-Anh
was filed over five years before the ’617 patent, when IMS was in the early stages
of development, demonstrating how straightforward, simple, and universally well-
known the checkpointing concept was. (Ex. 1002, Decl. ¶ 91.)
U.S. Patent 8,719,617 Petition for Inter Partes Review
29
Phan-Anh incorporates TR 23.821 by reference in its entirety. (Ex. 1003,
1:16-20.) TR 23.821 discloses that “for the purpose of the registration procedures .
. . [t]he serving CSCF [S-CSCF] understands a service profile and the address of
the functionality of the proxy CSCF [P-CSCF],” and indicated that after
registration, the S-CSCF must store “Subscriber information” and “Proxy
address/name.” (Ex. 1004 at 27-28 and B.4 (table showing “Stored Information).)
TR 23.821 also contemplated that the proxy address and name would be stored in
the HSS after registration. (Id.) (Ex. 1002, Decl. ¶ 92.)
With this backdrop, Phan-Anh explains that “the network disclosed in the
Technical Report [TR 23.821] fails to include any protection of the user’s transport
address (“TA”),” “IP address,” or “location information of a subscriber after a
CSCF crash, thereby preventing recovery after a CSCF crash.” (Ex. 1003, 1:26-
34.) Phan-Anh also notes that “the reachability of a subscriber is maintained in
two levels, namely, the network element level and the subscriber level.” (Id., 2:44-
46.) For this reason, “[t]he S-CSCF that the subscriber is currently registered to
and the TA of the roaming subscriber, which the subscriber provides to the
network during Application Level (AL) registration, must be known to and
maintained by the network.” (Id., 2:46-50.) As Mr. Bishop explains, at the time
Phan-Anh was filed, the 3GPP SA2 working group was developing the IMS
architecture and considered the IP address of the UE to be the way that the UE
U.S. Patent 8,719,617 Petition for Inter Partes Review
30
could be reached by the S-CSCF. SA2 had also specified that the UE address was
the only address not stored in the HSS following registration (both S-CSCF and
Proxy CSCF addresses were). (Ex. 1002, Decl.¶¶ 93-94; see Ex. 1030, S2-012330
(later changing contact method from IP address to P-CSCF address).) For this
reason, the inventors of Phan-Anh found that the TA of the subscriber therefore
“should be protected against loss with the same level of security as that for the
Serving CSCF (S-CSCF).” (Ex. 1003, 4:4-6.) “Keeping the current TA of the
subscriber ensures that a call made to the subscriber which arrives at the S-CSCF
can finally reach the subscriber.” (Id., 3:49-53.) (Ex. 1002, Decl. ¶ 94.)
As Mr. Bishop explains, a person of skill in the art would readily appreciate
that Phan-Anh therefore expands the teachings of TR 23.821 to “recovering
location information of a subscriber in a mobile network,” “including the
subscriber’s TA.” (Ex. 1003, 1:38-47; Ex. 1002, Decl. ¶ 95.) In one embodiment,
the TA, or “care of address,” is “an IP address associated with a mobile node while
the subscriber is visiting a particular foreign link.” (Id., 3:15-17.) Phan-Anh
explains that “[t]he TA of the subscriber should be forwarded to the HSS at
registration and downloaded from the HSS to the S-CSCF during recovery.” (Id.,
4:10-12.) Phan-Anh’s registration procedure is shown in Figure 4B (annotated
with the same color convention used above for the ‘617 patent):
U.S. Patent 8,719,617 Petition for Inter Partes Review
31
(Id., Fig. 4B.) In this procedure, as with the ’617 patent, “‘a safe copy’ of the
subscriber's TA is forwarded to the HSS for storage and protection.” (Id., 4:20-
21.) In step 1, “the registering subscriber forwards an AL registration request to
the S-CSCF including the TA.” (Id., 4:35-37.) In steps 2 and 3, the TA and S-
CSCF address are forwarded to the HSS, which “stores the updated TA and S-
CSCF address (in a hard disk, for example, or other non-volatile memory).” (Id.,
4:37-40.) In step 4, the HSS “forwards an AL Location Update acknowledgement
to the S-CSCF which stores the TA and subscription profile and other data in step
5.” (Id., 4:40-43.) (Ex. 1002, Decl. ¶ 95.)
Phan‐Anh
U.S. Patent 8,719,617 Petition for Inter Partes Review
32
TR 23.821 describes the data that is stored locally at the S-CSCF during
registration. Figure B.2 depicts the second part of the registration, which is the
same as Phan-Anh Figure 4B:
(Ex. 1004 at 51, Fig. B-2.) At H2, the S-CSCF “initiates the download of the
subscriber profile” and the HSS “provide[s] the serving CSCF with the requested
subscriber profile,” which the S-CSCF stores. (Id. at 51-52.) At the end of the
registration procedure, the S-CSCF has stored the HSS address and name, the
subscriber information, and the proxy (P-CSCF) address and name. (Ex. 1002,
Decl. ¶ 96.)
Phan-Anh Figure 4A (color added) shows how “[t]he TA and other data can
then be restored to the S-CSCF upon the earlier loss of the data by the S-CSCF”:
U.S. Patent 8,719,617 Petition for Inter Partes Review
33
(Id., 4:23-25, Fig. 4A.) In steps 1 and 2, “[a]n incoming call from an REP (Remote
End-Point) is received by the S-CSCF,” but the S-CSCF fails to find the
subscriber’s TA.” (Id., 4:26-28.) In step 3, “the S-CSCF initiates the restoration of
the subscriber's TA (and possibly other data) from the HSS.” (Id., 4:28-31.) In
step 4, the call “is then routed to the subscriber using the recovered TA.” (Id.,
4:33-34.) (Ex. 1002, Decl. ¶ 97.)
2. Overview of S2-060216
S2-060216 describes reassignment of a new S-CSCF after the original S-
CSCF has failed. It focuses on the exemplary situation “when the pre-assigned S-
CSCF is unavailable” during “the terminated call procedure,” i.e., when the UE is
the called party (also known as “mobile termination”). (Ex. 1005 at 1.) (Ex. 1002,
Decl. ¶ 98.)
a
Phan‐Anh
U.S. Patent 8,719,617 Petition for Inter Partes Review
34
Ericsson had proposed the concept of re-assignment after S-CSCF failure
years before in S2-022876, submitted to the same Work Group SA2 in 2002. (Ex.
1018 at 2-3.) Ericsson explained that “[a]n assigned S-CSCF could be down when
contacted by an I-CSCF,” and “[f]urther requests from the I-CSCF to the HSS” for
the name of the S-CSCF assigned to the user “would result in the same S-CSCF
name,” which had failed. Ericsson proposed that “[r]e-assignments of S-CSCF due
to failures in S-CSCFs shall take place both during re-registrations and session
initiations to unregistered users.” (Id.) When Huawei subsequently proposed a
more detailed procedure in early 2006 in S2-060216, the proposal was simply an
application of the known Cx interface defining messages between the S-CSCF and
I-CSCF and the HSS to Ericsson’s proposal. (Ex. 1002, Decl. ¶ 99.)
S2-060216 explains that “[t]he existing standards only consider . . .
reassignment [of an S-CSCF] during the registration procedure,” but “[i]t will take
a long time” and the caller “may give[] up the call during the reassignment
procedure.” (Ex. 1005 at 1.) S2-060216 suggested the same idea as the ’617
patent—“enabl[ing] the reassignment feature also in the terminated call procedure”
by “modify[ing] the existing Cx interface” to allow the I-CSCF to explicitly
request the S-CSCF capabilities from HSS. (Id. at 2.) (Ex. 1002, Decl. ¶ 100.)
This reassignment procedure is depicted in the Figure below (color added):
U.S. Patent 8,719,617 Petition for Inter Partes Review
35
(Ex. EX-S2 at 2.) S2-060216 describes the procedure as follows:
1. “When I-CSCF received a terminated SIP message, it queries the HSS”
using the LIR/LIA messages described above “to get the previous
assigned S-CSCF name.”
2. “Using that S-CSCF name, [the] I-CSCF . . . judges[s] whether the
pre-assigned S-CSCF is still available.”
S2‐060216
U.S. Patent 8,719,617 Petition for Inter Partes Review
36
3. “When [the] I-CSCF judge[s] that the pre-assigned S-CSCF is
unavailable,” it uses another LIR/LIA query to the HSS to retrieve
“the related S-CSCF capability.”
4. The I-CSCF then selects “a new S-CSCF2 and forward[s] the SIP
message” to S-CSCF2.
5. “[T]he new S-CSCF it will send the Cx-SAR message to [the] HSS,”
and the “HSS will record the new S-CSCF” assigned to the user.
6. All calls to the UE “will route to that new S-CSCF.”
(Id.) S2-060216 also noted that “the impact[] of the implementation to the existing
standard may be small.” (Id.) (Ex. 1002, Decl. ¶ 101.)
3. The 3GPP Documents Qualify As Prior Art to the ’617 Patent
TR 23.821, S2-060216, TS 23.228, SP-000289, TS 29.228, S2-022876, and
S2-012330 (Exhibits 1004-1005, 1007, 1008, 1010, 1018, and 1030) are prior art
because each was available to the interested public well before October 23, 2006,
which is one year prior to the U.S. filing date of the ’617 patent.
The “touchstone” of determining whether a reference constitutes a printed
publication is “public accessibility.” Kyocera Wireless Corp. v. ITC, 545 F.3d
1340, 1350 (Fed. Cir. 2008). “A reference is publicly accessible if it was
‘disseminated or otherwise made available to the extent that persons interested and
ordinarily skilled in the subject matter or art exercising reasonable diligence, can
U.S. Patent 8,719,617 Petition for Inter Partes Review
37
locate it.’” Kyocera, 545 F.3d at 1350-51 (finding public accessibility where
“ETSI did not impose restrictions on ETSI members to prevent them from
disseminating information about the standard to non-members”).
As discussed above, Mr. Bishop spent years working on 3GPP
standardization and is familiar with the publication practices of 3GPP from 1998 to
2006 and beyond. (Ex. 1002, Decl. ¶¶2-11.) Mr. Bishop explains that it has been
the practice of the 3GPP since 1998 to make standards proposals and draft standard
specifications publicly available on its FTP website, without password restriction,
before, during, or shortly after a working group meeting for which the documents
were intended, and to store them there for an indefinite period thereafter. (Id., ¶¶
38-43.) By navigating 3GPP’s public FTP website and accessing the hyperlinks on
the site, or by executing a simple Google search, an interested member of the
public could have downloaded each of the references of Exhibits 1004-1005, 1007,
1008, 1010, and 1018 without restriction. (Id., ¶43.) See LG Elecs. v. Core
Wireless Licensing S.A.R.L., IPR2015-01988, Paper 7, at 12–14 (PTAB Apr. 1,
2016). Mr. Bishop regularly downloaded 3GPP documents from the 3GPP public
FTP website in preparation for meetings. (Ex. 1002, Decl. ¶¶ 5-7, 25.)
Mr. Bishop also explains that the date and time each document was publicly
available can be determined, for example, by navigating to or searching for the
appropriate page on the 3GPP FTP web site and viewing the date and time the
U.S. Patent 8,719,617 Petition for Inter Partes Review
38
specific document was uploaded. (Id., ¶ 43; Ex. 1019 (3GPP document explaining
that each working group “has a specific documents area allocated on the 3GPP ftp
server . . . where you will find the all meeting documents including . . .
contributions (TDocs) relating to that group.”; Ex. 1020 (proposals and standards
specifications “on the public server, . . . will now get an upload date/time-stamp of
the new upload,” which “can be relied upon to indicate when the upload
occurred.”).)
The dates that Exhibits 1004-1005, 1007, 1008, 1010, 1018, and 1030 were
uploaded are shown by the screen shots of the FTP site pages to which they were
uploaded:
TR 23.821 (Ex. 1004) was publicly available no later than July 24,
2000. The zip file 23.821-101.zip (containing TR 23.821) was loaded
to the page for TR 23.821 at the 3GPP FTP site on July 24, 2000 at
9:50 am. (Ex. 1021 (screen capture).) (Ex. 1002, Decl. ¶¶ 32-33.)
S2-060216 (Ex. 1005) is a proposal that was available at the January
16-20, 2006 meeting #50 of the 3GPP Service and System Aspects 2
Working Group (SA2) in Budapest, Hungary, which Mr. Bishop
attended. The zip file S2-060216.zip (containing S2-060216) was
loaded to the loaded to the S2#50 working group meeting site on
U.S. Patent 8,719,617 Petition for Inter Partes Review
39
January 10, 2006 at 12:50 pm. (Ex. 1022 at 3.) (Ex. 1002, Decl. ¶¶
24-25.)
TS 23.228 (Ex. 1007) was publicly available no later than December
7, 2005, the date on which it was loaded to the corresponding 3GPP
FTP website. The zip file 23.228-720.zip (containing TS 23.228) was
loaded to the site on December 7, 2005 at 7:59 am. (Ex. 1023.) (Ex.
1002, Decl. ¶¶ 34-35.)
SP-000289 (Ex. 1008) is a proposal that was available at the June 26-
28, 2000 meeting #8 of the 3GPP SA working group in Düsseldorf,
Germany. SP-000289 was publicly available no later than June 26,
2000, the date on which it was loaded to the SP#8 working group
meeting site. The zip file containing SP-000289 was loaded on June
26, 2000 at 11:57 am. (Ex. 1024) (Ex. 1002, Decl. ¶¶26-27.)
TS 29.228 (Ex. 1010) was publicly available no later than December
23, 2005, the date on which it was loaded to the corresponding 3GPP
FTP website. The zip file 29.228-700.zip (containing TS 23.228 (Ex.
1007)) was loaded to the site on December 3, 2005 at 7:02 am. (Ex.
1025.) (Ex. 1002, Decl. ¶¶ 36-37.)
S2-022876 (Ex. 1018) is a proposal that was available at the October
14-18, 2002 meeting #27 of the 3GPP S2 working group in Beijing,
U.S. Patent 8,719,617 Petition for Inter Partes Review
40
China. S2-022876 was publicly available no later than October 23,
2002, the date on which it was loaded to the SA2#27 working group
meeting site. The zip file S2-022876.zip (containing S2-022876) was
loaded on October 23, 2002 at 4:19 pm. (Ex. 1026.) (Ex. 1002, Decl.
1002, ¶¶ 28-29.)
S2-012330 (Ex. 1030) is a change request that was available at the
August 27-31, 2001 meeting #19 of the 3GPP S2 working group in
Sophia-Antipolis, France. The zip file S2-012330.zip (containing S2-
012330) was loaded to the loaded to the S2#19 working group
meeting site on September 4, 2001 at 9:36 am. (Ex. 1031 at 6.) (Ex.
1002, Decl. ¶¶ 30-31.)
4. Claim 1
(a) “In a serving call session control function (S-CSCF), a method for realizing an Internet protocol multimedia subsystem (IMS) disaster tolerance, the method comprising”
This preamble does not limit the claim under the claim’s broadest reasonable
interpretation. To the extent the Board considers the preamble to be limiting,
Phan-Anh teaches a “method for realizing an Internet protocol multimedia
subsystem disaster tolerance” in “a serving call session control function (S-
CSCF).”
For example, Phan-Anh teaches a technique for “recovering location
U.S. Patent 8,719,617 Petition for Inter Partes Review
41
information of a subscriber in a mobile network,” “including the subscriber’s TA
[Transport Address] and the (S-CSCF) address,” “after Call State Control
Function (CSCF) crashes and after reset situations of a network element realizing
CSCF functionality after the S-CSCF and restarts, during which the S-CSCF loses
data. (Ex. 1003, 1:7-13, 1:38-47.) The “lost data including the subscriber’s TA
may be restored to the S-CSCF from the data stored in the S-CSCF.” (Id. at
Abstract.) Phan-Anh explains that “[k]eeping the current TA of the subscriber
ensures that a call made to the subscriber which arrives at the S-CSCF can finally
reach the subscriber.” (Id., 3:51-53.) (Ex. 1002, Decl. ¶ 94.)
S2-060216 also satisfies the preamble. S2-060216 proposes “introduc[ing]
the reassignment in the terminated call procedure” to “give [the] operator more
flexibility to recover from error especially in some case[s].” (Ex. 1005 at 2.) (Ex.
1002, Decl. ¶ 107.)
(b) ‘receiving a service request of a user forwarded by an interrogating CSCF (I-CSCF) when it is determined that a previous S-CSCF failed in providing a service to the user”
S2-060216 discloses this limitation. The figure of S2-060216 (color added)
shows “S-CSCF reassignment during the terminating call procedure”:
U.S. Patent 8,719,617 Petition for Inter Partes Review
42
(Ex. EX-S2 at 2.) In this figure, the I-CSCF has determined that the originally-
assigned S-CSCF1 is unavailable—e.g., due to a failure—and assigns S-CSCF2 to
the user using the LIR/LIA messages described above. The I-CSCF then forwards
the Invite to the newly-assigned S-CSCF2. (Id.) (Ex. 1002, Decl. ¶ 108.)
Phan-Anh also discloses that the S-CSCF receives a service request of the
user—e.g., a call set up request—from an I-CSCF, as does the ’617 patent. Figure
4A shows the restoration procedure when a subscriber is called (i.e., mobile
termination); it is juxtaposed to the mobile termination restoration procedure in
S2‐060216
U.S. Patent 8,719,617 Petition for Inter Partes Review
43
Figure 7(a) of the ’617 patent below (color added) and demonstrates that Phan-Am
contained substantively identical disclosure to that contained in the ’617 patent:
Phan‐Anh
’617 Patent
U.S. Patent 8,719,617 Petition for Inter Partes Review
44
(Ex. 1003, Fig. 4A; Ex. 1001, Fig. 7(a).) In step 1 of Figure 4A (in purple), “[a]n
incoming call from an REP (Remote End-Point)”—i.e., a “service request of the
user”—is received by the S-CSCF. (Ex. 1003, 4:26-28.) (Ex. 1002, Decl. ¶ 109.)
Figure 5 of Phan-Anh (color added) also shows another embodiment
disclosing the same claim element:
(Ex. EX-PHAN at Fig. 5.) At step 2, the I-CSCF in the home network of the user
receives an incoming call—i.e., a “service request of the user.” (Ex. 1002, Decl. ¶
110.)
Phan‐Anh
U.S. Patent 8,719,617 Petition for Inter Partes Review
45
(c) “sending a request for subscription data of the user and restoration data stored in a storage entity and used for restoring the service that failed to the user”
Phan-Anh discloses “sending a request for subscription data of the user”—
i.e., the subscription profile—and “restoration data”—i.e., the transport address
(TA) of the user—“ stored in a storage entity and used for restoring the service that
failed to the user”. Phan-Anh Figure 4A and ’617 Figure 7(a) (color added) both
show restoring the restoration data from the HSS:
Phan‐Anh
U.S. Patent 8,719,617 Petition for Inter Partes Review
46
(Ex. 1003, Fig. 4A; Ex. 1001, Fig. 7(a).) Like the HSS disclosed in the ’617
patent, the HSS in Phan-Anh has non-volatile memory and is part of the 3G All-IP
mobile network. (Ex. 1003, 4:38-40, Fig. 1 (“the architecture of a 3G All-IP
mobile network,” including an HSS), 2:16-17.) The HSS in Phan-Anh is a
“storage entity in a network.” (Ex. 1002, Decl. ¶ 111.)
Phan-Anh explains that, after the S-CSCF has failed to find the subscriber’s
transport address (“TA”), “the S-CSCF initiates the restoration of the subscriber's
’617 Patent
U.S. Patent 8,719,617 Petition for Inter Partes Review
47
TA (and possibly other data) from the HSS.” (Ex. 1003 at 4:10-12, 4:28-31 (“The
TA of the subscriber should be . . . downloaded from the HSS to the S-CSCF
during recovery.”).) As discussed above, the TA, or “care of address,” is “an IP
address associated with a mobile node,” and storing it “ensures that a call made to
the subscriber which arrives at the S-CSCF can finally reach the subscriber.” (Id.,
3:15-17, 3:49-53.) (Ex. 1002, Decl. ¶ 112.)
During restoration, the S-CSCF will also download the user’s “subscription
profile,” i.e., “the subscription data of the user,” which the ’617 patent also calls
the “user profile.” (Ex. 1003, 5:28-31; Ex. 1001, ’617 patent, 11:13-19 (“user
profile” information element is “valued as the subscription data of the user.”); Ex.
1002, Decl. ¶ 113.) Phan-Anh explains that during registration, after the HSS
stores the TA, the S-CSCF “stores the TA and subscription profile and other data
in step 5.” (Ex. 1003, 4:41-43; Fig. 5B, step 5.) TR 23.821 further explains the S-
CSCF obtained the subscription profile by “initiat[ing] the download of the
subscriber profile” from the HSS and the HSS “provid[ing] the serving CSCF with
the requested subscriber profile.” (Ex. 1004 at 51-52, 56-57 (identifying data
stored at the S-CSCF after registration).) When the S-CSCF retrieves the TA of
the user from the HSS during restoration in Phan-Anh, the HSS also send the
subscription profile of the user to the S-CSCF so that the S-CSCF will know how
to process services requests for that user. (Ex. 1003, Fig. 4A, step 3 and 5:7-31
U.S. Patent 8,719,617 Petition for Inter Partes Review
48
(“the S-CSCF has no memory of what mobile stations (MSs) were registered with
the S-CSCF” after a crash and therefore “trigger[s] a profile download”).) In this
manner, the S-CSCF “interrogates and acquires the subscription data of the user
(i.e., the subscription profile) and the restoration data (i.e., the transport address or
TA). (Ex. 1002, Decl. ¶ 113.)
It would have been apparent to a person of ordinary skill in the art that this
same procedure could be used to retrieve the restoration data stored in the HSS
after failure of the original S-CSCF and assignment of a new S-CSCF. Phan-Anh
discloses the checkpointing technique by which restoration data is stored and later
retrieved by an S-CSCF. A person of ordinary skill in the art would have
understood that this procedure, as disclosed in Phan-Anh, could be used to perform
this step, even if a different S-CSCF performed it. (Ex. 1002, Decl. ¶ 114.)
S2-060216 also discloses retrieving data from the HSS to continue
processing. As shown below, the figure in S2-060216 (color added) shows that the
new S-CSCF sends an SAR message to the HSS to “record the new S-CSCF,” and
the HSS returns an SAA message:
U.S. Patent 8,719,617 Petition for Inter Partes Review
49
(Ex. 1005 at 2; Ex. 1001, 13:54-56, Fig. 7(a).) When combined with Phan-Anh,
S2-060216 discloses interrogating and acquiring the restoration data from the HSS.
(Ex. 1002, Decl. ¶ 115.)
To the extent that Patent Owner argues for a narrow construction of the
“restoration data” terms (e.g., requiring that they include a SIP URL of a P-CSCF
assigned for a user device and/or a contact address of the user device), Phan-Anh
discloses this limitation. Phan-Anh expressly incorporates by reference TR
23.821, which (like the prior art described in the ’617 patent) requires that, during
S2‐060216
U.S. Patent 8,719,617 Petition for Inter Partes Review
50
registration, the S-CSCF must “understand a service profile and the address of the
functionality of the proxy CSCF” and store the “[s]ubscriber information and
[p]roxy name/address” after registration. (Ex. 1004 at 27-28, 56-57; Ex. 1001,
2:34-40 (the S-CSCF also stores same data).) A person of ordinary skill in the art
would have understood that the proxy address is a SIP URI. (Ex. 1002, Decl., ¶
116.) In fact, TR 23.821 indicates that the Internet standard SIP had been adopted
for the All-IP network. (Ex. 1004 at 9.) A person of ordinary skill in the art would
have known that this adoption meant that the P-CSCF would be reached by its SIP
URI. (Ex. 1002, Decl. ¶ 116.)
Moreover, it would have been obvious to store this contact information in
the HSS. As Mr. Bishop confirms, a person of ordinary skill in the art attempting
to solve the same purported problem as the ’617 patent would have recognized
that, because this information is stored at the S-CSCF after registration, it is being
used by the S-CSCF and therefore would be needed to restore processing of a user
service request. The most obvious place to safely store this information is the
HSS, which is designed for exactly that purpose. (Ex. 1002, Decl. ¶ 117.)
(d) “receiving the stored data that includes the subscription data of the user and the restoration data”
As discussed above with respect to the “sending” limitation,” Phan-Anh
discloses this limitation.
U.S. Patent 8,719,617 Petition for Inter Partes Review
51
(e) “based on the received data, restoring the service to the user”
Phan-Anh discloses that after the TA has been recovered, “in step 4, the call
is then routed to the subscriber using the recovered TA.” (Ex. 1003, 4:33-34, Fig.
4A.) The transport address (the “restoration data”) will “ensures that a call made
to the subscriber which arrives at the S-CSCF can finally reach the subscriber.”
(Id., 3:51-53.) (Ex. 1002, Decl. ¶ 119.)
S2-060216 also teaches “restoring the user service processing.” After the
new S-CSCF is selected, the “HSS will record the new S-CSCF” and “all
following terminated call will route to that new S-CSCF.” (Ex. 1005 at 2.) (Ex.
1002, Decl. ¶ 120.)
To the extent that Patent Owner argues for a narrow construction of the
“restoration data” terms (e.g., requiring that they include a SIP URL of a P-CSCF
assigned for a user device and a contact address of the user device), the claim is
still obvious in view of this combination for the reasons discussed above in
connection with the “sending a request” limitation above. (Ex. 1002, Decl. ¶ 121.)
5. Claim 5
(a) “A serving call session control function (S-CSCF) for realizing an Internet protocol multimedia subsystem (IMS) disaster tolerance”
This preamble does not limit the claim under the claim’s broadest reasonable
interpretation. To the extent the Board considers the preamble to be limiting, as
U.S. Patent 8,719,617 Petition for Inter Partes Review
52
discussed above in connection with the preamble of claim 1, Phan-Anh discloses a
“serving call session control function (S-CSCF) for realizing an Internet protocol
multimedia subsystem (IMS) disaster tolerance.”
(b) “a receiver, configured to receive a service request of a user forwarded by an interrogating CSCF (I-CSCF) when it is determined that a previous S-CSCF failed in providing a service to the user”
As discussed above in connection with claim 1 (subsection b), Phan-Anh
and S2-060216 disclose “receiv[ing] a service request of a user forwarded by an
interrogating CSCF (I-CSCF) when it is determined that a previous S-CSCF failed
in providing a service to the user.”
The detailed description of the ’617 patent never mentions or explicitly
discloses a “receiver.” Instead, at best, the ’617 patent suggests that S-CSCF must
include a receiver to receive the forwarded user request as depicted in Figures 6(a)-
(d) and 7(a)-(c). As Mr. Bishop explains, and as the patent itself admits, S-CSCFs
were already well known in the art. Mr Bishop explains that a person of ordinary
skill in the art would appreciate that S-CSCFs contained receivers and transmitters
for sending and receiving messages (including the recited messages) and a
processor for handling those requests. (Ex. 1002, Decl. ¶ 124.)
Phan-Anh contains commensurate, if not more, disclosure of the recited
receiver. For example, Figure 5 of Phan-Anh is described as a “signal flow in the
case of a recover after a CSCF crash” and depicts the S-CSCF receiving a “call
U.S. Patent 8,719,617 Petition for Inter Partes Review
53
setup” from the I-CSCF. (Ex. 1003, 2:28-30, Fig. 5.) A person of ordinary skill in
the art would appreciate that an S-CSCF must include a “receiver” configured to
receive signals from the I-CSCF, such as the call setup (i.e., “a service request of a
user”). (Ex. 1002, Decl. ¶ 125.)
(c) “a transmitter, configured to send a request for subscription data of the user and restoration data stored in a storage entity and used for restoring the service that failed to the user, wherein the restoration data is stored by the previous S-CSCF”
As discussed above in connection with claim 1 (subsection c), Phan-Anh and
S2-060216 disclose “send[ing] a request for subscription data of the user and
restoration data stored in a storage entity and used for restoring the service that
failed to the user, wherein the restoration data is stored by the previous S-CSCF.”
The detailed description of the ’617 patent never mentions or explicitly
discloses a “transmitter.” Instead, at best, the ’617 patent suggests that S-CSCF
must include a transmitter to forward user requests as depicted in Figure 2 and to
interrogate the HSS as depicted in Figures 6(a)-(d) and 7(a)-(c). As Mr. Bishop
explains, S-CSCFs were already well known in the art. Mr Bishop explains that a
person of ordinary skill in the art would appreciate that S-CSCFs contained
receivers and transmitters for sending and receiving messages (including the
recited messages) and a processor for handling those requests (i.e., a server is a
processor). (Ex. 1002, Decl. ¶ 127.)
U.S. Patent 8,719,617 Petition for Inter Partes Review
54
Phan-Anh discloses at least as much as the ’617 patent: Figure 5 is a
diagram of a “signal flow” which shows the “call control signaling” between the S-
CSCF and UMS (which is part of the HSS), GGSN and other components. (Ex.
1004, TR 23.821 at 15: Fig 5.2) A person of ordinary in the art would recognize
that the S-CSCF would need a “transmitter” configured to send signals, including
the request for subscription data of the user and restoration data stored in the HSS.
(Ex. 1002, Decl. ¶ 128.)
To the extent that Patent Owner argues for a narrow construction of the
“restoration data” terms (e.g., requiring that they include a SIP URL of a P-CSCF
assigned for a user device and a contact address of the user device), the claim is
still obvious in view of this combination for the reasons discussed above in
connection with the “sending a request” limitation above. (Ex. 1002, Decl. ¶ 129.)
(d) “a processor, configured to restore the service to the user after the subscription data of the user and the restoring data is received by the receiver from the storage entity”
As discussed above in connection with claim 1 (subsection d), Phan-Anh
and S2-060216 disclose “restor[ing] the service to the user after the subscription
data of the user and the restoring data is received by the receiver from the storage
entity.”
The detailed description of the ’617 patent never mentions or explicitly
discloses a “receiver.” Instead, at best, the ’617 patent suggests that S-CSCF must
U.S. Patent 8,719,617 Petition for Inter Partes Review
55
include a processor to process the service requests (such as call setup request) as
depicted in Figures 6(a)-(d) and 7(a)-(c). As Mr. Bishop explains, S-CSCFs were
already well known in the art. Mr Bishop explains that a person of ordinary skill in
the art would appreciate that S-CSCFs contained receivers and transmitters for
sending and receiving messages (including the recited messages) and a processor
for handling those requests. (Ex. 1002, Decl. ¶ 131.)
Phan-Anh discloses at least as much of this limitation in the specification as
the ’617 patent discloses. Phan-Anh claims “[a] non-transitory program storage
device readable by a machine, non-transmissible, tangibly embodying a program
of instructions executable by the machine”—i.e., a programmed computer—to
restore the transport address in response to a loss of the TA by the S-CSCF. (Ex.
1003, 6:62-7:6.) A person of ordinary skill in the art would recognize from this
disclosure that the S-CSCF “machine” (i.e., a computer) would have a “processor”
configured to perform the restoration. (Ex. 1002, Decl. ¶ 132.)
To the extent that Patent Owner argues for a narrow construction of the
“restoration data” terms (e.g., requiring that they include a SIP URL of a P-CSCF
assigned for a user device and a contact address of the user device), the claim is
still obvious in view of this combination for the reasons discussed above in
connection with the “sending a request” limitation above. (Ex. 1002, Decl. ¶ 133.)
U.S. Patent 8,719,617 Petition for Inter Partes Review
56
6. Claim 7
(a) “In a serving call session control function (S-CSCF), a computer program product comprising computer executable instructions stored on a non-transitory computer readable medium such that when executed by a computer program processor cause the S-CSCF to perform a method for realizing an Internet protocol multimedia subsystem (IMS) disaster tolerance by the following:”
This preamble does not limit the claim under the claim’s broadest reasonable
interpretation. To the extent the Board considers the preamble to be limiting, as
discussed above in connection with the preamble of claim 1, Phan-Anh discloses
this limitation.
As discussed above in connection with the preamble of claim 1, Phan-Anh
and S2-060216 disclose a “serving call session control function (S-CSCF) for
realizing an Internet protocol multimedia subsystem (IMS) disaster tolerance.”
Phan-Anh also discloses that the S-CSCF can be implemented in “[a] non-
transitory program storage device readable by a machine”—i.e., a “computer
readable medium”—and “a program of instructions executable by the machine”—
i.e.” “computer executable instructions.” (Ex. 1003, 6:42-7:6.) For example, as
explained above in connection with claim element 5(d), a person of ordinary skill
in the art would recognize that a S-CSCF was a SIP server that would include a
processor and memory and as such was a “machine” (i.e., a computer) that would
have a “processor” for executing the instructions, and that those instructions would
U.S. Patent 8,719,617 Petition for Inter Partes Review
57
be stored on a non-transitory medium (the server’s memory system). (Ex. 1002,
Decl. ¶ 135.)
(b) “receive a service request of a user forwarded by an interrogating CSCF (I-CSCF) when it is determined that a previous S-CSCF failed in providing a service to the user”
As discussed above in connection with claim 1(b), Phan Anh performs this
step, and as discussed in connection with claim 5, a person of ordinary skill in the
art would approved that this step is performed by a processor executing stored
instructions. (See Ex. 1003, 6:42-7:5.) (Ex. 1002, Decl., ¶ 136.)
(c) “send a request for subscription data of the user and restoration data stored in a storage entity and used for restoring the service that failed to the user, wherein the restoration data is stored by the previous S-CSCF”
As discussed above in connection with claim 1(b), Phan Anh performs this
step, and as discussed in connection with claim 5, a person of ordinary skill in the
art would approved that this step is performed by a processor executing stored
instructions. (See Ex. 1003, 6:42-7:5.) (Ex. 1002, Decl. ¶ 137.)
To the extent that Patent Owner argues for a narrow construction of the
“restoration data” terms (e.g., requiring that they include a SIP URL of a P-CSCF
assigned for a user device and a contact address of the user device), the claim is
still obvious in view of this combination for the reasons discussed above in
connection with the “sending a request” limitation above. (Ex. 1002, Decl. ¶¶
U.S. Patent 8,719,617 Petition for Inter Partes Review
58
138.)
(d) “receive the stored data that includes the subscription data of the user and the restoration data”
As discussed above in connection with claim 1(b), Phan Anh performs this
step, and as discussed in connection with claim 5, a person of ordinary skill in the
art would appreciate that this step is performed by a processor executing stored
instructions. (See Ex. 1003, 6:42-7:5.) (Ex. 1002, Decl. ¶ 139.)
To the extent that Patent Owner argues for a narrow construction of the
“restoration data” terms (e.g., requiring that they include a SIP URL of a P-CSCF
assigned for a user device and a contact address of the user device), the claim is
still obvious in view of this combination for the reasons discussed above in
connection with the “sending a request” limitation above. (Ex. 1002, Decl. ¶ 140.)
(e) based on the received data, restore the service to the user
As discussed above in connection with claim 1(b), Phan Anh performs this
step, and as discussed in connection with claim 5, a person of ordinary skill in the
art would approved that this step is performed by a processor executing stored
instructions. (See Ex. 1003, 6:42-7:5.) (Ex. 1002, Decl. ¶ 141.)
7. Reasons to Combine Phan-Anh and S2-060216
As Mr. Bishop explains, one of ordinary skill in the art would readily
recognize the benefits of incorporating the teachings of S2-060216 into the
solution described in Phan-Anh. S2-060216 is directed to an IMS procedure in
U.S. Patent 8,719,617 Petition for Inter Partes Review
59
which a new S-CSCF is assigned to a user when the original S-CSCF fails during a
call setup, and one of ordinary skill in the art would assume that the user profile is
retrieved by the S-CSCF to continue service processing after the assignment.
Phan-Anh was intended to be implemented in the All-IP network, which was
realized by IMS and, like the ’617 patent, describes a standard checkpointing
technique in which data needed to restore a user service is stored during
registration and retrieved when the S-CSCF fails and restarts during a call setup.
Both Phan-Anh and S2-060216 describe these procedures in the same context:
mobile termination. It would have been a simple matter to a person of ordinary
skill in the art to incorporate the re-assignment procedure in S2-060216 into Phan-
Anh to achieve a solution that covered both S-CSCF failure/restart and S-CSCF
failure/re-assignment. (Ex. 1002, Decl. ¶ 142.)
A person of ordinary skill in the art also would have been motivated to make
such a combination because S2-060216 describes how requests are made to and
returned from the HSS using the SAR/SAA messages already known in IMS, and
would appreciate that the SAA would include requested data to be returned to the
S-CSCF. Phan-Anh was filed years before S2-060216 was submitted, and was to
be implemented in the All-IP network—an early incarnation of IMS which also
uses CSCFs and HSS and the same functionality as IMS—before the interface
messages (including SAR/SAA) had been specified by 3GPP. By the time S2-
U.S. Patent 8,719,617 Petition for Inter Partes Review
60
060216 was published, the messages were specified in TS 23.228 and TS 29.228,
and a person of ordinary skill in the seeking to incorporate the procedure of S2-
060216 into Phan-Anh would have known to use those messages. (Ex. 1002, Decl.
¶ 143.)
Finally, there is evidence of “simultaneous invention”: Nokia Siemens filed
a European patent application covering the same subject matter as the ’617 patent
application on the same day (October 24, 2006) that Huawei filed its earliest
Chinese priority application. The Examiner rejected 25 of the 28 claims in the
’365 patent application (to which the ’617 patent claims priority) as anticipated by
that application, confirming that the rejected claims read on the subject matter of
the Nokia Siemens application. Although the Examiner eventually allowed the
claims because the Nokia Siemens application was not published early enough to
be prior art, this evidence of simultaneous invention is a strong indication of
obviousness. (Ex. 1002, Decl. ¶ 144.) See Ecolochem, Inc. v. Southern California
Edison Co., 227 F.3d 1361, 1379 (Fed. Cir. 2000) (“[T]he possibility of near
simultaneous invention by two or more equally talented inventors working
independently . . . may . . . be an indication of obviousness when considered in
light of all the circumstances.”)
C. Ground 2: Claims 1, 4, 5, 7, and 10 Are Invalid As Obvious Over Phan-Anh Combination With S2-060216 and TS 23.228
As discussed above, claims 1, 5, and 7 are invalid as obvious over the
U.S. Patent 8,719,617 Petition for Inter Partes Review
61
combination of Phan-Anh and S2-060216. If, however, the Patent Owner argues
for a narrow construction of the “restoration data” terms that includes the SIP URL
of the P-CSCF and a contact address of the user—the same limitations found in
dependent claims 4 and 10—all of the challenged claims are invalid as obvious
over the combination of Phan-Anh and S2-060216 in light of TS 23.228
1. Claims 1, 5, and 7
To the extent that Patent Owner argues for a narrow construction of the
“restoration data” terms (e.g., requiring that they include a SIP URL of a P-CSCF
assigned for a user device and a contact address of the user device), the claim is
still obvious over the combination of Phan-Anh and S2-060216 for all the reasons
discussed in Ground 1, and in view of TS 23.228. TS 23.228 specifies IMS and
explains that the CSCF nodes in IMS (including the P-CSCF) “shall be identifiable
using a valid SIP URI,” and that the SIP URIs would be used when identifying
these nodes in header fields of SIP messages.” (Ex. 1007 at 28.) In addition,
according to TS 23.228, “each registration and each de-registration process always
relates to a particular contact address.” (Id. at 41.)
A person of ordinary skill in the art at the time of the invention would have
been well versed in this means of identifying CSCFs and users. Such a person
seeking to solve the same problem as the ’617 patent would appreciate that Phan-
Anh was written at a time when IMS was in its infancy and so did not reflect the
U.S. Patent 8,719,617 Petition for Inter Partes Review
62
latest version of the IMS standard. Such a person would have looked to the IMS
standard in TS23.228 at the time of the priority date of the ’617 patent—five years
after Phan-Ahn was filed—to determine how the standard had changed since Phan-
Anh was filed and to see how the invention in Phan-Anh might be updated to be
applicable to the modern system. By the time of the priority date of the ’617 patent
(five years later), this architecture had evolved into the fully-specified architecture
of IMS and the interactions between its entities described in TS 23.228. Therefore,
a person of ordinary skill in the art would have looked to TS 23.228 to understand
how the P-CSCF and user must be addressed. (Ex. 1002, ¶ 147.)
2. Claims 4 and 10
(a) “the restoration data includes a session initiation protocol (SIP) URL of a proxy CSCF (P-CSCF) assigned for the user to enter the IMS subsystem and a contact address of the user”
These limitations are disclosed in TS 23.228 and render claims 4 and 10
invalid as obvious for the same reasons discussed above in connection with claims
1, 5, and 7. (Ex. 1002, ¶ 148.)
D. Ground 3: Claims 1, 4, 5, 7, and 10 Are Invalid As Obvious Over Phan-Anh In View of TR 23.821, S2-060216 and TS 23.228
To the extent Patent Owner argues that TR 23.821 is not part of Phan-Anh,
which would be incorrect, it nevertheless would have been obvious to combine the
two. Phan-Anh incorporates TR 23.821 by reference in its entirety, and the
U.S. Patent 8,719,617 Petition for Inter Partes Review
63
solution described in Phan-Anh addresses a shortcoming of the All-IP network.
(Ex. 1003, 1:26-18 (“Unfortunately, the network disclosed in the Technical Report
fails to include any protection of the TA of a 3G AII-IP subscriber from loss.”).) A
person of ordinary skill in the art would have looked to TR 23.821 to understand
the context and details for implementation of the solution described in Phan-Anh.
For example, Phan-Anh explains that during registration, after the HSS stores the
TA, the S-CSCF “stores the TA and subscription profile and other data in step 5.”
(Ex. 1003, 4:41-43; Fig. 5B, step 5.) TR 23.821 further explains the S-CSCF
obtained the subscription profile by “initiat[ing] the download of the subscriber
profile” from the HSS and the HSS “provid[ing] the serving CSCF with the
requested subscriber profile.” (Ex. 1004 at 51-52, 56-57 (identifying data stored at
the S-CSCF after registration).) A person of ordinary skill in the art would have
known that these steps described in TR 23.821 could also be used to download the
TA and subscriber profile (i.e., “restoration data” and “subscription data of the
user”). (Ex. 1002, ¶¶ 149-150.)
U.S. Patent 8,719,617 Petition for Inter Partes Review
64
VIII. CONCLUSION
Based on the foregoing, Petitioners request institution of an inter partes
review to cancel the challenged claims.
Respectfully Submitted,
__/Peter M. Dichiara/_______
Peter M. Dichiara
Registration No. 38,005
U.S. Patent 8,719,617 Petition for Inter Partes Review
65
TABLE OF EXHIBITS
Exhibit Description
1001 U.S. Patent No. 8,719,617 (“’617 patent”)
1002 Declaration of Craig Bishop (“Decl.”), with Appendix A
1003 U.S. Patent No. 7,769,374 (“Phan-Anh”)
1004 Excerpts from 3GPP Technical Report 23.821 v1.0.1 (July 2000), 3rd Generation Partnership Project, Architecture Principles for Release 2000 (“TR 23.821”).
1005 S2-060216, Reassignment for S-CSCF during the terminated call procedure, Huawei, 3GPP TSG SA WG2 #50, January 16-20, 2006 (“S2-060216”)
1006 ’617 File History, 6/17/2013 Office Action
1007 Excerpts from 3GPP Technical Specification 23.228 v7.2.0 (December 2005), IP Multimedia Subsystem (IMS); Stage 2 (“TS 23.228”)
1008 SP-000289, Revised WI on An architecture for Call control and roaming to support IP-based multimedia services in UMTS, 3GPP TSG WG SA #8, June 26-28, 2000 (“SP-000289”)
1009 Printout from http://lteuniversity.com/get_trained/expert_opinion1/b/lpatterson/archive/2013/06/12/cscf-in-volte-the-p-cscf-part-1-of-4.aspx
1010 Excerpts from 3GPP Technical Specification 29.228 v7.0.0 (December 2005), IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and message contents (“TS 29.228”)
1011 ’365 File History, EP 1916821 A1 (“Leis”)
1012 Joint Construction Statement, Exhibits A and B, Docket No. 110-1 in Huawei Technologies Co. Ltd. v. T-Mobile US, Inc. et al., Case No. 2:16-cv-00052-JRG-RSP
1013 Siewiorek and Swarz, “The Theory and Practice of Reliable System Design” Digital Press, pp. 170-71 (1982)
U.S. Patent 8,719,617 Petition for Inter Partes Review
66
Exhibit Description
1014 U.S. Patent No. 6,108,300 (“’300 patent”)
1015 U.S. Patent No. 6,885,861 (“’861 patent”)
1016 U.S. Patent No. 6,963,996 (“’996 patent”)
1017 U.S. Patent No. 6,408,182 (“’182 patent”)
1018 S2-022876, Re-assignment of S-CSCF, Ericsson, 3GPP TSG SA WG2 #27, October 14-18, 2002 (“S2-022876”)
1019 3GPP News
1020 3GPP FAQs, dated 8/3/2016
1021 Printout of 3GPP FTP site for 23.821, http://www.3gpp.org/ftp/Specs/archive/23_series/23.821/
1022 Printout of TSGS2#50 3GPP FTP site, http://www.3gpp.org/ftp/tsg_sa/wg2_arch/TSGS2_50_Budapest/Docs/
1023 Printout of 3GPP FTP site for 23.228, http://www.3gpp.org/ftp/Specs/archive/23_series/23.228/
1024 Printout of TSGS#8 3GPP FTP site, http://www.3gpp.org/ftp/tsg_sa/tsg_sa/TSGS_08/Docs/ZIP/
1025 Printout of 3GPP FTP site for 29.228, http://www.3gpp.org/ftp/Specs/archive/29_series/29.228/
1026 Printout of TSGS2#27 3GPP FTP site, http://www.3gpp.org/ftp/tsg_sa/wg2_arch/TSGS2_27/tdocs/set_02/
1027 ’617 File History, 11/18/2013 Reply to Office Action
1028 ’617 File History, 12/31/2013 Office Action
1029 ’617 File History, 1/29/2014 Terminal Disclaimer
1030 S2-012330, Change Request, Correction on CSCF discovery to align with 23.228, 3GPP TSG SA WG2 #19, August 27-31, 2001 (“S2-021330”)
U.S. Patent 8,719,617 Petition for Inter Partes Review
67
Exhibit Description
1031 Printout of TSGS2#19 3GPP FTP site, http://www.3gpp.org/ftp/tsg_sa/wg2_arch/TSGS2_19/tdocs/
U.S. Patent 8,719,617 Petition for Inter Partes Review
i
CERTIFICATE OF COMPLIANCE
I hereby certify that the foregoing, Petition for Inter Partes Review, contains
11,924 words as measured by the word processing software used to prepare the
document, in compliance with 37 C.F.R. § 42.24 (d).
Respectfully submitted,
Dated: January 20, 2017 /Arthur C. H. Shum/ Arthur C. H. Shum Reg. No. 74,973
U.S. Patent 8,719,617 Petition for Inter Partes Review
ii
CERTIFICATE OF SERVICE
I hereby certify that on January 20, 2017, I caused a true and correct copy of the following materials
Petition for Inter Partes Review of U.S. Patent No. 8,719,617
Exhibits 1001-1031
List of Exhibits
Fee Authorization
Certificate of Compliance
T-Mobile US, Inc. Power of Attorney and
T-Mobile USA, Inc. Power of Attorney
to be served via Federal Express on the following correspondence address of record as listed on PAIR:
Leydig, Voit & Mayer, Ltd. (for Huawei Technologies Co., Ltd)
Two Prudential Plaza Suite 4900 180 North Stetson Avenue
Chicago IL 60601 Respectfully submitted, /Arthur C. H. Shum/ Arthur C. H. Shum Reg. No. 74,973