Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`Apple, Inc. (“Apple”) hereby contends that the asserted claims (claims 1-19) of U.S. Patent No. 9,189,787 (“the ’787 patent”) are invalid as
`anticipated and/or rendered obvious by U.S. Publication No. 2006/0165060 (“Dua”) under 35 U.S.C. §§ 102 and/or 103, alone or in view of the
`knowledge and skill of one in the art at the time and/or any other prior art reference identified herein or within the related pleading, including, but not
`limited to, SmartMX, P5CT072 Secure Dual Interface PKI Smart Card Controller, Short Form Specification (Rev. 1.3) (“Philips”), and GlobalPlatform
`Card Specification Version 2.1.1 (“GlobalPlatform”). Dua was filed on January 21, 2005, and published on July 27, 2006. Philips was published on
`October 4, 2004. GlobalPlatform was published on March 2003.
`The chart below discloses how the aforementioned prior art reference discloses, either expressly or inherently, and/or renders obvious each of
`the asserted claims. The citations provided are exemplary and do not necessarily include each and every disclosure of the limitation in the references.
`Apple has endeavored to cite to the most relevant portions of the identified prior art, but other portions of the identified prior art may additionally
`disclose, either expressly or inherently, and/or render obvious one or more limitations of the asserted claims. Thus, Apple reserves the right to rely on:
`(1) uncited portions of the identified prior art; (2) other prior art not identified herein; (3) references that show the state of the art (irrespective of
`whether such references themselves qualify as prior art to the asserted patents); (4) factual testimony from the inventors or authors of the prior art
`references, or purveyors of prior art devices; and/or (5) expert testimony, to provide context to or aid in understanding the prior art and the state of the
`art at the time of the alleged inventions.
`The lack of a citation for an element should not be deemed an admission that the element is not disclosed or is not inherent in the reference.
`When the chart indicates a particular reference discloses or embodies a limitation, the terms “discloses,” “disclosed,” “embodies,” and “embodied”
`refer to explicit and/or inherent disclosure and/or obvious variations of the actual disclosure. Further, for each claim limitation that Apple contends is
`indefinite, Apple has used its best efforts to reasonably interpret the claims to fulfill their duties in charting the prior art references.
`Where Apple cites to a particular drawing or figure in the accompanying charts, the citation encompasses the description of the drawing or
`figure, as well as any text associated with the drawing or figure. Similarly, where Apple cites to particular text concerning a drawing or figure, the
`citation encompasses that drawing or figure as well. Certain identified prior art inherently discloses features of the asserted claims. Apple reserves the
`right to rely on inherency to demonstrate the invalidity of the asserted claims. Moreover, certain prior art references may inherently disclose certain
`features of the asserted claims as construed by RFCyber Corp. Apple may rely on cited or uncited portions of the prior art, other documents, factual
`testimony, and expert testimony to establish the inherency of certain features of the prior art to invalidate the asserted claims.
`
`The exemplary disclosures identified below disclose and/or render obvious the asserted claims as Defendant currently understands them,
`including based on Plaintiff’s infringement contentions. No disclosure or statement below is intended to assert or agree with any particular claim
`construction position and Defendant reserves the right to advance and rely on positions regarding claim construction and noninfringement regardless
`of the disclosures asserted herein.
`
`WEST\297673027.1
`
`1
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 001
`
`

`

`Claim
`No.
`1[pre]
`
`’787 Patent Claim Limitation
`
`A portable device for commerce, the
`portable device comprising:
`
`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`Exemplary disclosure
`
`To the extent the preamble is limiting, Dua discloses a portable device for commerce.
`See Claim 1.
`“The present invention relates generally to systems and methodologies for conducting
`electronic commerce and more particularly to systems and methodologies for issuing,
`managing, storing and using credentials authorizing the legitimate holder of such a credential
`to accomplish a desired result”.
`
`“Another important trend in consumer-related electronics is the increased speed and the reduced
`size of available electronic components which has contributed to the proliferation of powerful
`wireless devices. Mobile devices including personal digital assistants (PDAs) and cellular
`phones now number over one billion worldwide. The capability of wireless devices has been
`augmented by their ability to connect to the Internet and also to exchange data over short ranges
`with other wireless devices or readers”.
`
`“As stated above, the present invention preferably involves the distribution of credentials to a
`“wireless device'. As used herein, wireless device 200 is preferably a device that is capable of
`wirelessly connecting to the Internet using network protocols such as GSM/GPRS,
`CDMA2000, W-CDMA, EDGE, HDR, 1xRTT, UMTS, IMT-2000, 802.11a, 802.11b,
`802.11g, or BLUETOOTH or other relevant protocols developed hereinafter. Preferably,
`wireless device 200 has a display screen and a key pad for alphanumeric and special character
`data input. It is further preferred that wireless device 200 has processing and secure
`storage capabilities allowing it to host and operate a wallet application capable of receiving,
`storing, managing and transmitting multiple payment, identification, and other confidential
`information electronically. Wireless device 200 also preferably has an integrated short-range
`communication capability for transmitting confidential information and exchanging other data
`between the wallet application and an external reader that is in proximity to the wireless
`device”.
`
`WEST\297673027.1
`
`2
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 002
`
`

`

