UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.,
`Petitioner
`
`v.
`
`UNILOC 2017 LLC,
`Patent Owner
`
`U.S. Patent No. 7,969,925
`Filing Date: July 8, 2010
`Issue Date: June 28, 2011
`Title: Peer-to-Peer Mobile Data Transfer Method and Device
`
`Inter Partes Review No.: IPR2019-00702
`
`PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 7,969,925
`UNDER 35 U.S.C. §§ 311-319 AND 37 C.F.R. §§ 42.1-100, ET SEQ.
`
`

`

`TABLE OF CONTENTS
`
`Page
`
`I.
`II.
`
`Introduction ..................................................................................................... 1
`Compliance with Formal Requirements ......................................................... 1
`A. Mandatory Notices Under 37 C.F.R. §§ 42.8(b)(1)-(4) ....................... 1
`B.
`Proof of Service on the Patent Owner .................................................. 2
`C.
`Power of Attorney ................................................................................ 3
`D.
`Standing ................................................................................................ 3
`E.
`Fees ....................................................................................................... 3
`III. Statement of Precise Relief Requested ........................................................... 3
`A.
`Prior Art ................................................................................................ 3
`B. Grounds ................................................................................................ 6
`IV. This Petition is Proper Under 35 U.S.C. §§ 314(a) and 325(d) ..................... 7
`V.
`Full Statement of Reasons for Requested Relief ............................................ 7
`A.
`Summary of the 925 Patent .................................................................. 7
`B.
`Claims of the 925 Patent ...................................................................... 7
`C.
`Person of Ordinary Skill in the Art ...................................................... 9
`D.
`Claim Construction Under 37 C.F.R. § 42.104(b)(3) ........................19
`VI. Ground 1: The Combination of Alos and RFC793 Renders Obvious
`Claims 1, 3-8, 10-15 and 17-20 ....................................................................23
`A. Alos Overview ....................................................................................23
`B.
`RFC793 Overview ..............................................................................26
`C.
`Rationale for Combining Alos and RFC793 ......................................26
`D. Detailed Claim Analysis .....................................................................29
`VII. Ground 2: The Combination of Alos, RFC793, WMA and the SMS
`Specification Renders Claims 2, 9 and 16 Obvious .....................................35
`A.
`SMS Specification Overview .............................................................35
`B. WMA Overview .................................................................................36
`C.
`Rationale for Combining Alos, RFC793, the SMS Specification
`and WMA ...........................................................................................36
`
`i
`
`

`

`TABLE OF CONTENTS
`(continued)
`
`Page
`
`D. Detailed Claim Analysis .....................................................................38
`VIII. Ground 3: The Combination of Cordenier and RFC793 Renders
`Obvious Claims 1, 3-8, 10-15 and 17-20 .....................................................41
`A.
`Cordenier Overview ...........................................................................41
`B.
`Rationale for Combining Cordenier and RFC793 .............................43
`C. Detailed Claim Analysis .....................................................................45
`IX. Ground 4: The Combination of Cordenier, RFC793 and Dorenbosch
`Renders Claims 2, 9 and 16 Obvious ...........................................................51
`A. Overview of Dorenbosch ...................................................................51
`B.
`Rationale for Combining Cordenier, RFC793 and Dorenbosch ........52
`C. Detailed Claim Analysis .....................................................................53
`X. Ground 5: The Combination of Lee, RFC793, and the SMS
`Specification Renders Obvious Claims 1, 3-8, 10-15 and 17-20 .................55
`A.
`Lee Overview .....................................................................................55
`B.
`Rationale for Combining Lee, RFC793, and the SMS
`Specification .......................................................................................57
`C. Detailed Claim Analysis .....................................................................58
`XI. Ground 6: The Combination of Lee, RFC793, the SMS Specification
`and WMA Renders Claims 2, 9 and 16 Obvious .........................................65
`A.
`Rationale for Combining Lee, RFC793, the SMS Specification
`and WMA ...........................................................................................65
`B. Detailed Claim Analysis .....................................................................65
`XII. Conclusion ....................................................................................................68
`
`ii
`
`

`

