INTER PARTES - Microsoft · PDF fileHuawei Technologies Co. Ltd. Patent Owner Case IPR2017-00697 ... service in an IP multimedia subsystem (IMS) when a particular server in that system

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


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


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)


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:


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.)


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.


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:


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


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


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):


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


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,


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


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,


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


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:


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.


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:


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-


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


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


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.)


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.)


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.


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.)


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


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.


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.


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


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.)


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


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):


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


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”:


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


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):


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


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


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


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


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,


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


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”:


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


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


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


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


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


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


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:


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


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.


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.)



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”


interpretation. To the extent the Board considers the preamble to be limiting, as


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


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.”


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.)


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.)






(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.”


discloses a “receiver.” Instead, at best, the ’617 patent suggests that S-CSCF must


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.)







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:”


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


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”




instructions. (See Ex. 1003, 6:42-7:5.) (Ex. 1002, Decl. ¶ 137.)





connection with the “sending a request” limitation above. (Ex. 1002, Decl. ¶¶


58

138.)

(d) “receive the stored data that includes the subscription data of the user and the restoration data”



art would appreciate that this step is performed by a processor executing stored







(e) based on the received data, restore the service to the user





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


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-


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


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




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


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


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.)


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


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)


66

Exhibit Description





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/


1024 Printout of TSGS#8 3GPP FTP site, http://www.3gpp.org/ftp/tsg_sa/tsg_sa/TSGS_08/Docs/ZIP/


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”)


67

Exhibit Description

1031 Printout of TSGS2#19 3GPP FTP site, http://www.3gpp.org/ftp/tsg_sa/wg2_arch/TSGS2_19/tdocs/


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


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