`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`“FIG. 3 illustrates some of the SIP components, their relationship to one another and the
`protocols that are employed. A user agent acting as a client (in this case the issuer WCM 410
`which is in communication with issuer card management system 420) uses SIP to set up a
`session with a user agent that acts as a server (in this case a wallet application operating on
`user's wireless device 400). The session initiation dialogue uses SIP and involves one or more
`proxy servers to forward requests and responses between the two user agents. The user agents
`also make use of the SDP, which is used to describe the media session”.
`
`“Mobile transactions can be performed in three environments: local, remote, and personal. Each
`environment has its own mobile commerce services and characteristics that may require
`specific technologies. A wallet application on a wireless device that enables transactions in all
`three environments will provide the greatest utility to users. Electronic credentials issued to a
`user and stored in the wallet application can be used in all three environments”.
`
`“As can be seen in FIG. 8, a first transmission path of an electronic credit card authorization
`request 870 includes, for example, a merchant store controller and merchant host system, an
`acquirer/processor network, a private network such as VisaNet, and a issuer gateway. Using
`these components, point of sale terminal 860, via RF reader 820 can be used to capture and
`transmit an electronic credential from a wireless device for online authorization. The second
`transmission path as shown in FIG. 8 is via WCM 810 using the Internet and wireless link 880
`and issuer DNS server 890 and is used to deliver a PIN request to wireless device 800 and to
`receive a user-input response from wireless device 800”.
`
`Dua ¶¶ [002], [0015], [0041], [0107], [0313], [0405].
`
`WEST\297673027.1
`
`3
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 003
`
`

`

`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`WEST\297673027.1
`
`4
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 004
`
`

`

`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`WEST\297673027.1
`
`5
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 005
`
`

`

`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`WEST\297673027.1
`
`Dua at FIGs. 1, 3, and 8.
`
`6
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 006
`
`

`

`1[a]
`
`an emulator loaded in a smart card
`module for storing security values and
`updated transaction logs, and
`
`WEST\297673027.1
`
`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`Dua discloses an emulator loaded in a smart card module for storing security values and
`updated transaction logs.
`For Example:
`See 1[pre], which is incorporated by reference.
`To the extent that this element is not explicitly disclosed, a POSITA would have found this
`element obvious in light of this reference in combination with the knowledge and skill of a
`POSITA and/or one or more of the other prior art references identified by Defendants. For
`example, a POSITA would have recognized and understood that the teachings of this
`reference could be modified, combined, or replaced with the teachings from the other
`identified prior art references, including, but not limited to, the disclosures identified in the
`following documents and charts related to this limitation:
`
`See, e.g, APL-RFC0916-PA-00000001 - APL-RFC0916-PA-00021141
`See, e.g., “C” Charts regarding the ’787 patent
`
`A POSITA would have been motivated to combine the teachings of these references to
`practice this limitation. For example, one of skill in the art would find these combinations
`obvious to try, due at least to the similarity of the technical teachings of the art. As another
`example, one of skill in the art would find that the teachings could be predictably
`interchanged by, for example, simple substitution, at least because of the predictability of the
`art and the known interchangeability of the various elements. As another example, one of skill
`in the art would be motivated to combine the references, and would have a reasonable
`expectation of success in doing so, at least because the references use known variations of
`existing technology to solve routine and well understood problems in predictable ways.
`
`For example:
`Philips pp 2-3, 692-693.
`Dua discloses “a novel system and methodology for conducting financial and other transactions
`requiring authorization” that involves the secure distribution and personalization of
`applications to a “handheld device such as a mobile telephone via a wireless network.” Dua
`¶[0026]. Dua’s wireless device “has processing and secure storage capabilities allowing it to
`7
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 007
`
`