`Exhibit No.
`1001
`1002
`1003
`1004
`1005
`
`1006
`1007
`1008
`1009
`
`1010
`
`1011
`1012
`1013
`
`1014
`
`EXHIBIT LIST
`
`Description
`U.S. Patent No. 7,969,925 to Lin (“925 patent”)
`Declaration of Dr. Henry Houh
`File History of U.S. Pat. No. 7,969,925 to Lin
`File History of U.S. Pat. No. 7,961,663 to Lin
`Certified Translation and Original of European Pat. App. Pub. EP
`1 009 153 A1 (“Alos”)
`U.S. Pat. No. 6,847,632 (“Lee”)
`European Pat. App. Pub. EP 1 385 323 A1 (“Cordenier”)
`Complaint for Patent Infringement (“Uniloc Complaint”)
`Declaration of Sandy Ginoza for IETF RFC 1122: Requirements
`for Internet Hosts - Communication Layers with the exhibit
`RFC 1122, “Requirements for Internet Hosts - Communication
`Layers” (“RFC1122”)
`Declaration of Sandy Ginoza for IETF RFC 793: Transmission
`Control Protocol with the exhibit, RFC 793, “Transmission
`Control Protocol” (“RFC793”)
`U.S. Pat. App. Pub. No. 2003/0217174 (“Dorenbosch”)
`U.S. Patent No. 5,163,131 (“Row”)
`W. Richard Stevens, “Unix Network Programming,” Chapters 1,
`“Introduction”; 4, “A Network Primer”; 5, “Communication
`Protocols”; and, 6, “Berkeley Sockets”
`Information Disclose Statement Under 37 C.F.R. §§ 1.97 and 1.98
`that includes “Universal Mobile Telecommunications System
`(UMTS); Technical realization of the Short Message Service
`(SMS) (3G TS 23.040 version 3.5.0 Release 1999)” and was
`submitted August 15, 2002, concurrently with U.S. Pat. App.
`10/218,580, which application was published on February 27,
`2003, as U.S. Pat. App. Pub. 2003/0040300 A1 (“SMS
`Specification”)
`
`i
`
`

