Apple Inc.Download PDFPatent Trials and Appeals BoardFeb 8, 20212020005817 (P.T.A.B. Feb. 8, 2021) Copy Citation UNITED STATES PATENT AND TRADEMARK OFFICE UNITED STATES DEPARTMENT OF COMMERCE United States Patent and Trademark Office Address: COMMISSIONER FOR PATENTS P.O. Box 1450 Alexandria, Virginia 22313-1450 www.uspto.gov APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO. 14/474,787 09/02/2014 Yousuf H. Vaid 5607.2040001 (P21734US1) 7814 63975 7590 02/08/2021 STERNE, KESSLER, GOLDSTEIN & FOX P.L.L.C. 1100 NEW YORK AVENUE, N.W. WASHINGTON, DC 20005 EXAMINER SAX, TIMOTHY P ART UNIT PAPER NUMBER 3685 NOTIFICATION DATE DELIVERY MODE 02/08/2021 ELECTRONIC Please find below and/or attached an Office communication concerning this application or proceeding. The time period for reply, if any, is set in the attached communication. Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the following e-mail address(es): Apple-eOA@sternekessler.com e-office@sternekessler.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ Ex parte YOUSUF H. VAID, GEORGE R. DICKER, AHMER A. KHAN, CHRISTOPHER B. SHARP, GLEN W. STEELE, CHRISTOPHER D. ADAMS, and DAVID T. HAGGERTY ____________ Appeal 2020–005817 Application 14/474,787 Technology Center 3600 ____________ Before ANTON W. FETTING, MICHAEL C. ASTORINO, and JAMES P. CALVE, Administrative Patent Judges. FETTING, Administrative Patent Judge. DECISION ON APPEAL STATEMENT OF THE CASE1 Yousuf H. Vaid, George R. Dicker, Ahmer A. Khan, Christopher B. Sharp, Glen W. Steele, Christopher D. Adams, and David T. Haggerty 1 Our decision will make reference to the Appellant’s Appeal Brief (“Appeal Br.,” filed March 10, 2020) and Reply Brief (“Reply Br.,” filed August 10, Appeal 2020-005817 Application 14/474,787 2 (Appellant2) seeks review under 35 U.S.C. § 134 of a final rejection of claims 1–10, 21, 23, 24 ,26, 28, and 30–37, the only claims pending in the application on appeal. We have jurisdiction over the appeal pursuant to 35 U.S.C. § 6(b). We REVERSE. The Appellant invented a way of generating identifiers and receipts related to financial transactions conducted by electronic devices via wireless communication. Spec., para. 3. An understanding of the invention can be derived from a reading of exemplary claim 1, which is reproduced below (bracketed matter and some paragraphing added). 1. An electronic device, comprising: [1] an antenna; [2] an interface circuit coupled to the antenna and configured to communicate with an other [sic, another] electronic device; and [3] a secure element coupled to the interface circuit and configured to:3 [4] generate a dynamic card verification value (DCVV) for a financial transaction based at least in part on an account number identifier that indirectly specifies a financial account, 2020), and the Examiner’s Answer (“Ans.,” mailed June 10, 2020), and Final Action (“Final Act.,” mailed October 11, 2019). 2 We use the word “Appellant” to refer to “applicant” as defined in 37 C.F.R. § 1.42. Appellant identifies the real party in interest as Apple, Inc. (Appeal Br. 3). 3 Encompasses limitations 4–10. Appeal 2020-005817 Application 14/474,787 3 a truncated counter value representing a number of transactions conducted by the electronic device, and a random number; [5] generate financial-account information comprising the account number identifier, the truncated counter value, and the DCVV; [6] determine a first transaction identifier that uniquely identifies the financial transaction based at least in part on the financial- account information; [7] conduct the financial transaction with the other electronic device by transmitting, using the interface circuit, the financial- account information to the other electronic device; [8] receive, from a computer system operated for a third party, a notification associated with the financial transaction, wherein the computer system operated for the third party is independent of a counterparty in the financial transaction associated with the other electronic device; [9] receive, from the computer system operated for the third party, receipt information associated with the financial transaction, wherein the receipt information comprises a second transaction identifier that uniquely identifies the financial transaction, wherein the second transaction identifier is computed based at least in part on the financial-account information transmitted to the other electronic device; and [10] associate the receipt information with the financial transaction based at least in part on the first transaction identifier and the second transaction identifier. Appeal 2020-005817 Application 14/474,787 4 The Examiner relies upon the following prior art: Name Reference Date Bowman US 6,460,163 B1 Oct. 1, 2002 Biere US 7,742,762 B1 June 22, 2010 Pastusiak US 2006/0129502 A1 June 15, 2006 Dua US 2006/0165060 A1 July 27, 2006 Hammad US 2008/0040276 A1 Feb. 14, 2008 Wentker US 2008/0167017 A1 July 10, 2008 Ronda US 2011/0265159 A1 Oct. 27, 2011 Claims 1, 3–10, 21, 23, 24, 26, 28, and 34–37 stand rejected under 35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, and Bowman.4 Claim 2 stands rejected under 35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, Bowman, and Biere. Claim 30 stands rejected under 35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, Bowman, and Ronda. Claims 31–33 stand rejected under 35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, Bowman, and Pastusiak. ISSUES The issues of obviousness turn primarily on whether all of the claim limitations deserve patentable weight and whether all limitations deserving such weight are described by the art. 4 Claim 23 is omitted from the lead paragraph (Final Action 4), but is included in the analysis (Final Action 9). Appeal 2020-005817 Application 14/474,787 5 FACTS PERTINENT TO THE ISSUES The following enumerated Findings of Fact (FF) are believed to be supported by a preponderance of the evidence. Facts Related to Appellant’s Disclosure 01. The financial-account information may correspond to or be equivalent to magnetic-stripe data on a credit card. Financial- account information includes data, such as: a token associated with a financial-account identifier, a card-holder-name field, an expiration date of the financial account specified by the financial- account identifier, a numerical value corresponding to a number of financial transactions conducted by electronic device, a dynamic card verification value (DCVV) for the financial transaction, and/or additional data. Spec., para. 36. 02. If the financial account is a credit-card account, the token may be a device primary account number (DPAN) instead of the financial primary account number (FPAN) or credit-card number, where the DPAN may be thought of as a 'virtual' credit card number that corresponds/maps to a 'real' FPAN. In addition, the financial- account information may include a truncated counter value (such as the least-significant three bits, four bits or five bits of a two- byte counter value) combined with the dynamic card verification value. Note that the dynamic card verification value may be dynamically generated by the secure element in electronic device for each financial transaction using a cryptographic technique using the DPAN, the counter value, one or more cryptographic keys and a random number provided by electronic device during Appeal 2020-005817 Application 14/474,787 6 the wireless communication. Consequently, a different dynamic card verification value may be generated for each financial transaction. Spec., para. 37. 03. The process encrypts and/or decrypts authentication information communicated with authentication subsystem, and encrypts and/or decrypts information (such as tokens) communicated with secure subsystem. The process compares authentication information with stored authentication. Spec., para. 51. 04. The Specification contains no other reference to the dynamic card verification value, and in particular, describes no functional use of the value or the data representing the value other than as a conventional authentication value after it is generated, encrypted, and decrypted. The Specification describes no functional effect of the DPAN or the counter value upon the dynamic card verification value’s use as a conventional authentication value or on any other functional effect upon the process. Facts Related to the Prior Art Wentker 05. Wentker is directed to improved consumer mobile phone payment systems and methods. Wentker, para. 8. 06. Wentker describes a mobile phone, which can include mobile phone components such as an NFC communications element, a secure element comprising a payment application, and resident applications including one or more mobile applications and one or more download managers. Wentker, para. 37. Appeal 2020-005817 Application 14/474,787 7 Hammad 07. Hammad is directed to improved consumer and portable consumer device authentication and authenticating a portable consumer device such as a payment card and a consumer using the portable consumer device, performing back end processing, and providing consumer notification of purchase transactions. Hammad, para. 5. 08. Hammad describes Dynamic CVV ("dCVV") as the generation of a verification value using information including a PAN (primary account number), an expiration date, a service code, and an automatic transaction counter. This verification value is transmitted from a merchant to a service provider (e.g., a payment processing organization or an issuer) where it is decoded and evaluated for possible approval. The automatic transaction counter keeps track of the number of times that a portable consumer device is used, and if there is a mismatch between a counter value that is received at the issuer and the counter at the issuer, then this may indicate possible data skimming or fraudulent use. Hammad, para. 68. 09. Hammad describes improving upon prior dCVV processes by generating different dynamic verification values using different data or different types of variable information. For example, more transaction and/or user specific data could be dynamically changed to verify that the portable consumer device is the correct one. This would be more secure than using just a simple counter. For example, specific information could include the following: Appeal 2020-005817 Application 14/474,787 8 terminal ID, time of day, telephone number, SIM card number, transaction amount, account number, service code (two digits), expiration date, current date, random numbers from the terminal, etc. The specific information preferably includes at least one dynamic data element such as a counter, time of day, purchase amount, etc. In other embodiments, the specific information used to create the dynamic verification value includes dynamic, consumer specific or transaction specific information such as the time of day when the transaction is taking place, the purchase amount, prior transaction data, etc. Any, some, or all of these may be used to create a verification value or other specific pieces of information could be dynamically altered to create a new dCVV. In one specific example, data regarding a prior transaction (e.g., a prior purchase amount, the time of a prior purchase, etc.) may be a dynamic data element, which may be used to authenticate a portable consumer device for future transactions. Hammad, para. 72. 10. Hammad describes data that is transmitted from a merchant to an issuer in a purchase transaction. The data fields include PAN, expiration date, service code, PIN CVV, and discretionary data fields. Hammad, para. 95. Dua 11. Dua is directed to 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. Dua, para. 2. Appeal 2020-005817 Application 14/474,787 9 12. Dua describes a wallet application that will log all transactions made in proximity, personal, or remote mode. The log will display information such as date/time, name of retailer/ organization, location ID, list of credentials used in the transaction, and purchase price (if transaction had a financial component). The purpose of this log is to allow a user to see what credential and personal information was shared with a third-party. User's need to be able to verify sometimes what personal information may have been shared during a specific transaction. This viewer allows the user to go back and view up to 6 months of transactions. In the case of financial transactions, the log entries will also have links to digital receipts (which are stored separately in the wallet application). Digital Receipts will be linked to log entries based on date/time stamp and credential matches (other criteria could also be used--for example, under one embodiment, the device generates a unique transaction ID which is transmitted with the credential to the merchant during each transaction. This ID could be contained in the digital receipt, and used by the wallet application to link the digital receipt with the log entries). Dua, para. 489. Bowman 13.Bowman is directed to selling of digital content over a computer network, and more particularly to a system which ensures more reliable delivery of digital content via a computer network. Bowman 1:25–27. Appeal 2020-005817 Application 14/474,787 10 14. Bowman describes transporting a digital content item between an order fulfillment server and a client computer by accepting a digital receipt from a user, presenting a choice of digital content for which the digital receipt is valid, accepting a request for a digital content item from the user, computing a first checksum of the digital content item at the order fulfillment server, transmitting the digital content item from the order fulfillment server to the client computer using a protocol capable or recovering from communication errors without the need to retransmit the entire digital content item, computing a second checksum of the digital content item at the client computer, and comparing the first checksum to the second checksum. Bowman 2:63–3:8. 15. Bowman describes the user selecting a specific digital content item, the digital content item is downloaded, a checksum of at least a portion of the digital content item used as a designated test portion and preferably of the entire digital content item is calculated at the client. A checksum of the file generated on the order fulfillment server is compared to the checksum computed in block 419 on the client computer. This important step verifies that digital content item which has been paid for by the use, has been received intact. Either the checksum generated on the client can be sent to the server which will perform the comparison or vice versa. A message digest algorithm such as MD5 offers almost complete assurance that the file received is perfectly correct. Bowman 8:29–58. Appeal 2020-005817 Application 14/474,787 11 ANALYSIS Claims 1, 3–10, 21, 23, 24, 26, 28, and 34–37 rejected under 35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, and Bowman We agree with Examiner that the recited combination of an account number identifier that indirectly specifies a financial account, a truncated counter value representing a number of transactions conducted by the electronic device, and a random number is non-functional descriptive material that is simply describing the data that is being used to generate the dynamic card verification value. As long as three different data values are used to generate the DCVV then that will read on this claim limitation because the claim does not provide any specifics on how the DCVV is generated based on the data. What those three different data values are named does not affect the generation of the DCVV. Ans. 5. While data per se applied to some computer process causes a functional effect on the computer and process, that data per se is an arbitrary pattern of bits based on unrecited encoding protocols and unrecited generating steps and structure. Informing one how to mentally interpret or label that bit pattern (what the Examiner refers to as what those three different data values are named) is itself of no functional consequence. The data label is not a limitation that can distinguish the claim from the art. The patentability issue devolves to whether the prior art describes the recited structure or function irrespective of how one labels the data. Our reviewing court has held that nonfunctional descriptive material cannot lend patentability to an invention that would have otherwise been anticipated by the prior art. In re Ngai, 367 F.3d 1336, 1339 (Fed. Cir. Appeal 2020-005817 Application 14/474,787 12 2004). Cf. In re Gulack, 703 F.2d 1381, 1385 (Fed. Cir. 1983) (noting that when descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from the prior art in terms of patentability). King Pharm., Inc. v. Eon Labs, Inc., 616 F.3d 1267, 1279 (Fed. Cir. 2010) (“[T]he relevant question is whether ‘there exists any new and unobvious functional relationship between the printed matter and the substrate.’”) (citations omitted). The rationale behind this lack of patentable weight is preventing the repeated patenting of essentially a known product by the mere inclusion of novel non-functional descriptive material. King Pharm., Inc, 616 F.3d at 1279) (“The rationale behind this line of cases is preventing the indefinite patenting of known products by the simple inclusion of novel, yet functionally unrelated limitations.”) Cf. In re Ngai, 367 F.3d 1336, 1339 (Fed. Cir. 2004) (“If we were to adopt Ngai’s position, anyone could continue patenting a product indefinitely provided that they add a new instruction sheet to the product.”). Here the process in no way depends on the actual mental interpretation of the account number identifier, truncated counter value, and random number, and the mental interpretation of such data is not dependent on the process. Were the recited data labels within data criteria to be given weight, an Applicant could obtain patents on the existing Hammad prior art described dynamic card verification value by simply applying differently labelled non-functional data. We are, however, persuaded by Appellant’s argument that “Bowman does not teach or suggest a second transaction identifier [that uniquely identifies the financial transaction] computed based on financial-account Appeal 2020-005817 Application 14/474,787 13 information transmitted to another electronic device.” Appeal Br. 12; Reply Br. 10. The Examiner responds that [t]he limitation as a whole recites “receive, from the computer system operated for the third party, receipt information associated with the financial transaction, wherein the receipt information comprises a second transaction identifier that uniquely identifies the financial transaction, wherein the second transaction identifier is computed based at least in part on the financial- account information transmitted to the other electronic device”. The claims are directed to the electronic device that receives receipt information from the third party computer system. The second transaction identifier is not computed by this electronic device and instead is generated by a separate device that is outside the scope of the claims. How the second transaction identifier is computed does not affect the limitations directed to the electronic device of the claims. Even assuming that this limitation should be given patentable weight, Bowman in Column 8, Ln 29 - Column 9, Ln 4 discloses that a checksum is generated by a server based on a digital content item and a checksum is generated by a client device based on the same digital content item. Therefore these checksums are generated by two separate entities using the same data and are then compared to make sure they match. Even though the data that is being generated in Bowman is a checksum generated using a digital content item and the data being generated in the pending application is a transaction identifier using transaction data, the checksums of Bowman are generated the same way as the transaction identifiers in this pending application. Ans. 6–7. The problem for the Examiner is that a checksum is far from unique. Instead, its relationship to the content from which it is derived is such that it is improbable that a different content would produce the same value, although this is possible. Rather than uniquely identifying content, it shows a high probability that the content is unaltered. The Examiner does Appeal 2020-005817 Application 14/474,787 14 not determine why one of ordinary skill would have substituted a unique identifier for Bowman’s checksum. The remaining claims depend from claim 1 or similar claim 21. Claim 2 rejected under 35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, Bowman, and Biere This claim depends from claim 1. Claim 30 rejected under 35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, Bowman, and Ronda This claim depends from claim 1. Claims 31–33 rejected under 35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, Bowman, and Pastusiak These claims depend from claims 1 and 21. CONCLUSIONS OF LAW The rejection of claims 1, 3–10, 21, 23, 24, 26, 28, and 34–37 under 35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, and Bowman is improper. The rejection of claim 2 under 35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, Bowman, and Biere is improper. The rejection of claim 30 under 35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, Bowman, and Ronda is improper. The rejection of claims 31–33 under 35 U.S.C. § 103(a) as unpatentable over Wentker, Hammad, Dua, Bowman, and Pastusiak is improper. Appeal 2020-005817 Application 14/474,787 15 CONCLUSION The rejection of claims 1–10, 21, 23, 24, 26, 28, and 30–37 is reversed. In summary: Claims Rejected 35 U.S.C. § Reference(s)/Basis Affirmed Reversed 1, 3–10, 21, 23, 24, 26, 28, 34–37 103 Wentker. Hammad, Dua, Bowman 1, 3–10, 21, 23, 24, 26, 28, 34–37 2 103 Wentker. Hammad, Dua, Bowman, Biere 2 30 103 Wentker. Hammad, Dua, Bowman, Ronda 30 31–33 103 Wentker. Hammad, Dua, Bowman, Pastusiak 31–33 Overall Outcome 1–10, 21, 23, 24, 26, 28, 30–37 REVERSED Copy with citationCopy as parenthetical citation