`

`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`host and operate a wallet application capable of receiving, storing, managing and transmitting
`multiple payment, identification, and other confidential information electronically” through a
`wireless interface or through a short-range communication capability. Id., ¶¶[0041], [0309].
`Dua’s wireless device includes “an embedded smart card” that can be programmed with an
`account holder’s information, keys and authentication information that provides for
`authentication in connection with a transaction and protects data through secure encryption
`methods. Id., ¶¶[0295], [0215], [0007].
`Dua refers to credit card organizations “working jointly over the last few years to develop
`specifications that define a set of requirements for security and interoperability between chip
`cards and terminals on a global basis, regardless of the manufacturer, financial institution, or
`where the card was used,” which a POSITA would recognize as including GlobalPlatform. Id.,
`¶[0014]; GlobalPlatform, p.16(§1).
`Indeed, GlobalPlatform discloses “a hardware-neutral, vendor neutral, Application-
`independent [smart] card management specification” that provides a security architecture that
`protects the “structure and function of cards within the GlobalPlatform system” for the life of
`the card. GlobalPlatform, pp.16, 32. Dua’s “wallet application should meet standards defined
`by card organizations,” and GlobalPlatform was one such standard. Dua, ¶[0525];
`GlobalPlatform, p.16. Dua also discloses the use of a Java platform and Java applets with its
`wireless devices, which a POSITA would recognize as being a reference to Java Card. Dua,
`¶¶[0195], [0216], [0498]-[0500]. GlobalPlatform is specifically designed to be compatible with
`Java Card. GlobalPlatform, p.24(§1.5.2.10); see also id. p.29 (“GlobalPlatform is intended to
`run on
`top of any secure, multiapplication card runtime environment.”). Further,
`GlobalPlatform specifically facilitates loading and installing of issuer specific Applications,
`such as Dua’s extensions. GlobalPlatform, p.27 (showing system architecture and explaining
`“the business partners of a Card Issuer can be allowed to manage their own Applications on the
`Card Issuer's cards as appropriate.”) For at least these reasons, a POSITA would be motivated
`to and would find it obvious to use GlobalPlatform with Dua’s smart cards, wallet application,
`and extensions.
`Dua discloses dual interface (hybrid) smart cards and their benefits. Dua, ¶¶[0008], [0010]-
`[0011]. Philips Semiconductor SmartMX smart cards were well-known dual interface cards, as
`the ’787 patent and related prosecutions admit. As described by Philips, the SmartMX card is
`designed to work with Java Card and GlobalPlatform and is “positioned to service …
`8
`
`WEST\297673027.1
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 008
`
`

`

`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`multiapplication markets such as … mobile communications,” i.e., wireless devices. Philips,
`p.1, making SmartMX cards especially attractive to a POSITA considering which smart card
`to use in Dua’s wireless devices. Accordingly, a POSITA would have recognized that Philips
`described a SmartMX card that would have fit the needs of Dua. Moreover, Philips explains
`that the SmartMX card supports an e-purse in a MIFARE® emulator used for RF
`communications (readers) for bus/train fare. Philips, pp.2- 3 (discussing “[c]ompatibility with
`existing MIFARE” and “free of charge emulation” and use in RF harsh environments like “in
`buses or train stations.”). Dua prefers its wireless devices to include such RF functionality. Dua,
`¶¶[0290], [0293]. A POSITA, therefore, would have found it advantageous to use the SmartMX
`smart card with its built in MIFARE® emulator as the smart card of Dua’s wireless device.
`Dua, ¶[0295]. Thus, a POSITA would be motivated to and would find it obvious to use a Philips
`smart card in Dua’s wireless device. A POSITA would have found it obvious to use any
`compatible smart card with Dua’s wireless devices.
`
`Dua discloses an e-purse applet to cause the portable device to function as an electronic purse
`(e-purse).
`For Example:
`See 1[pre]-1[a], which are incorporated by reference.
`“The following discussion provides additional details concerning the wallet application of the
`present invention in a preferred embodiment thereof. The wallet application is a platform
`capable of securely holding a myriad of different electronic credentials and making them
`available in a controlled way through specific functions. When loaded on a wireless device, an
`icon for the wallet application is designed to appear on the main navigation screen. The icon
`can be used to launch the application.
`The open-architecture of the wallet platform allows credential issuers to deploy their own
`commerce-specific applications called “extensions’. Extensions literally “extend the capability
`of the wallet platform by enabling a new set of features defined by the credential issuer.
`Different credentials serve many unique purposes and are not all used in the same way”.
`
`“For example, when a subway contactless stored value card is waved in front of a reader at the
`turnstile, the electronic balance is automatically debited from the onboard chip. The rules that
`9
`
`1[b]
`
`an e-purse applet to cause the portable
`device to function as an electronic
`purse (e-purse),
`
`WEST\297673027.1
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 009
`
`