`

`Exhibit No.
`1015
`
`1016
`1017
`1018
`
`1019
`1020
`1021
`
`1022
`
`1023
`1024
`
`1025
`1026
`
`1027
`
`Description
`W. Richard Stevens, TCP/IP ILLUSTRATED, VOLUME 2: THE
`PROTOCOLS (1994)
`U.S. Pat. No. 8,018,877 to Lin
`U.S. Pat. Pub. No. 2005/0278448 to Mazor (“Mazor”)
`Declaration of Harold Ogle Regarding JSR-000120, “Wireless
`Messaging API (WMA) for JavaTM 2 Micro Edition Version
`1.0” with the exhibit JSR 120, “Wireless Messaging API
`(WMA) for Java™ 2 Micro Edition Version 1.0” (“WMA”)
`IBM Dictionary of Computing, 10th Ed. (1993)
`Newton’s Telecom Dictionary, 11th Ed. (1996)
`Declaration of Sandy Ginoza for IETF RFC 2543: SIP: Session
`Initiation Protocol with the exhibit RFC 2543, “SIP: Session
`Initiation Protocol” (“RFC2543”)
`Declaration of Sandy Ginoza for IETF RFC 791: Internet
`Protocol with the exhibit RFC 791, “Internet Protocol”
`U.S. Pat. Pub. No. 2003/0040300
`Declaration of Sandy Ginoza for IETF RFC 2026: The Internet
`Standards Process – Revision 3 with the exhibit, RFC 2026:
`“The Internet Standards Process – Revision 3” (“Internet
`Standards Process”)
`U.S. Pat. No. 7,181,231
`Declaration of Mr. Craig Bishop regarding ETSI TS 123 040
`V3.5.0, “Universal Mobile Telecommunications System
`(UMTS); Technical Realization of the Short Message Service
`(SMS) (3GPP TS 23.040 version 3.50 Release 1999) with
`appendices A-D
`Declaration of Sandy Ginoza for IETF RFC 768: User Datagram
`Protocol with the exhibit, RFC768: User Datagram Protocol
`
`ii
`
`

`

`I.
`
`INTRODUCTION
`Apple Inc. (“Apple” or “Petitioner”) hereby petitions for inter partes review
`
`of U.S. Patent No. 7,969,925 (Ex. 1001, “925 patent”). The 925 patent describes a
`
`technique for using an SMS invitation message to establish a peer-to-peer IP-based
`
`connection between two devices. The same technique is disclosed in each of the
`
`three primary prior art references presented in this Petition. The secondary
`
`references disclose well-known implementation details for network
`
`communications; specifically, the use of ports (e.g., to define a socket) and the use
`
`of TCP (e.g., for TCP/IP communications). In fact, these implementation details
`
`were taught by the same standards that defined the network communication
`
`protocols taught in the primary references, rendering the challenged claims
`
`obvious.
`
`II.
`
`COMPLIANCE WITH FORMAL REQUIREMENTS
`A. Mandatory Notices Under 37 C.F.R. §§ 42.8(b)(1)-(4)
`1.
`Real Party-In-Interest
`Apple is the real party-in-interest.
`
`Related Matters
`2.
`According to the assignment records at the USPTO, the 925 patent is
`
`currently owned by Uniloc 2017 LLC (“Uniloc”). The 925 patent was asserted
`
`against Apple by Uniloc Luxembourg S.A. and Uniloc USA, Inc. in Uniloc USA,
`
`1
`
`

`

`Inc., et al. v. Apple Inc., Case No. 1:18-cv-00166-LY (W.D. Tex.) (“the Related
`
`Litigation”), in a complaint filed on February 22, 2018. Ex. 1008.
`
`Petitioner is contemporaneously filing IPR2019-00700 and IPR 2019-00701
`
`on related U.S. Patent Nos. 8,406,116 and 8,018,877, respectively, which involve
`
`many of the same issues addressed herein. Uniloc has asserted each of the above
`
`patents in the Related Litigation.
`
`Lead and Backup Counsel
`3.
`Lead counsel is Brian Erickson Reg. No. 48,895, of DLA Piper LLP (US),
`
`401 Congress Avenue, Suite 2500, Austin, TX 78701;
`
`brian.erickson@dlapiper.com, 512-457-7059 (phone), 512-457-7001 (fax).
`
`Backup counsel is James M. Heintz, Reg. No. 41,828, of DLA Piper LLP
`
`(US), 11911 Freedom Drive, Suite 300; Reston, VA 20190;
`
`jim.heintz@dlapiper.com, 703-773-4148 (phone), 703-773-5200 (fax).
`
`Service Information
`4.
`Service information for lead and back-up counsel is provided in the
`
`designation of lead and back-up counsel above. Apple consents to electronic
`
`service to lead and back-up counsel and to Apple-Uniloc-IPR@dlapiper.com.
`
`Proof of Service on the Patent Owner
`B.
`As identified in the attached Certificate of Service, a copy of this Petition
`
`and supporting evidence is being served electronically by agreement of the parties
`
`and pursuant to 37 C.F.R. §§ 42.6&42.105(b).
`
`2
`
`

`

`Power of Attorney
`C.
`Powers of attorney are being filed with designation of counsel in accordance
`
`with 37 C.F.R. § 42.10(b).
`
`Standing
`D.
`In accordance with 37 C.F.R. §42.104(a), Petitioner certifies that the 925
`
`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.
`
`Fees
`E.
`The undersigned authorizes the Director to charge the fee specified by 37
`
`C.F.R. § 42.15(a) and any additional fees that might be due in connection with this
`
`Petition to Deposit Account No. 50-3266.
`
`III.
`
`STATEMENT OF PRECISE RELIEF REQUESTED
`A.
`Prior Art
`The following references are pertinent to the grounds of unpatentability
`
`under Title 35 United States Code, pre-AIA:
`
` “Alos” (Ex. 1005) – EP 1 099 153 A1, published on June 14, 2000, is
`
`prior art under Section 102(b).
`
` “Cordenier” (Ex. 1007) – EP 1 385 323 A1, published on January 28,
`
`2004, is prior art under Section 102(a).
`
`3
`
`

`

` “Lee” (Ex. 1006) – U.S. 6,847,632, issued from an application filed
`
`on December 22, 1998, is prior art under Section 102(e).
`
` “RFC793” (Ex. 1010) – Request for Comment 793, published no later
`
`than 1992, is prior art under Section 102(b). As explained by Sandy
`
`Ginoza, RFC793 was indexed and published on a publicly available
`
`website and repository making it available and accessible to any
`
`interested person no later than October 1992. Ex. 1010 at 1-3
`
`(original publication date of September 1981). As explained by Dr.
`
`Houh, anyone, including a POSITA, would have had access to, and
`
`would have been able to locate RFC793 no later than October 1992.
`
`Ex. 1002 ¶55; see also Ex. 1024 at 10-11. Indeed, the purpose of
`
`publishing Requests for Comments was to publicly solicit input from
`
`POSITAs for the standards setting processes. Id. RFC793 was in fact
`
`available and located by POSITAs, as established by its citation in
`
`contemporaneous documents. Ex. 1012 at 6:40-43 (U.S. Patent issued
`
`in 1992 and incorporating RFC793 by reference).
`
` “SMS Specification” (Ex. 1014) – SMS Specification, published no
`
`later than August 15, 2002, is prior art under Section 102(b). As
`
`explained at length by Craig Bishop, both ETSI and 3GPP published
`
`the SMS Specification as part of their standards setting processes. Ex.
`
`4
`
`

`

`1026 ¶¶ 1-34 and Appendices A-D (detailing the development and
`
`publication of the SMS Specification by ETSI and 3GPP). Mr.
`
`Bishop attended the meeting where the SMS Specification was
`
`“frozen” and explains in detail how interested persons could locate the
`
`publication. Id. at ¶20 (meeting and archive.org confirmation), ¶¶22-
`
`30 (access). Additionally, the SMS Specification was published no
`
`later than February 27, 2003, the publication date of U.S. App.
`
`10/218,580 and its file history. Ex. 1014 at 1-6 (IDS dated August 15,
`
`2002); Ex. 1023 (U.S. Pat. App. Pub. 2003/0040300) at [0002]-[0013]
`
`(describing and pointing a POSITA to the SMS Specification, a copy
`
`of which was in the publicly available file history); Ex. 1025 (U.S.
`
`Pat. No. 7,181,231) at 1:21-2:45 (same). Ex. 1002 ¶56 (explaining
`
`how a POSITA would have been aware of and able to locate the SMS
`
`Specification from the relevant standards bodies).
`
` “WMA” (Ex 1018) – WMA, published no later than August 21, 2002,
`
`is prior art under Section 102(b). As explained by Harold Ogle,
`
`WMA was indexed and published by the Java developers website no
`
`later than August 21, 2002. Ex. 1018 at 1-2, 6; Ex. 1002 ¶57
`
`(explaining how a POSITA would have been able to locate WMA).
`
`5
`
`

`

` “Dorenbosch” (Ex 1011) – U.S. 2003/0217174, filed on May 15,
`
`2002 and published on November 20, 2003, is prior art under Sections
`
`102(a) and (e).
`
`B.
`
`Grounds
`
`This Petition, supported by the declaration of Dr. Henry Houh (“Houh
`
`Declaration”) (Ex. 1002), requests cancellation of claims 1-20 of the 925 patent on
`
`the following grounds under Title 35, United States Code pre-AIA:
`
` Ground 1: Claims 1, 3-8, 10-15, 17-20 are invalid under Section 103
`
`over the combination of Alos and RFC793
`
` Ground 2: Claims 2, 9 and 16 are invalid under Section 103 over the
`
`combination of Alos, RFC793, SMS Specification and WMA
`
` Ground 3: Claims 1, 3-8, 10-15, 17-20 are invalid under Section 103
`
`over the combination of Cordenier and RFC 793
`
` Ground 4: Claims 2, 9 and 16 are invalid under Section 103 over the
`
`combination of Cordenier, RFC793 and Dorenbosch
`
` Ground 5: Claims 1, 3-8, 10-15, 17-20 are invalid under Section 103
`
`over the combination of Lee, RFC793 and SMS Specification
`
` Ground 6: Claims 2, 9 and 16 are invalid under Section 103 over the
`
`combination of Lee, RFC793, SMS Specification and WMA
`
`6
`
`

`

`IV. THIS PETITION IS PROPER UNDER 35 U.S.C. §§ 314(A)
`AND 325(D)
`None of Alos, Lee, Cordenier, RFC793, SMS Specification, Dorenbosch or
`
`WMA were considered during prosecution or any post-grant proceeding of the 925
`
`patent, and they are not cumulative of any references of record.
`
`V.
`
`FULL STATEMENT OF REASONS FOR REQUESTED RELIEF
`A.
`Summary of the 925 Patent
`The 925 patent describes a technique for transferring data between mobile
`
`devices that does not require a server. Ex. 1001 at 1:61-67. With this technique, a
`
`first mobile device sends an SMS invitation message that includes its IP address to
`
`a second mobile device, and the second mobile device responds by initiating a
`
`TCP/IP connection to the first mobile device’s IP address. Fig. 2, Ex. 1001 at
`
`4:23-35; Ex. 1002 ¶32.
`
`Claims of the 925 Patent
`B.
`Claim 1 tracks the disclosed technique by claiming (1.pre) a method of
`
`establishing a data connection comprising (1.a) opening a listening software port,
`
`(1.b) transmitting an invitation via page-mode messaging (e.g., SMS), (1.c)
`
`receiving a response at the software port, and (1.d) establishing a peer-to-peer data
`
`transfer session. Ex. 1002 ¶33. These steps are highlighted in annotated Figure 2
`
`below.
`
`7
`
`

`

`Challenged claim 2 recites that the initiating mobile device receives similar
`
`invitations from “another” mobile device through the page-mode messaging
`
`service and transmits a response thereto. Challenged claim 3 specifies the type of
`
`address (IP), claims 4-5 specify the type of page-mode messaging service (SMS
`
`8
`
`

`

`and PIN-to-PIN, respectively), claim 6 specifies the type of unique ID used by the
`
`service (telephone number), and claim 7 specifies the type of data session (TCP).
`
`Ex. 1002 ¶34.
`
`Challenged claims 8-14 (mobile device) and claims 15-20 (Beauregard)
`
`parallel claims 1-7. Id.
`
`Person of Ordinary Skill in the Art
`C.
`A person of ordinary skill in the art at the time of the alleged invention of
`
`the 925 patent (a “POSITA”) would have had a Bachelor’s degree in computer
`
`science or a comparable field of study, plus approximately two to three years of
`
`professional experience with cellular phone and IP networks, or other relevant
`
`industry experience. Additional graduate education could substitute for
`
`professional experience and significant experience in the field could substitute for
`
`formal education. The knowledge of a POSITA would have included the
`
`following subject matter. Ex. 1002 ¶35.
`
`Networking and the Internet
`1.
`A lowercase-I “internet” or “internetwork” is a network of networks that all
`
`use the same protocol suite to communicate. Ex. 1015 at 7; see also Ex. 1013 at
`
`13, 12-14. “The goal of internetworking is to hide the details of what might be
`
`different physical networks, so that the internet functions as a coordinated unit.”
`
`Ex. 1013 at 13; Ex. 1015 at 8; Ex. 1002 ¶36.
`
`9
`
`

`

`The uppercase-I “Internet” is an internet or internetwork that uses the
`
`TCP/IP protocol suite. Ex. 1009 at 10-12; see also Ex. 1013 at 40; Ex. 1015 at 4.
`
`The TCP/IP protocol suite includes the “Transmission Control Protocol” (TCP),
`
`“User Datagram Protocol” (UDP), and “Internet Protocol” (IP). Ex. 1009 at 12-14,
`
`31-42 (introducing the network layer protocols and describing the IP), 81
`
`(describing UDP), 86 (describing TCP). Ex. 1002 ¶37.
`
`TCP/IP Ports
`2.
`The 925 patent discusses the use of TCP ports. See, e.g., Fig. 2 (step 210
`
`“Open TCP Port”). During prosecution of the first application to which the 925
`
`patent claims priority, applicant admitted that opening a TCP Port was well-known
`
`in the prior art. See, e.g., Ex. 1004 at 415 (“It is well-known in the art that any
`
`general computer system may open different types of default or well-known
`
`listening software ports for specific purposes.”), id (“well-known TCP ports … are
`
`opened as a default to service any and all devices for specific purposes (e.g., FTP,
`
`telnet, HTTP, etc.) … .”), 416 (“mobile devices may generally have the capability
`
`(and indeed must have such a capability for Applicant’s claimed invention) to
`
`open a listening software port … .”) (emphasis original), 416 (footnote 4,
`
`discussing “well-known TCP ports” for FTP and other services), 422 (Annex D
`
`disclosing well-known TCP/UDP ports). These admissions are consistent with the
`
`level of disclosure in the 925 patent, which simply states that ports may be opened
`
`10
`
`

`

`and used without any further explanation. Ex. 1002 ¶38; see, e.g., Ex parte
`
`Reisner, 2013 WL 6217754 at *3 (PTAB Nov. 14, 2013) (“In failing to provide a
`
`more detailed teaching disclosure, Appellant’s Specification essentially presumes
`
`that a person of ordinary skill in the art already knows how to configure an
`
`electromagnetic loop to function as a transmitter.”).
`
`Applicant’s admissions as to the prior art are correct. A POSITA would
`
`have known that the Transport Layer of the Internet Protocol suite, most notably
`
`the Transmission Control Protocol (“TCP”) and the User Datagram Protocol
`
`(“UDP”) used ports. Ex. 1009 at 12-13 (explaining the two most prominent
`
`transport layers TCP and UDP); Ex. 1004 at 416, 422 (Annex D reciting same and
`
`listing the admittedly well-known ports for both TCP and UDP). Because certain
`
`dependent claims recite that the transport layer is TCP, this Petition focuses on the
`
`use of TCP ports. Ex. 1002 ¶39.
`
`Ports were extensively described in the Transmission Control Protocol
`
`(TCP) specification, RFC793, published in 1981. Ex. 1010 at 16, 19-21, 24-28, 30
`
`(“LISTEN - represents waiting for a connection request from any remote TCP and
`
`port.”), 54-55, 90 (“port: The portion of a socket that specifies which logical input
`
`or output channel of a process is associated with the data”). TCP itself was also
`
`notoriously well-known in the art at the time of the 925 patent as a large portion of
`
`Internet messages, both then and now, are conducted using TCP/IP. RFC793
`
`11
`
`

`

`explains that TCP is “intended to provide a reliable process-to-process
`
`communication service in a multinetwork environment.” Ex. 1010 at 11, 10, 12,
`
`14, 16-17, 18-19, 93. TCP interfaces on one side to a user or application process,
`
`and on the other side to a lower level protocol, typically Internet Protocol, which
`
`does not itself provide reliable communication service. Ex. 1010 at 12; Ex. 1022 at
`
`10-12; Ex. 1002 ¶40.
`
`To allow for many processes within a single host to utilize the TCP software
`
`communications facilities, TCP provides a set of addresses, referred to as port
`
`identifiers or simply ports, within each host. Ex. 1010 at 14 and 19. Thus, a port is
`
`the address for a particular process at the host level in the same way that the IP
`
`address is the address for a particular host at the network level. Ex. 1015 at 14
`
`(referring to demultiplexing to identify particular process/application at host based
`
`on TCP port number). The ports are independently defined by a particular host,
`
`but are not necessarily unique as between hosts. Ex. 1010 at 19. To define a
`
`unique address, the TCP port is concatenated with the IP address to form what is
`
`known as a “socket address” or simply “socket,” which uniquely identifies a
`
`particular process on a particular host (a communication end point) across the
`
`network. Id. Two active interconnected sockets thus uniquely and fully define a
`
`connection over the network. Id. TCP messages include headers that specify both
`
`the source and destination ports in the same way that IP headers define both source
`
`12
`
`

`

`and destination IP addresses. Ex. 1010 at 24. The combination of an IP address
`
`and port is also commonly referred to in the art as a “transport address.” Ex. 1013
`
`at 35; Ex. 1002 ¶41.
`
`The standard TCP header includes both source and destination ports as
`
`shown in Figure 3 of RFC793:
`
`Ex. 1010 at 24 (highlighting added); see also Ex. 1015 at 69; Ex. 1002 ¶42.
`
`The TCP software running on a particular host assigns port numbers to
`
`processes running on that host, although industry organizations have reserved
`
`certain port numbers for certain commonly used processes. Ex. 1010 at 20; Ex.
`
`1015 at 15-16. For example, port 21 is associated with FTP (file transfer protocol)
`
`for file transfer programs, port 25 is associated with SMTP (simple mail transfer
`
`protocol) for email programs, and port 80 is associated with HTTP (hypertext
`
`13
`
`

`

`transfer protocol) for web browsers. Since 2002, these well-known ports, as well
`
`as registered ports and private ports, have been maintained by IANA (Internet
`
`Assigned Numbers Authority) in an on-line database. Ex. 1015 at 16. While well-
`
`known port assignments were permanent, other ports, referred to in the art as
`
`ephemeral ports, are temporary ports that are assigned on an as-needed basis.
`
`Ex. 1015 at 16. Ex. 1002 ¶43.
`
`A process on a host utilizes TCP by making calls to OPEN or CLOSE a
`
`connection, SEND or RECEIVE data, or to obtain STATUS about a connection.
`
`These calls are like other calls from user programs on the operating system, such as
`
`calls to open, close, read to, or write from files. Ex. 1010 at 18. To open a TCP
`
`connection, an application performs an OPEN call that specifies local port and
`
`foreign socket arguments. Id. at 19. The local port argument specifies the local
`
`port on which incoming communications are received, and the foreign socket
`
`identifies the IP address and port of the foreign TCP endpoint. The OPEN call can
`
`be active or passive. Id.; see also Ex. 1015 at 84. A passive OPEN call “means
`
`that the process wants to accept incoming connection requests rather than
`
`attempting to initiate a connection.” Ex. 1010 at 20, 19-21, 32, 45-46, 79. If the
`
`process wishes to accept a connection from any other process, the passive OPEN
`
`call specifies a foreign socket with all zeroes. Id. at 20. This allows for a
`
`connection to be established with any process on any host that requests a
`
`14
`
`

`

`connection to the local socket (the local port on the host and the IP address of the
`
`host). Id. Alternatively, the OPEN call can specify a particular foreign socket.
`
`RFC793 explains that a passive OPEN call “is a call to LISTEN for an incoming
`
`connection.” Id. at 54 (emphasis added). This is illustrated diagrammatically in
`
`the TCP state transition diagram in Ex. 1015 at 85, which shows a transition from
`
`CLOSED to LISTEN when an application performs a passive open of a TCP port.
`
`15
`
`

`

`Ex. 1015 at 85 (highlighting added). In other words, the result of a passive OPEN
`
`call is that the TCP software on the host is set to the LISTEN state in which it
`
`listens for an incoming message on the specified local port. Ex. 1002 ¶44.
`
`A POSITA would also understand that a port must be OPEN in order for
`
`messages specifying that port to be received. RFC793 discloses that when a
`
`16
`
`

`

`“connection does not exist (CLOSED) then a reset is sent in response to any
`
`incoming segment except another reset. In particular, SYNs addressed to a non-
`
`existent connection are rejected by this means. If the incoming segment has an
`
`ACK field, the reset takes its sequence number from the ACK field of the segment,
`
`otherwise the reset has sequence number zero and the ACK field is set to the sum
`
`of the sequence number and segment length of the incoming segment. The
`
`connection remains in the CLOSED state.” Ex. 1010 at 45. Thus, a POSITA
`
`would understand that a passively opened listening port would be required to
`
`receive any messages, otherwise any incoming message would be rejected. Ex.
`
`1002 ¶45.
`
`SMS Ports
`3.
`The 925 patent also discusses the use of SMS ports. Ex. 1001 at Fig. 2 (step
`
`220 “Open SMS Port”), 4:40-43 and 6:2-4. Applicant similarly admitted that SMS
`
`ports were well-known in the prior art. Ex. 1004 at 415-16 (“For example, a
`
`mobile device may support a default SMS listening software port opened to receive
`
`SMS messages from all other devices … .”). This is consistent with the
`
`specification that merely mentions the optional use of SMS ports without further
`
`explanation. Ex parte Reisner, 2013 WL 6217754 at *3 (PTAB Nov. 14, 2013).
`
`Ex. 1002 ¶46.
`
`17
`
`

`

`Applicant’s admissions are well founded, as the use of ports in connection
`
`with SMS messages was also well-known and standardized in the prior art SMS
`
`Specification itself. As disclosed in SMS Specification, 8- and 16-bit application
`
`port addressing “allows short messages to be routed to one of multiple applications
`
`in the TE (terminal equipment), using a method similar to TCP/UDP ports in a
`
`TCP/IP network.” Ex. 1014 at 72-73, 66-69. The 16-bit port addresses 0-15999
`
`are well-known ports allocated by the IANA just like the ports for TCP and UDP.
`
`Id. at 73. A POSITA would also have known that SMS ports could be opened in a
`
`listen mode. For example, WMA discusses an application program interface that
`
`supports the use of ports that an application on a device such as a mobile phone
`
`could use to send and receive wireless messages on services such as GSM SMS or
`
`CDMA SMS. Ex. 1018 at 21; Ex. 1018 at 44. WMA further discloses opening a
`
`port in listening mode in order to receive an SMS message and notify an
`
`application associated with that port. Ex. 1018 at 11-12, 22 (disclosing the
`
`MessageListener interface), 27-28, 31-34, 37-45. Ex. 1002 ¶47.
`
`SMS Invitations and TCP/IP-based Responses
`4.
`A POSITA would have been familiar with the well-known technique of
`
`sending SMS invitations and providing IP-based responses. The 925 patent
`
`acknowledges this in its discussion of the MMS protocol, which was one well
`
`known and standardized example of that technique. Ex. 1001 at 1:23-57. In the
`
`18
`
`

`

`MMS protocol, a server sends its URL to the target mobile device using a “WAP
`
`Push over the Short Message Service (‘SMS’) protocol.” Id. The mobile device
`
`responds by using the server’s URL to initiate a TCP/IP connection to obtain the
`
`multimedia content. Id. A POSITA would know that the mobile device opens the
`
`WAP port to listen for the WAP Push over SMS, so that the message can be routed
`
`to the WAP browser, which can then use the URL to initiate the TCP/IP
`
`connection. A POSITA also understands that the server opens and listens on a
`
`TCP port for the expected TCP/IP response. An example of a WAP Push over
`
`SMS followed by a TCP/IP response is U.S. Pat. App. No. 2003/0217174
`
`(Dorenbosch). Ex. 1011 at Fig. 3, [0027]-[0037]; Ex. 1002 ¶48.
`
`Claim Construction Under 37 C.F.R. § 42.104(b)(3)
`D.
`The claims are interpreted using the same claim construction standard that is
`
`used to construe the claim in a civil action in federal district court. 83 FR 51340-
`
`59.
`
`Petitioner does not contend that the constructions proposed herein are
`
`complete constructions of these limitations or the claims for any other purpose,
`
`including for issues that have been raised in the related litigation. Because the
`
`prior art asserted herein discloses the preferred embodiment within the indisputable
`
`scope of the claims, the Board need not construe the outer bounds of the claims as
`
`part of these proceedings. The district court may have to address other bounds of
`
`19
`
`

`

`the claims in addressing infringement. See, e.g., 83 FR 51340 at 47-48, 55
`
`(“[O]nly those terms that are in controversy need be construed, and only to the
`
`extent necessary to resolve the controversy”), 65-71.
`
`1.
`
`“page-mode messaging service” (claims 1-2, 4-5, 8-9, 11-12,
`15-16, 18)
`This limitation need not be construed explicitly for purposes of the issues
`
`raised in the Petition. The claims and specification disclose that “page-mode
`
`messaging service” encompasses the Short Message Service (“SMS”). Ex. 1001 at
`
`3:13-17 and claims 4, 11, 18. The prior art asserted herein discloses SMS. Ex.
`
`1002 ¶49.
`
`2.
`
`No Order Required Between the Steps of Claims 1 and 2; 8
`and 9; and 15 and 16.
`Independent claims 1, 8 and 15 are each directed to an initiating device that
`
`sends an invitation to a target mobile device and then establishes a connection with
`
`that device. Dependent claims 2, 9, and 16 each add limitations to their respective
`
`independent claims related to an invitation received by the initiating mobile device
`
`from “another” mobile device. There is no claimed relationship between the
`
`timing of any of the steps in these independent claims vis-à-vis the steps in these
`
`dependent claims, such that the steps of the dependent claims can be performed at
`
`any time before or after the steps of the independent claims. Nor does the
`
`20
`
`

`

`specification require any temporal relationship. Thus, none is required. Ex. 1002
`
`¶50; see, e.g., Altiris Inc. v. Symantec Corp.,