Diego MatuteDownload PDFPatent Trials and Appeals BoardOct 22, 20212020005235 (P.T.A.B. Oct. 22, 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/334,981 07/18/2014 Diego Matute 20455P0002US02 7947 25319 7590 10/22/2021 Aventum IP Law LLP P.O. Box 13002 Kanata, ONTARIO K2K 0E2 CANADA EXAMINER PHAM, THIERRY L ART UNIT PAPER NUMBER 2674 MAIL DATE DELIVERY MODE 10/22/2021 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 DIEGO MATUTE Appeal 2020-005235 Application 14/334,981 Technology Center 2600 Before TREVOR M. JEFFERSON, AMBER L. HAGY, and MICHAEL J. ENGLE, Administrative Patent Judges. HAGY, Administrative Patent Judge. DECISION ON APPEAL STATEMENT OF THE CASE Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the Examiner’s decision to reject claims 1–20, which are all of the pending claims. See Final Act. 1–2; Appeal Br. 3. We have jurisdiction under 35 U.S.C. § 6(b). We affirm. 1 “Appellant” herein refers to “applicant” as defined in 37 C.F.R. § 1.42. Appellant identifies the real party in interest as the applicant, Diego Matute. Appeal Br. 3. Appeal 2020-005235 Application 14/334,981 2 CLAIMED SUBJECT MATTER The subject matter of the present application pertains to “a method for securing electronic transactions, and more particularly to a method for securing electronic transactions based on push notifications that prompt a user to confirm authentication via a mobile device.” Spec. ¶ 1. By way of background, the Specification describes how various entities, such as banks and social networks, require a “user to provide authentication information prior to allowing the user to compete an electronic transaction.” Id. ¶ 2. The Specification also describes such authentication in mobile systems, wherein the required authentication information may be a username and a password. Id. ¶ 5. The Specification notes, however, that if a “criminal acquires both the username/card number and password/PIN,” the criminal may obtain unauthorized access to the user’s account. Id. Appellant’s application purports to describe and claim a method for improving authentication for secure electronic transactions, in which a smartphone “is uniquely associated” with a user. Id. ¶ 22. If the user wants to access bank data, for example, the user sends a request to the bank server, such as via a computer. Id. The user also enters a username and password. Id. In response to a correct username/password combination, the server will transmit “a push notification to the application executing on” the user’s smartphone, and a “response is expected for the transaction to continue.” Id. The Specification notes that, because a push notification is sent to the user’s smartphone requiring a response for the transaction to continue, a criminal merely in possession of the user’s username and password, but not the user’s smartphone as well, will be unable to obtain unauthorized access to the user’s account. See id. ¶ 23. Appeal 2020-005235 Application 14/334,981 3 Claims 1, 10, 14, and 19 are independent. Claim 1, reproduced below, is representative: 1. A method comprising: associating a mobile electronic device with a first user; retrievably storing, by a first computer system, registration data relating to the first user and including a device identifier that is unique to the mobile electronic device associated with the first user; sending, by the first computer system, a push notification to the mobile electronic device, the push notification prompting the first user to provide a confirmation reply via a user interface of a security application for activating the mobile electronic device as a security token; and activating the mobile electronic device as a security token for the first user in response to receiving at the first computer system, from the mobile electronic device, the confirmation reply from the first user. Appeal Br. 16 (Claims App.). REJECTION Claims 1–20 stand rejected under 35 U.S.C. § 102(a)(2) as anticipated by Schultz et al., U.S. Patent App. No. 2013/0227651 A1, pub. Aug. 29, 2013 (“Schultz”). Final Act. 2–10. OPINION We have considered Appellant’s arguments (Appeal Br. 7–14; Reply Br. 1–3) in light of the Examiner’s findings and explanations (Final Act. 2– 10; Ans. 8–13). For the reasons set forth below, we are not persuaded of Examiner error in the rejection of the pending claims, and we, therefore, sustain the Examiner’s rejection. Appellant argues the Examiner’s finding of anticipation of all claims by Schultz is in error because Schultz fails to disclose a “push notification” Appeal 2020-005235 Application 14/334,981 4 sent by the first computer system. Appeal Br. 7. Rather, according to Appellant, in Schultz [t]he notification relating to authentication and provided by the detection module is provided from within the mobile device to an authentication process within the mobile device. The “push” referred to in the Official Action is from one process within the mobile device to another process within same mobile device. Such a “push” falls outside the limit of the recitations of the claims. Id. (emphasis added). Appellant further contends: The embodiment of [Schultz] specifically identified and relating to Figure 4G, involves an access system, wherein a mobile device detects proximity to the access point because the access point transmits a signal and prompts a user thereof for authentication information. It appears that the signal is generic and includes generic information transmitted from the access system for use by the mobile device, however, it is the mobile device that detects the generic signal and invokes the authentication and so forth. This is distinct from the claimed invention. The signal transmitted by the access point is also not a push notification within the teachings of the present application as it is not taught by [Schultz] that the signal is addressed to a unique mobile device. Id. at 8. Appellant also presents additional arguments specific to each of the independent claims, while arguing that the dependent claims are patentable for the reasons Appellant presents as to the independent claims. Id. at 10– 14. As for claims 1, 14, and 19, Appellant additionally argues the Examiner’s findings of anticipation by Schultz are in error because Schultz fails to disclose activating the mobile device as a security token for the user. Id. at 11, 13, 14. As for claim 10, Appellant additionally argues that the Appeal 2020-005235 Application 14/334,981 5 Examiner’s findings of anticipation by Schultz are in error because Schultz fails to disclose a “secondary authentication” of the user. Id. at 12. As for claim 14, Appellant additionally argues that Schultz fails to disclose a “security computer sending push notifications to [the] same mobile device for different transaction systems.” Id. at 13. We address Appellant’s contentions in turn below. A. “push notification” (independent claims 1, 10, 14, and 19) With regard to Appellant’s general argument that Schultz does not disclose “push notification[s],” as recited in all of the claims, the Examiner responds by stating that “push notifications” are interpreted as “notification prompts” that are “sent/transmitted/pushed from [a] resource provider to [a] user’s device (e.g. an example of user interface displayed on a user’s device display unit as shown in fig. 4G) requesting authentication from [the] user.” Ans. 8 (emphasis omitted). The Examiner finds Schultz discloses “push notifications” as claimed because Schultz discloses a server sending push notifications to a mobile device requesting authentication for multi-factor authentication. Final Act. 7 (citing Schultz ¶¶ 43, 51–56, Figs. 4f–4i); Ans. 8–10 (citing Schultz ¶¶ 27, 38, 81). We are not persuaded of Examiner error in finding that Schultz discloses “push notifications” as recited in Appellant’s claims. First, we determine the Examiner’s construction of “push notifications” as “notification prompts sent/transmitted/pushed from [the] resource provider to [the] user’s device . . . requesting authentication from [the] user” (Ans. 8) (emphasis omitted) is reasonable in light of the Specification. The Specification describes the invention as relating to a “method for securing electronic transactions based on push notifications that prompt a user to confirm authentication via a mobile device.” Spec. ¶ 1; see also id. ¶ 22 Appeal 2020-005235 Application 14/334,981 6 (describing a scenario in which, if the user enters the correct username and password in a request to access a resource, “the server transmits or causes to be transmitted a push notification to the application executing on smartphone 207, via WAN 203, indicating that someone is attempting to access user 201 bank data” and a “response is expected for the transaction to continue”). Second, we agree with the Examiner’s finding that Schultz discloses multi-factor authentication of a user of a mobile device in which notification prompts (push notifications) are sent to a user device requesting authentication (including biometric data). See Schultz ¶¶ 27, 28, 42, 43, 55– 56, 72–78, 81. In particular, Schultz discloses a system in which “a biometric authenticator 103 is configured to operate in connection with, e.g., the user device 101a (e.g., a mobile device) and/or various resources to permit the gathering and processing of multiple different types of biometric data.” Id. ¶ 17, Fig. 1.2 A user may be enrolled with the biometric authenticator by capturing certain physical, physiological, and behavioral characteristics via any suitable device (e.g., one having a microphone and/or camera). Id. ¶¶ 20, 21. The biometric authenticator may be employed as part of a secured access scheme, in which a user is prompted to respond to authentication questions according to the policies established by the provider of the resource: For the purpose of illustration, the biometric authenticator 103 may be employed in connection with a secured access scheme for an application or service 102 made available by a provider. In this scenario, the resource can be limited to being accessed only by those users whose voice and/or face (or other biometric) information may be authenticated as a result of 2 All bolding of reference numbers has been omitted herein. Appeal 2020-005235 Application 14/334,981 7 performing a biometric analysis. Per the resource polices 107c established by the provider of the resource, the user may be prompted to respond to one or a series of authentication questions, challenges, commands or tasks by way of their user device 101a. The response provided by the user is captured, via one or more sensors 117 of the device 101a, for compiling a set of voice, video or other data (e.g., still image data by way of an infrared light source), referred to herein as a response input. Id. ¶ 27. Schultz also discloses that the authentication process may include the biometric authenticator generating a message at the user interface of the user device requesting a response: In certain embodiments, the biometric authenticator 103 may generate a message at the user interface of the device 101a for requesting the user to provide biometric data response input per an authentication process. The message may be a request for the user to utter a security code or password, perform a specific facial gesture, repeat a phrase or random string of digits, vary the angle of image capture or orientation of the device, perform a series of movements about the user’s face, or a combination thereof. Id. ¶ 28 (emphasis added). Schultz also discloses that the authentication procedure may be triggered when the user travels with the user device to the proximity of a resource: [T]he authentication procedure may be invoked on demand, such as when the user travels from the location of one resource to another. By way of example, device interaction for triggering authentication may be facilitated via wireless link detection (e.g., Bluetooth, near field communication (NFC), Zigbee, Z-Wave) or a network connection between the resource to be accessed and the user device 101a. An application 119 at the user device 101a may facilitate the communication process, such as in response to a user request. Alternatively, the process may be triggered in response to a proximity/presence condition being fulfilled. It is noted that identifying information, such as a device identifier, may be exchanged during communication between the resource Appeal 2020-005235 Application 14/334,981 8 and the user device 101a for enabling the authentication procedure to commence. Id. ¶ 42 (emphasis added). Schultz’s biometric authenticator “may be offered by a service provider as a managed or hosted solution (e.g., as a cloud based service), as an integrated component of the user device 101a, or a combination thereof.” Id. ¶ 43. Thus, as described above, Schultz discloses an authentication procedure that is triggered, for example, when the user initiates a request or when the user’s device is detected as being within proximity of a resource for which access by the user is desired. Id. ¶ 42. The device may interact with the resource wirelessly via a user device and a biometric authenticator (which may act as an intermediary between the user device and the resource—see Fig. 1), and may exchange identifying information (such as a device identifier) for enabling the authentication procedure to commence. Id. ¶ 42. Schultz also discloses that a biometric authenticator may interact with the user device to prompt the user to input authentication information and to process that information to determine user access. Id. ¶¶ 27, 28, 43, 51–56, 81. As noted above, Appellant argues Schultz does not disclose “push notifications” as claimed because “[t]he ‘push’ referred to in the Official Action is from one process within the mobile device to another process within same mobile device.” Appeal Br. 7. We disagree. As the Examiner finds, and we agree, Schultz discloses “push notifications” as claimed because it discloses “[e]ach provider has its own protocols/procedures for authentications and level of authentications requirements. The policies/ protocols are stored/implemented at the providers, the ‘NOTIFICATIONS PROMPTS’ are then pushed/transmitted/ sent from the provider to the Appeal 2020-005235 Application 14/334,981 9 mobile device for further authentication (e.g. fingerprint, face recognition, passcode, and etc., known as two-factor authentication).” Ans. 8 (emphasis added) (citing Schultz ¶¶ 27, 38, 81); see also Final Act. 2 (citing Schultz Figs. 1–3, ¶¶ 51–56). The Examiner’s findings are supported by Schultz’s disclosure. Although Schultz discloses the biometric authenticator may, in an embodiment, be an integrated component of the user device, Schultz also discloses the authenticator may be a cloud-based service remote from the user device. Schultz, Fig. 1, ¶ 43. As illustrated in Figure 1, the user device may communicate with a biometric authenticator, which in turn may communicate with a resource (service 102) or security system 104. Id. ¶ 27. Schultz also discloses that the biometric authenticator may “generate a message at the user interface of the device,” which may be a request for the user to provide various forms of authentication (such as uttering a security code). Id. ¶ 28. Schultz further discloses that the system may perform “continual authentication,” such as requiring a user “to perform the authentication procedure every x minutes” after an initial authentication. Id. ¶ 39. In the case of a biometric authenticator separate from the user device, as noted above, Schultz teaches this process involves the biometric authenticator sending a notification prompt (push notification) to the user device to cause the user device to display a prompt for authentication information from the user. Thus, we are not persuaded of Examiner error in finding that Schultz discloses “push notifications” as recited in Appellant’s claims. B. “electronic device as a security token” (independent claims 1, 14, and 19) Appellant also argues the Examiner’s findings of anticipation of claims 1, 14, and 19 are in error because Schultz does not disclose Appeal 2020-005235 Application 14/334,981 10 “tokenization of the mobile device”—that is, “activating the mobile electronic device as a security token,” as recited in claims 1, 14, and 19. Appeal Br. 9, 11. We are not persuaded of Examiner error in the rejection. The Examiner finds Schultz discloses service providers implementing two-factor authentication, wherein a biometric authenticator generates a message at the user interface of the device requesting the user to provide biometric data to authenticate a transaction. Ans. 10–11 (citing Schultz ¶¶ 28, 38, 39). The Examiner also finds Schultz discloses a device identifier that is unique to the mobile electronic device. Final Act. 2, 4 (citing Schultz ¶ 42); Ans. 3, 5 (citing Schultz ¶¶ 42, 53, 72). In particular, Schultz discloses that device interaction may trigger authentication wirelessly such as where the user device fulfills a “proximity/presence condition” to the resource. Schultz ¶ 42. Schultz discloses that “identifying information, such as a device identifier, may be exchanged during communication between the resource and the user device 101a for enabling the authentication procedure to commence.” Id. Thus, Schultz discloses that if a particular smartphone (corresponding to a known device identifier) is within certain proximity of a secured resource, the authentication procedure will commence. Id. At that point, the biometric authenticator will generate a message at the mobile device requesting the user to provide a response to a command, question, or combination, for authentication purposes. Id. ¶ 70. Schultz’s disclosure of authentication via a mobile device (Schultz ¶¶ 27, 28, 42, 70) is consistent with the Specification’s description of creating a “tokenized smartphone” in which “the smartphone and the intended owner of the smartphone are both uniquely known and verified.” See Spec. ¶ 21. As described above, Schultz discloses identifying a mobile Appeal 2020-005235 Application 14/334,981 11 device by a device identifier and also describes a biometric authenticator (operating in accordance with an intended resource’s security policies) generating a message at the mobile device requesting the user to confirm the user’s identity. Schultz ¶¶ 27, 28, 42, 70. Thus, Schultz discloses that a smartphone and the intended owner of the smartphone are both uniquely known and verified through processes involving the smartphone, the user, and an intended resource. As such, we agree with the Examiner that Schultz discloses “activating the mobile electronic device as a security token,” as recited in claims 1, 14, and 19. Appellant’s argument in the Reply Brief that Schultz’s use of biometrics “makes the USER a token” is unavailing of Examiner error. See Reply Br. 2. Although Schultz’s system may be more complex than that described in Appellant’s claims—requiring additional biometric data beyond a simple confirmation of the transaction—this added complexity does not remove Schultz’s disclosure from the broad scope of Appellant’s claims. That is, Appellant’s claims recite merely that a “confirmation reply” from the user is required, and, as such, the claims do not exclude biometrics as part of the confirmation reply. C. “secondary authentication” (claim 10) With regard to claim 10, Appellant contends the Examiner’s anticipation rejection based on Schultz is in error because: Nowhere in [Schultz] is it taught, “subsequent to authenticating the first user, requesting by the first system to the second system a secondary authentication of the first user; sending from the second system to the uniquely identifiable mobile electronic device a push notification prompting the first user to provide a secondary authentication response via the uniquely identifiable mobile electronic device.” As such, claim 10 cannot be anticipated by Schultz. Appeal 2020-005235 Application 14/334,981 12 Appeal Br. 12. Other than the naked assertion that Schultz fails to disclose the recited limitation (id.), Appellant does not sufficiently address the Examiner’s findings, e.g., explain why Schultz’s disclosure, as cited by the Examiner (see Final Act. 4–5; Ans. 10–13), fail to disclose the claimed limitation. Appellant has, therefore, not rebutted the Examiner’s findings. See In re Lovin, 652 F.3d 1349, 1357 (Fed. Cir. 2011) (“[W]e hold that the Board reasonably interpreted Rule 41.37 to require more substantive arguments in an appeal brief than a mere recitation of the claim elements and a naked assertion that the corresponding elements were not found in the prior art.”). D. “different transaction systems” (claim 14) With regard to claim 14, Appellant additionally argues that “nowhere in [Schultz] is there disclosure of a security computer sending push notifications to a same mobile device for different transaction systems, a first transaction system and a second transaction system.” Appeal Br. 13. Again, other than the naked assertion that Schultz fails to disclose the recited limitation (id.), Appellant does not sufficiently address the Examiner’s findings, e.g., explain why Schultz’s disclosure, as cited by the Examiner (see Final Act. 5–6; Ans. 10–13), fail to disclose the claimed limitation. Appellant has, therefore, not rebutted the Examiner’s findings. See In re Lovin, 652 F.3d at 1357. E. Conclusion For the foregoing reasons, we are not persuaded of Examiner error in the rejection of independent claims 1, 10, 14, and 19, and we, therefore, sustain that rejection, along with the rejection of the dependent claims, which are all argued collectively with their respective independent claims. See Appeal Br. 8–14. Appeal 2020-005235 Application 14/334,981 13 CONCLUSION The Examiner’s anticipation rejection of claims 1–20 is sustained. DECISION SUMMARY In summary: Claim(s) Rejected 35 U.S.C. § Reference(s)/Basis Affirmed Reversed 1–20 102(a)(2) Schultz 1–20 TIME PERIOD FOR RESPONSE No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. § 1.136(a)(1)(iv). AFFIRMED Copy with citationCopy as parenthetical citation