`

`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`govern the functioning of that stored value program and the cards interaction with an external
`RF reader, are all programmed into the onboard chip”.
`
`“These are just a few examples of the types of credentials that can be issued to and stored within
`the wallet application. Implementing electronic versions of these credentials in the wallet
`application creates different operating and processing requirements for each credential.
`Consider the requirements associated with implementing the subway stored value credential
`through the wallet platform. The logic required to operate the subway stored value credential,
`the unique message format for communication between the wireless device and a RF reader at
`the turnstile, unique display messages, an over-the-air reload tool, and other features associated
`with the stored value credential that a user might see on the wireless device—all need to be
`programmed into the wallet application. These types of requirements are embodied in mini-
`programs that operate within the wallet application called “extensions' since they “extend the
`capability of the wallet application in order to handle new features and capabilities that are
`specific to an issuer's credential. These extensions allow credentials to be used in a controlled
`way through specific issuer-defined functions”.
`
`“Sample sub-categories are represented in the example credential tree below. The credential
`tree may be used to visually present information in the wallet application”.
`
`“Certain payment methods such as subway stored value cards may be organization specific and
`be the only payment method accepted; as such, a subway operator may employ reader keys to
`facilitate a rapid payment system with wireless devices”.
`
`“A user may be willing to assume a slight risk by designating certain credentials for PIN-less
`use since the benefits of speed and convenience are important to them. Rapid payment at the
`subway turnstile is an example of where the benefits of speed and convenience may outweigh
`the risks associated with designating a stored value credential on a wireless device for PIN-less
`use, leaving open the possibility that a fraudster could steal the device and use the stored value
`purse. Each individual will have their own risk tolerance and as such will want the flexibility
`to designate specific credentials in their wallet as requiring advance PIN-entry and others to
`function without the prior input of the wallet PIN”.
`
`WEST\297673027.1
`
`10
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 010
`
`

`

`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`“This design also offers a flexible solution for user's to gain access to their credentials in their
`digital wallet without the use of a wireless device. For example, in one scenario, a user making
`a purchase at a grocery store may be
`prompted at the point-of-sale for his E. 164 phone number and his fingerprint. The grocery
`chain's IP-enabled POS system will capture the E. 164 number and biometric information, and
`forward them to a WCM connected to the grocery chain's network. The grocery chain's WCM
`will be used in this case to facilitate a transaction with the wallet server where the user is
`registered. The WCM will perform an ENUM query on the E. 164 number using a DNS server
`on the grocery chain's network, retrieve a NAPTR record that corresponds to the appropriate
`wallet service (e.g.“E2U+walletserver”), and use the URI in the NAPTR record to establish a
`secure peer-to-peer session via the Internet to the wallet server. The WCM and the wallet server
`may exchange encryption keys using established methods for doing so over the Internet prior
`to exchanging any confidential information. After the key exchange, the WCM will send the
`wallet server the E. 164 number and the biometric information (fingerprint data) that was
`captured at the POS. The wallet server will validate that the E. 164 number is associated with
`an account on record that is in good standing. If the account is valid and in good standing, the
`wallet server will validate the biometric information against information stored in the account.
`If the biometric information matches, the wallet server will transmit a menu showing all the
`credential types that are in the customer's wallet. This menu corresponds to the primary
`credential categories in the hierarchy that was previously discussed in this document. The
`customer could for example select “payment methods’ and then see the secondary hierarchy
`(credit cards, debit cards, stored value cards, etc). Credentials will be displayed under the
`secondary categories. Credential listings will be displayed with some of the follow
`information:”
`
`Dua ¶¶ [0288] – [0289], [0290], [0293], [0345], [0363], [0368], [0543].
`To the extent that this element is not explicitly disclosed, a POSITA would have found this
`element obvious in light of this reference in combination with the knowledge and skill of a
`POSITA and/or one or more of the other prior art references identified by Defendants. For
`example, a POSITA would have recognized and understood that the teachings of this
`reference could be modified, combined, or replaced with the teachings from the other
`
`WEST\297673027.1
`
`11
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 011
`
`

`

