Talmor, Eli et al.Download PDFPatent Trials and Appeals BoardMar 21, 20222022000816 (P.T.A.B. Mar. 21, 2022) 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. 16/233,217 12/27/2018 Eli Talmor 6393 125833 7590 03/21/2022 Eli Talmor Finland 7a Haifa, 3498927 ISRAEL EXAMINER BROWN, SHEREE N ART UNIT PAPER NUMBER 3649 MAIL DATE DELIVERY MODE 03/21/2022 PAPER 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. PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ Ex parte ELI TALMOR and RITA TALMOR ____________ Appeal 2022-000816 Application 16/233,217 Technology Center 3600 ____________ Before DANIEL S. SONG, MICHELLE R. OSINSKI, and MICHAEL L. WOODS, Administrative Patent Judges. OSINSKI, Administrative Patent Judge. DECISION ON APPEAL STATEMENT OF THE CASE Appellant1 appeals under 35 U.S.C. § 134(a) from the Examiner’s decision rejecting claims 1-20. We have jurisdiction over the appeal under 35 U.S.C. § 6(b). We REVERSE. 1 We use the term “Appellant” to refer to “applicant” as defined in 37 C.F.R. § 1.42. Appellant identifies Eli Talmor and Rita Talmor as the real parties in interest. Appeal Br. 2. Appeal 2022-000816 Application 16/233,217 2 THE CLAIMED SUBJECT MATTER Claims 1 and 11 are independent. Claim 1 is reproduced below. 1. A method for securing blockchain transactions in real-time, comprising; identifying a user, sending said transaction, in real-time, using personally identifiable endpoint devices, and hardware and software-based identification-as-a-service, resulting in storing said identification in database memory; integrating computer-based wallet, performing cryptographic functions for signing blockchain transactions and said identification, using said identification-as-a-service, wherein integration results in said identification being part of said cryptographic functions and said blockchain transactions; calculating, in real-time, the user’s private key using said wallet and said identification-as-a-service, wherein said private key is re-created every time said wallet is opened or initialized; applying said user’s private key to sign a transaction using an application, performing a specific activity, and linked to said wallet application; storing said transaction in a blockchain ledger memory, performing storage of transactions and records, and linked to said application. REFERENCES The prior art relied upon by the Examiner is: Name Reference Date Spencer US 2016/0125416 A1 May 5, 2016 Sheng US 2017/0109735 A1 Apr. 20, 2017 THE REJECTION2 Claims 1-20 stand rejected under 35 U.S.C. § 103 as unpatentable over Sheng and Spencer. Final Act. 6-11. 2 Rejections of claims 11-20 under 35 U.S.C. § 112(a) as failing to comply with the written description requirement (Final Act. 3-4) and claims 1-20 Appeal 2022-000816 Application 16/233,217 3 OPINION The Examiner finds that Sheng teaches most of the limitations of independent claim 1, including, among other things, (i) the step of using personally identifiable endpoint devices and hardware and software-based identification-as-a-service, resulting in storing identification in database memory; (ii) the step of integrating a computer-based wallet that results in the identification being part of the cryptographic functions and blockchain transactions performed by the computer-based wallet; and (iii) the step of calculating the user’s private key using the wallet and the identification-as-a- service. Final Act. 7-8. As to using personally identifiable endpoint devices, the Examiner points to Sheng’s teachings in paragraph 430. Ans. 8; see also Sheng ¶ 430 (referring to “Chromebooks,” “netbooks, tablets,” “mobile smartphones”). As to using hardware and software-based identification-as-a-service, the Examiner points to Sheng’s teaching of a user inputting identification information into a web form, and “[t]he user’s inputs are then prepared for transmission to the SOCOACT [(Computationally Efficient Transfer Processing, Auditing, and Search Apparatuses, Methods, and Systems)] Controller . . . which is [equivalent] to the Appellant’s teachings of ‘using said identification-as-a-service.” Ans. 4-5 (citing Sheng ¶ 149). The Examiner further points to Sheng’s teaching of “a virtual currency transaction process between a buyer and a seller using the SOCOACT.” Sheng ¶ 177 (cited at Ans. 8). Paragraph 177 continues that “[a]t a commencement of the process, a buyer (i.e., a payer) requests registration under 35 U.S.C. § 112(b) as being indefinite (id. at 4) are moot following Appellant’s amendments to the claims. Amend. (Dec. 2, 2018), 3, 5. Appeal 2022-000816 Application 16/233,217 4 with the SOCOACT system (step 801)” and “[i]n response, the SOCOACT serves a registration form for completion by the buyer (step 804).” Id. Paragraph 177 further adds that “[t]he registration form may include an identification of the buyer, the buyer[’]s wallet, and a source of funds to be established in the wallet.” Id. As to the step of integrating a computer-based wallet that results in the identification being part of the cryptographic functions and blockchain transactions performed by the computer-based wallet, the Examiner relies on Sheng’s paragraphs 115, 438, 129, 157, 160, 161, and 163 as teaching a computer-based wallet that performs cryptographic functions for signing blockchain transactions. Ans. 3-4; see Final Act. 7 (citing to Sheng’s paragraphs 115, 438, 157, 390, 103, 113-115, 124-129, and 327 in connection with the claim limitation relating to integration). The Examiner also states that “Sheng’s teachings of ‘verify the signatures to verify the chain of ownership’ in [p]aragraph 0157 [and] 0390 discloses the Appellant’s claim language of ‘wherein said integration results in said identification.’” Ans. 5. In response to Appellant’s argument that Sheng does not mention “using identification as being part of the cryptographic function”(Appeal Br. 12), the Examiner states that “Sheng’s [p]aragraph 0228 discloses ‘blockchain functionality is based upon elliptic curve cryptography, where addresses are derived from elliptic-curve public keys and transactions authenticated using digital signatures.’” Ans. 9. The Examiner also states that Sheng’s paragraph 164 teaches “A private key in the context of virtual currency is a secret number that allows a denomination[] of the virtual currency to be spent. Every address within a wallet has a matching private key, which is usually saved in the wallet file of the person who Appeal 2022-000816 Application 16/233,217 5 owns the balance, but may also be stored using other means and methods. The private key is mathematically related to the address, and is designed so that the address can be calculated from the private key while, importantly, the reverse cannot be done.” Id. at 9-10. The Examiner states that “[t]he [E]xaminer maintains Sheng’s paragraphs 0228 and 0164 discloses . . . Appellant’s claim language.” Id. at 10. As to calculating the user’s private key using the wallet, the Examiner points to Sheng’s teaching in paragraph 164. Final Act. 8. Notably, the Examiner fails to identify any paragraph in Sheng with respect to the portion of the claim requiring the calculation of the private key to also be done using the identification-as-a-service. Id. The Examiner acknowledges that Sheng fails “to explicitly disclose wherein said private key is re-created every time said wallet is opened or initialized.” Id. at 6. The Examiner finds that Spencer teaches “identification as a service, wherein said private key is re- created every time said wallet is opened or initialized.” Id. at 6-7 (citing Spencer ¶¶ 13, 41, 74). The Examiner concludes that it would have been obvious to have modified Sheng’s method “by the teachings of Spencer to enable improved security for transactions such as transactions on the internet, and in particular[,] provide methods for authenticating a user for performing a transaction, more effectively.” Id. at 7 (citing Spencer ¶ 5). Despite the finding that Spencer teaches “identification as a service” (id. at 6-7), the Examiner explains only how Spencer is relied on for teaching the portion of the claim limitation relating to re-creation of a private key every time the wallet is opened or initialized, but provides no further details regarding identification-as-a-service purportedly being taught by Spencer (Final Act. 6-7; Ans. 5, 11, 12). Appeal 2022-000816 Application 16/233,217 6 Assuming arguendo that Sheng’s SOCOACT Controller identifies a user using hardware and software-based identification-as-a-service to result in storing an identification in database memory (Ans. 4-5 (the Examiner finding the SOCOACT Controller to be equivalent to using identification-as- a-service)) and also assuming arguendo that a computer-based wallet is integrated with Sheng’s SOCOACT Controller to result in the identification being part of cryptographic functions and blockchain transactions (Final Act. 7 (citing, e.g., Sheng ¶¶ 124-129)), the Examiner fails to explain adequately how the identification-as-a-service is used in a manner to meet an additional limitation in claim 1. In particular, with respect to the limitation of “calculating . . . the user’s private key using said wallet and said identification-as-a-service, wherein said private key is re-created every time said wallet is opened or initialized” (Appeal Br. 24 (Claims App.) (emphasis added)), Appellant argues that claim 1 clearly requires the identification-as-a-service to be used to calculate the user’s private key. Reply Br. 4. Appellant then argues that “[both] Sheng and Spen[c]er are using random number generation of Private Key. . . . None of them or a combination of them uses Identification-as-a- Service to generate a private key.” Id. at 8 (emphasis omitted). Appellant further states that, in Sheng, “identification-as-a-service is not explicitly used to calculate private keys in real-time.” Id. at 11 (emphasis omitted). More particularly, Appellant looks at the portions of the prior art identified by the Examiner (Final Act. 6-8; Ans. 5) in connection with the step of calculating the user’s private key using the wallet and the identification-as-a-service-namely, paragraph 164 of Sheng and paragraphs 13, 41, and 74 of Spencer. Appeal Br. 14-15. Appellant states Appeal 2022-000816 Application 16/233,217 7 that Sheng’s paragraph 164 is merely “the common knowledge definition of a private key.” Id. at 15; see also Reply Br. 10-11 (emphasis omitted) (“These paragraphs [(including Sheng’s paragraph 164)] are common- knowledge facts known to anyone skilled in the art” and “[n]one of these quotes [from these paragraphs] discloses [Appellant’s] [c]laim language.”). The reference to the description of a private key in Sheng’s paragraph 164 (e.g., “[a] private key in the context of virtual currency is a secret number that allows a denomination[] of the virtual currency to be spent” and “[e]very address within a wallet has a matching private key, which is usually saved in the wallet file of the person who owns the balance”) lacks an adequate explanation from the Examiner as to how these general teachings of a private key disclose or render obvious the more particular claim language that the calculation of the user’s private key be done using the identification-as-a-service. As to the descriptions in Spencer’s paragraphs 13, 41, and 74 identified by the Examiner, these descriptions relate to the feature of the private key being generated for every transaction. Spencer ¶¶ 13, 41, 74. Again, the reference to these descriptions of a private key lacks an adequate explanation from the Examiner as to how these teachings of the particular feature that the private key be generated for every transaction disclose or render obvious the particular claim language that the calculation of the user’s private key be done using the identification-as-a-service in addition to the wallet every time the wallet is opened or initialized. The Examiner has also not explained adequately how Sheng is modified in accordance with the teachings of Spencer in the articulated rejection (Final Act. 7) in order to establish that the combination teaches the claimed step of calculating the Appeal 2022-000816 Application 16/233,217 8 user’s private key using the identification-as-a-service, wherein the private key is re-created every time the wallet is opened or initialized. In short, the Examiner has not supported adequately a finding that the combination of Sheng and Spencer teaches the claimed step of “calculating, in real time, the user’s private key using said wallet and said identification-as-a-service, wherein said private key is re-created every time said wallet is opened or initialized.” For the foregoing reasons, Appellant apprises us of error in the Examiner’s determination that the combination of Sheng and Spencer renders obvious the subject matter of claim 1. Accordingly, we do not sustain the rejection of claim 1, or claims 2-10 depending therefrom, under 35 U.S.C. § 103 as unpatentable over Sheng and Spencer. We also do not sustain the rejection of claim 11 which is “rejected on the same basis as claim[] 1” (Final Act. 11), or claims 12-20 depending therefrom, under 35 U.S.C. § 103 as unpatentable over Sheng and Spencer. CONCLUSION The Examiner’s rejection is reversed. DECISION SUMMARY In summary: Claims Rejected 35 U.S.C. § Reference(s)/Basis Affirmed Reversed 1-20 103 Sheng, Spencer 1-20 REVERSED Copy with citationCopy as parenthetical citation