`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`identified prior art references, including, but not limited to, the disclosures identified in the
`following documents and charts related to this limitation:
`
`See, e.g, APL-RFC0916-PA-00000001 - APL-RFC0916-PA-00021141
`See, e.g., “C” Charts regarding the ’787 patent
`
`A POSITA would have been motivated to combine the teachings of these references to
`practice this limitation. For example, one of skill in the art would find these combinations
`obvious to try, due at least to the similarity of the technical teachings of the art. As another
`example, one of skill in the art would find that the teachings could be predictably
`interchanged by, for example, simple substitution, at least because of the predictability of the
`art and the known interchangeability of the various elements. As another example, one of skill
`in the art would be motivated to combine the references, and would have a reasonable
`expectation of success in doing so, at least because the references use known variations of
`existing technology to solve routine and well understood problems in predictable ways.
`
`Dua discloses wherein both of the emulator and e-purse applet are already personalized via a
`personalization process built on a first security channel so that the emulator is set to store a set
`of keys for subsequent data access authentication and the e-purse applet is configured to
`conduct a transaction with a network server over a second security channel.
`For Example:
`See 1[pre]-1[b], which are incorporated by reference.
`“Turning now to FIG. 2, an overview of the credential issuance process of the present invention,
`in a preferred embodiment thereof, is now described. The credential issuance process begins
`with WCM 110 receiving a request from the issuer's card or user management system 120 to
`issue electronic credentials to an individual user (see step 310). The request is forwarded to
`WCM 110 along with the user's mobile (E.164) number, the credentials to be issued, encryption
`keys, and other information contained in the Personalization File for the specific request. The
`Personalization File may be a batch file that contains numerous records of credentials that are
`to be issued to individuals on their wireless device 200, or could be a separate file record for
`each credential to be issued. In another embodiment, the Personalization File is transmitted to
`
`12
`
`1[c]
`
`wherein both of the emulator and e-
`purse applet are already personalized
`via a personalization process built on a
`first security channel so that the
`emulator is set to store a set of keys for
`subsequent data access authentication
`and the e-purse applet is configured to
`conduct a transaction with a network
`server over a second security channel;
`
`WEST\297673027.1
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 012
`
`

`

`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`WCM 110 by issuer personalization server 130 which is in communication with issuer
`cardholder system 120. Issuer personalization server communicates with personalization
`bureau server 140 which is typically maintained by the personalization bureau”.
`“The Personalization File is preferably similar to the Personalization File that credit card issuers
`send to personalization bureaus responsible for manufacturing, personalizing, and fulfilling
`magnetic-stripe cards for issuance to customers. The Personalization File received by
`personalization bureaus from credit card companies contains all the necessary account and
`consumer data required to emboss a card, encode the magnetic stripe, and fulfill the issued card
`via mail. Other information is sometimes also included in the Personalization File depending
`on the additional services performed by the Personalization Bureau. For example, the file may
`contain data indicating a request of the Personalization Bureau to generate a personal
`identification number (PIN) which may be mailed to the customer. This information or a subset
`thereof makes up the personalization file record that is transmitted by issuer cardholder system
`120 to WCM 110 in connection with a credential issuance request according to the present
`invention”.
`
`“SIP is based on an HTTP-like request/response transaction model. Each transaction consists
`of a request that invokes a particular method, or function, on the server and at least one
`response. SIP uses most of the header fields, encoding rules, and status codes of HTTP. This
`provides a readable text-based format for displaying information. SIP incorporates the use of
`Session Description Protocol (SDP), which defines session content using a set of types similar
`to those used in Multipurpose Internet Mail Extensions (MIME). Technically, SIP will
`function across both IPv4 and IPv6 networks”.
`
`“SIP often runs on top of the User Datagram Protocol (UDP) for performance reasons, and
`provides its own reliability mechanisms, but may also use TCP. If a secure, encrypted transport
`mechanism is desired, SIP messages may alternatively be carried over the Transport Layer
`Security (TLS) protocol”.
`
`“SIP URIs have a format based on e-mail address formats, namely user@domain. There are
`two common schemes. An ordinary SIP URI is of the form: sip:bob@biloxi.com. The URI may
`also include a password, port number, and related parameters. If secure transmission is required,
`“sip:” is replaced by "sips:”. In the latter case, SIP messages are transported over TLS.
`13
`
`WEST\297673027.1
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 013
`
`

`

`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`“The following discussion covers security mechanisms and procedures which may be used in
`a preferred embodiment of the system of the present invention. Since the SIP message structure
`is a straight derivation from the HTTP request/response model, all security mechanisms
`available for HTTP (RFC 2617) can also be applied to SIP sessions. The use of MIME
`containers within SIP messages supports the use of email security mechanisms S/MIME (RFC
`2633). And of course similar to a https: URI, a corresponding sips: URI will try to build up a
`secure transport layer tunnel using TLS (RFC 2246). And last but not least IP security (IPsec)
`(RFC 2315) can be used as a general purpose mechanism to encrypt all IP based communication
`right on the network layer”.
`
`“Another possible security mechanism is Secure MIME (S/MIME). SIP messages carry MIME
`bodies. MIME itself defines mechanisms for the integrity protection and the encryption of the
`MIME contents. SIP may utilize S/MIME to enable mechanisms like public key distribution,
`authentication and integrity protection, or confidentiality of SIP signaling data. S/MIME may
`be considered as a replacement for PGP used in RFC2543 to provide means for integrity
`protection and encryption of SIP messages. To be able to protect SIP header fields as well,
`tunneling of SIP messages in MIME bodies is specified. Generally the proposed SIP tunneling
`for SIP header protection will create additional overhead. S/MIME requires certificates and
`private keys to be used, whereas the certificates may be issued by a trusted third party or may
`be self-generated. The latter case may not provide real user authentication but may be used to
`provide a limited form of message integrity protection”.
`
`“Yet another security mechanism which may be used in accordance with the present invention
`is based upon SIPS URI (TLS). RFC3261 mandates the use of TLS for proxies, redirect servers,
`and registrars to protect SIP signaling. Using TLS for UAS is recommended. TLS is able to
`protect SIP signaling messages against loss of integrity, confidentiality and against replay. It
`provides integrated key-management with mutual authentication and secure key distribution.
`TLS is applicable hop-by-hop between UAS/proxies or between proxies. The drawback of TLS
`in SIP scenarios is the requirement of a reliable transport stack (TCP-based SIP signaling). TLS
`cannot be applied to UDP based SIP signaling”.
`
`WEST\297673027.1
`
`14
`
`RFCyber's Exhibit No. 2006, IPR2022-00412
`Page 014
`
`

`

`Exhibit C-2 – Invalidity Chart Regarding
`U.S. Publication No. 2006/0165060 (“Dua”)
`
`“Another security mechanism which may be used in connection with the present invention is
`IP Security (IPsec). IPsec may also be used to provide security for SIP signaling at the network
`layer. This type of security is most suited to securing SIP hosts in a SIP VPN scenario (SIP user
`agents/proxies) or between administrative SIP domains. IPsec works for all UDP, TCP and
`SCTP based SIP signaling. IPsec may be used to provide authentication, integrity and
`confidentiality for the transmitted data and supports end-to-end as well as hop-by-hop
`scenarios. At this time there is no default cipher suite for IPsec defined in SIP. Note: RFC 3261
`does not describe a framework for the use of IPsec. Especially, no information is given as to
`how the key management is to be realized, or which IPsec header and mode is to be used”.
`
`“In order to provide security implementation (see RFC 3261), various requirements exist. It is
`intended that the proxy servers and registrars will support TLS, and both mutual and one-way
`authentication. It is also intended that the WCM and the wallet application will be capable
`initiating TLS. Proxy servers, redirect servers, and registrars may use a site certificate whose
`subject corresponds to their canonical hostname. UAs may have certificates of their own for
`mutual authentication with TLS. All SIP elements that Support TLS should have a mechanism
`for validating certificates received during TLS negotiation; this entails possession of one or
`more root certificates issued by certificate authorities (preferably well-known distributors of
`site certificates comparable to those that issue root certificates for web browsers). Further, all
`SIP elements that support TLS should support the SIPS URI scheme”.
`
`“The WCM and the wallet application should support the signing and encrypting of MIME
`bodies, and transference of credentials with S/MIME as described in Section 23 of RFC 3261.
`If a UA holds one or more root certificates of certificate authorities