DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The response of 07/08/26 was received and considered. Claims 1-20 are canceled. Claims 21-40 are newly added.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because claims 1-20 are canceled and all new claims are added, the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 21 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,170,662. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the current application are anticipated by the claims of the ‘662 patent. See the chart below for comparison:
18/945,038
U.S. Patent No. 12,170,662
21. (New) A tangible, non-transitory, machine-readable medium storing instructions that when executed by one or more processors of a computer system effectuate operations comprising:
receiving, from a first computing device executing a user authentication process, a request to establish a user account record, the user account record including identifying information associated with the first computing device;
registering the first computing device to authenticate access to a web-based service from other computing devices;
associating, with the record, an identifier corresponding to an account of the user on the web-based service;
receiving, from a second computing device executing a client authentication process, user account or device identifying information;
identifying, based on the received user account or device identifying information, the user account record;
receiving, from the first computing device, an authentication request to access the web-based service from the second computing device; and
transmitting, to the second computing device, an authentication token indicative of the second computing device being permissioned to access the web-based service under the account of the user on the web-based service.
1. A tangible, non-transitory, machine-readable medium storing instructions that when executed by one or more processors of a computer system effectuate operations comprising:
storing a user account record indicative of a first computing device and first credentials by which a user authenticates on the first computing device;
receiving an indication of a user selection on the first computing device to register the first computing device to authenticate access to a webservice from other computing devices; associating, with the record, second credentials by which the user authenticates with the webservice;
identifying, based on user account or device identifying information received from a second computing device different from the first computing device, the record;
updating an indication of availability of the second computing device in association with the record;
receiving, from the first computing device, an authentication request to access the webservice from a selected available computing device and, in association with the authentication request, authentication data;
verifying the authentication data based on the first credentials to determine the user authenticated on the first computing device; and
transmitting, to the selected available computing device, based on the verifying, second authentication data by which the second computing device is permissioned to access the webservice.
Claims 21 and 40 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 12 and of U.S. Patent No. 10,939,295. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the current application are anticipated by the claims of the ‘662 patent. See the chart below for comparison:
18/945,038
U.S. Patent No. 10,939,295
21. (New) A tangible, non-transitory, machine-readable medium storing instructions that when executed by one or more processors of a computer system effectuate operations comprising:
receiving, from a first computing device executing a user authentication process, a request to establish a user account record, the user account record including identifying information associated with the first computing device;
registering the first computing device to authenticate access to a web-based service from other computing devices;
associating, with the record, an identifier corresponding to an account of the user on the web-based service;
receiving, from a second computing device executing a client authentication process, user account or device identifying information;
identifying, based on the received user account or device identifying information, the user account record;
receiving, from the first computing device, an authentication request to access the web-based service from the second computing device; and
transmitting, to the second computing device, an authentication token indicative of the second computing device being permissioned to access the web-based service under the account of the user on the web-based service.
1. A tangible, non-transitory, machine-readable medium storing instructions that when executed by a computer system effectuate operations comprising: establishing, by an application executing within a client execution environment of a first computing device, a set of credentials within a secure memory by a co-processor of a trusted execution environment of the first computing device, the co-processor being a different processor from a central processing unit of the first computing device; requesting, by the application, from the trusted execution environment, both: a first key of a key-pair corresponding to a second key of the key-pair maintained in the secure memory, and for at least one credential in a set of credentials by which a user authenticates to the first computing device, a representation generated within the trusted execution environment, wherein the representation is indicative of a value of the corresponding credential, and the representation does not reveal the value; transmitting, from the first computing device, the representation and the first key, or transmitting data corresponding to the representation and the first key, over a secure session to an authentication server to register the first computing device with the authentication server; receiving, by the application, a user selection to register the first computing device to a web-service to be accessed from a second computing device, wherein: the second computing device is different from the first computing device, and the authentication server is configured to identify sessions of the user with the second computing device to convey credentials received from the first computing device to the second computing device for presentation to a server associated with the web-service; obtaining, by the application, a registration value corresponding to the web-service and, from the trusted execution environment, data signed by the second key, the signed data being indicative of a result of user authentication on the first computing device; transmitting, from the first computing device, data including the registration value and the signed data to the authentication server to cause the authentication server to register the first computing device with the web-service based on authentication of the signed data and the registration value; and requesting, by the application, to the trusted execution environment, establishment of a credential value within the trusted execution environment corresponding to the web-service.
40. (New) A method, comprising: receiving, from a first computing device executing a user authentication process, a request to establish a user account record, the user account record including identifying information associated with the first computing device; registering the first computing device to authenticate access to a web-based service from other computing devices; associating, with the record, an identifier corresponding to an account of the user on the web-based service; receiving, from a second computing device executing a client authentication process, user account or device identifying information; identifying, based on the received user account or device identifying information, the user account record; receiving, from the first computing device, an authentication request to access the web-based service from the second computing device; and transmitting, to the second computing device, an authentication token indicative of the second computing device being permissioned to access the web-based service under the account of the user on the web-based service.
12. A computer-implemented method, executed by a server-side computing system that supports user initiated authentication on a mobile computing device to access a web-service from another computing device different from the mobile computing device, the method comprising: registering the mobile computing device having a trusted execution environment, the registering comprising: establishing a user record associated with a user of the mobile computing device, the user permitted to access a web-service from one or more second computing devices and the user record comprising a user identifier associated with the user; and establishing, in association with the user record, a record of the mobile computing device in response to receiving, from the mobile computing device, a set of representations corresponding to a set of credentials stored within the trusted execution environment on the mobile computing device and a signature verification key corresponding to a private key of the trusted execution environment; receiving, from the mobile computing device, a request to authorize the user to authenticate on the mobile computing device to access the web-service from one or more of the second computing devices and, in association with the request, first data indicative of a value; obtaining an authentication result indicative of authentication of the user to the web-service, the authentication result associated with an identifier; in response to identifying a correspondence between the value and the identifier, determining whether the user of the mobile computing device is permitted to authenticate on the mobile computing device to access the web-service from at least one of the second computing devices based on the user record; in response to determining the user of the mobile computing device is permitted to access the web-service from the at least one second computing device, transmitting a credential value and a policy associated with the web-service to the mobile computing device; receiving, from the mobile computing device, an authentication request to access the web-service from a second computing device and, in association with the authentication request, authentication data and signed data; identifying a given one of the second computing devices being permitted to access the web-service and having an active user session for the user; verifying the authentication data complies with the policy; verifying the authentication data was generated by the trusted execution environment and corresponds to the signed data based on the signature key; and transmitting, to the identified one of the second computing devices, based on the verifying, second authentication data and instructions to cause the second computing device to transmit the second authentication data to the web-service.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 21-31 and 3440 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Independent Claim 21:
Step 1: The claim recites a "tangible, non-transitory, machine-readable medium." This falls under a statutory category (Manufacture).
Step 2A (Prong 1): The claim is directed to the concept of authenticating a user and device to grant access to a service. Courts have consistently held that identity verification, authentication, and access control are fundamental economic practices and abstract ideas (methods of organizing human activity).
Step 2A (Prong 2): The claim uses generic computer components (a first computing device, a second computing device, a web-based service) to perform standard data transmission ("receiving," "registering," "identifying," "transmitting"). These computer components are performing conventional authentication operations and generic computing/network functions. Under current jurisprudence, using generic computer networks as a tool to execute an abstract idea does not constitute a practical application.
Step 2B: The steps recite well-understood, routine, and conventional activities: creating an account record, identifying a user, and sending an authentication token. Without reciting a specific, non-conventional technical implementation, this claim is ineligible.
Dependent Claims 22-39:
Claim 22 adds that the authentication token is "persisted" (stored) for subsequent use. Data storage and caching are generic computer functions. This does not add an inventive concept or practical application to overcome the abstract idea.
Claim 23 adds that the token is valid for multiple sessions and expires based on time or a logout event. Applying rules (time limits, expiration) is an abstract mental process and routine in token management.
Claim 24 adds transmitting the token based on satisfying a "policy." Evaluating data against rules or policies is a classic abstract idea. This fails to provide a technical improvement to the computer itself.
Claim 25 adds issuing a session and obtaining a "service-specific credential" from a "credentialing authority." This introduces third-party verification, which is a longstanding commercial/security practice performed via generic computer functions. The claim does not explain the technical mechanism by which the credentialing authority performs its function.
Claim 26, similar to 25, adds establishing a session "without requiring additional credential input from the user." This claims a desired result (frictionless login) without reciting a novel technological mechanism to achieve it. Desired results do not confer patent eligibility. The claim itself does not establish how the computer system technically achieves that result.
Claim 27 adds storing a credential in a "trusted execution environment" (TEE) and matching user input. While the matching is an abstract mental process, the recitation of a TEE provides a specific hardware-based security structure. However, a TEE is a known security component being used for the conventional purpose of authenticating a user. The claim does not specify how the TEE operates to add significantly more than the abstract idea.
Claim 28 adds verifying authentication based on a "plurality of credentials." Gathering and verifying additional data points is generic and conventional.
Claim 29 depends on 28, adding that the credentials comprise biometric input or a PIN verified in the TEE. Similar to claim 27, data gathering and matching is considered an abstract mental process. The TEE is conventional hardware performing conventional authentication.
Claim 30 adds transmitting a URL containing the token to redirect a browser. URLs and browser redirects are conventional, well-understood web technologies.
Claim 31 adds storing device identifying info and permissioning the first device to initiate requests for the second device. This is basic data organization and rule application (access control logic). Fails to add an inventive concept.
Claim 32 conditions the request on detecting a "proximity signal... over a local wireless interface." This introduces a specific physical, technical limitation (e.g., Bluetooth, NFC). This limitation ties the abstract idea of authentication to a specific physical relationship between hardware components, as a practical application improving local device security. This claim is eligible.
Claim 33 adds signing data using a private key governed by the TEE. Cryptography is typically viewed as an abstract mathematical concept. However, executing specific cryptographic steps tied to localized hardware (TEE) is tied to a specific technical solution to a security vulnerability. This claim is eligible.
Claim 34 adds constructing a token value and transmitting it via a URL. Data formatting (constructing a token) and standard web transmission (URL) are routine and conventional.
Claim 35 depends on 34, restricting the token presentation to a specific domain. Applying a domain-restriction rule is an abstract method of organizing human activity.
Claim 36 adds receiving credential data from an "enterprise identity management system." Retrieving data from a generic third-party server does not transform an abstract idea into a patent-eligible invention.
Claim 37 adds presenting the token to a plurality of web-based services (Single Sign-On). SSO is a well-known, abstract concept of centralized authentication. Executing it with generic tokens fails Step 2B.
Claim 38 adds presenting the token to a "service application" to access a resource. Generic interaction between software components.
Claim 39 recites "steps for logging-in the user... without entering a password." This is a purely functional, result-oriented limitation. Claiming the result of an abstract idea without the technological means to achieve it is patent-ineligible.
Independent Claim 40:
Step 1: The claim recites a "method, comprising..." This is a statutory category (Process).
Step 2A & 2B Analysis: Claim 40 contains the exact same steps as the CRM in Claim 21, simply phrased as a method rather than stored instructions. The § 101 analysis is identical to Claim 21. It is directed to the abstract idea of user/device authentication and relies on generic computing devices ("first computing device," "second computing device") to perform routine data reception, identification, and transmission. It lacks a specific technological improvement in the claim language itself.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 39 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 39 recites a negative limitation: "without entering a password on the computing device." Independent Claim 21 introduces a "first computing device" and a "second computing device." Because it is entirely ambiguous which of the two computing devices claim 39 refers to, this claim is indefinite.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 21-26, 30-31 and 34-40 are rejected under 35 U.S.C. 103 as being unpatentable over US 2016/0285633 to Allinson et al, and further in view of US 2019/0103968 to Srinivasan et al.
Regarding claim 21, Allinson teaches a tangible, non-transitory, machine-readable medium storing instructions that when executed by one or more processors of a computer system effectuate operations (Fig. 10 and paragraph 0077) comprising:
receiving, from a first computing device executing a user authentication process, a request to establish a user account record, the user account record including identifying information associated with the first computing device (0043-0044: a user registering a first device (smartphone) by sending an encryption key request comprising a username and push token to the service login management component);
registering the first computing device to authenticate access to a web-based service from other computing devices (0002 and 0045: registering the first device as having authorization to authenticate a user for accessing a service from a second device);
associating, with the record, an identifier corresponding to an account of the user on the web-based service (0044 and 0070: the database associating the push token and the first device’s registration with the user’s name/account);
receiving, from a second computing device executing a client authentication process, user account or device identifying information (0046: the second device (e.g. a smart television or PC) sending an access request to the login management component specifying the username and device authorization information/cookies);
identifying, based on the received user account or device identifying information, the user account record (0047: extracting the username from the access request and retrieving the associated push token/encryption key from the authorization database);
receiving, from the first computing device, an authentication request to access the web-based service from the second computing device (0048 and 0060: receiving an encrypted “login user authorization notification” from the first device after the user taps “yes” on the mobile interface to approve the login).
Allinson discloses “logging the user into the service on the second device” (0049) but lacks the explicit transmission of a standardized token.
However, Srinivasan teaches transmitting, to the second computing device, an authentication token indicative of the second computing device being permissioned to access the web-based service under the account of the user on the web-based service (0011, 0071, 0072: a token relay system, that upon backend validation of a client’s authority, transmits a standardized access token (e.g. an OAuth token issued by a token issuer authority) to a requesting non-confidential client/second device so it may access a protected web resource). It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the proprietary login execution of Allison by integrating the standardized token issuance and transmission architecture of Srinivasan. The motivation is to modernize the out of band (OOB) authentication system, transitioning it from reliance on proprietary session cookies to industry-standard OAuth tokens, which predictably enhances security, scalability, and interoperability, as taught by Srinivasan.
Regarding claim 22, Srinivasan further teaches the medium of claim 21, wherein the authentication token is persisted on the second computing device for use in a subsequent authentication to the web-based service during a session associated with the user account (0112: clients receiving access tokens may cache the access tokens for subsequent usage during a session).
Regarding claim 23, Srinivasan further teaches the medium of claim 21, wherein the authentication token is valid for a plurality of user sessions associated with the second computing device and expires based on a time duration or logout event (0113: “access tokens, by definition, have an associated expiration time” and is standard practice to “reuse” the access token obtained for a resource for accessing the same resource as long as the access token has not expired” across sessions).
Regarding claim 24, Srinivasan further teaches the medium of claim 21, wherein transmitting the authentication token to the second computing device is performed in response to determining that the authentication request satisfies a policy governing token issuance (0066-0069 and 0093-0094: evaluating token requests against access control policies, specifically verifying if the requesting client ID is permitted to request the specific token scopes configured by an administrator).
Regarding claims 25 and 26, Srinivasan further teaches the medium of claim 21, further comprising: issuing a session to the second computing device, the session corresponding to a credential obtained by the second computing device based on the user account record, the credential identifying a target service and permitting the second computing device to obtain a service-specific credential from a credentialing authority, wherein the service- specific credential is presented by the second computing device to the target service to establish a session under the user account:
issuing a session to the second computing device, the session permitting the second computing device to request, from a credentialing authority, a service-specific credential associated with the user account, wherein the second computing device presents the service-specific credential to a web-based service to establish a session under the user account without requiring additional credential input from the user (0004, 0062, 0068, 0076: the token relay system obtaining an OAuth access token (the service-specific credential) from the Identity Cloud Service/OAuth Server (the credentialing authority) to establish a session for a target REST service, performed silently without challenging the end-user for credentials).
Regarding claims 30 and 34, Srinivasan further teaches the medium of claim 21, wherein transmitting the authentication token to the second computing device comprises transmitting a uniform resource locator comprising the authentication token, the uniform resource locator operable to redirect a browser of the second computing device to the web-based service for access under the user account; wherein transmitting the authentication token to the second computing device comprises: constructing an authentication token value associated with the user account; and transmitting, to the second computing device, a uniform resource locator comprising the authentication token value, the uniform resource locator operable to initiate access to the web-based service under the user account (token relay logic executing in a browser environment (JavaScript applications). It is well known in the art (an an inherent feature of OAuth 2.0 flows described in Srinivasan) that access tokens or authorization codes are transmitted to the client application via URL query parameters or fragments during an HTTP redirect).
Regarding claim 31, Allinson, as modified above, teaches the medium of claim 21, wherein registering the first computing device to authenticate access to the web-based service from other computing devices comprises storing, in association with the user account record, device identifying information corresponding to the second computing device and permissioning the first computing device to initiate authentication requests on behalf of the second computing device based on the stored device identifying information (0046: storing device authorization information (e.g. cookies) on the second device and validating it to ensure the first device is registered and permissioned to authenticate it).
Regarding claim 35, Srinivasan further teaches the medium of claim 34, wherein: the authentication token value is specific to the second computing device based on identifying information received from the second computing device; and presentation of the authentication token value is restricted to a domain associated with the web-based service (0102-0108: enforcing Cross-Origin Resource Sharing (CORS) policies and Origin HTTP headers to whitelist specific domains, thereby restricting token presentation soley to the permitted domain associated with the client ID).
Regarding claim 36, Srinivasan further teaches the medium of claim 21, further comprising receiving, from an enterprise identity management system, credential data associated with the user account and storing a representation of the credential data in association with the user account record (0040, 0029: the token issuer authority being part of an enterprise security and access management system, specifically Oracle’s Identity Cloud Service (IDCS) which manages enterprise credentials and assertions)).
Regarding claim 37, Srinivasan further teaches the medium of claim 21, further comprising presenting the authentication token by the second computing device to a plurality of web-based services associated with the user account to establish sessions with each of the web-based services (0040, 0050: tokens for Single Sign On (SSO) environments where a client may use the tokens to securely access multiple distinct protected REST resources/services from a single page).
Regarding claim 38, Srinivasan further teaches the medium of claim 21, further comprising the second computing device to present the authentication token to a service application executing on the second computing device to access a web-based resource associated with the user account (0038: the second computing device executing a client application (e.g. a native media application or browser based JavaScript application).
Regarding claim 39, Allinson, as modified above, further teaches the medium of claim 21, the operations further comprising: steps for logging-in the user to the web-based service without entering a password on the computing device (0004: the exact functional result claimed, teaching logging the user into the service on the second device “without prompting the user to enter a password into the second device”).
As per claim 40, this is a method version of the claimed medium discussed above in claim 1 wherein all claimed limitations have also been addressed and/or cited as set forth above.
Claims 27-29 and 32-33 are rejected under 35 U.S.C. 103 as being unpatentable over US 2016/0285633 to Allinson et al, view of US 2019/0103968 to Srinivasan et al, and further in US 2019/0034621 to Mondello et al.
Regarding claim 27, Allinson lacks or does not expressly disclose a TEE. However, Mondello teaches storing, within a trusted execution environment of the first computing device, a representation of a user credential; and determining that the user is authenticated based on a match between the stored representation and user-supplied input (local biometric templates are securely stored and matched within an isolated hardware trusted execution environment (Secure Enclave) to present OS-level malware from extracting the biometric representation.).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Allinson, as modified above, with Mondello to include a trusted execution environment, in order to securely store credentials, as taught by Mondello.
Regarding claims 28-29, Allinson lacks or does not expressly disclose biometric. However, Mondello teaches comprising verifying authentication of the user on the first computing device based on a plurality of credentials supplied by the user; wherein the plurality of credentials supplied by the user comprise a biometric input or a personal identification number, the credential being verified against a corresponding stored representation within a trusted execution environment of the first computing device (0065, 0070: the first computing device (mobile device) performs local user authentication prior to releasing a credential, specifically verifying a combination of “biometric” (e.g. fingerprint, facial data, etc.) a user’s passcode, etc.)).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Allinson, as modified above, with Mondello to verify a biometric, in order securely authenticate, as taught by Mondello.
Regarding claims 32-33, Allinson lacks or does not expressly disclose biometric. However, Mondello teaches the medium of claim 21, wherein receiving the authentication request from the first computing device is conditioned on detecting, by the first computing device, a proximity signal from the second computing device over a local wireless interface (0059, 0068: a Discovery Phase (1002) and Pairing Phrase (1004) to establish a connection directly over a local wireless interface (e.g. Bluetooth, IR, Wi-Fi) between the mobile device and the media player device before credential sharing can proceed).
wherein: the authentication request includes signed data; and access to a private key by which data is signed is governed by authentication of the user on the first computing device upon credentials processed within a trusted execution environment (0069: generating a secure, encrypted channel (e.g. via Diffie-Hellman key exchange) predicated on the successful local authentication of the user on the mobile device)).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Allinson, as modified above, with Mondello to communicate a proximity signal, in order securely authenticate, as taught by Mondello.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AUBREY H WYSZYNSKI whose telephone number is (571)272-8155. The examiner can normally be reached M-F 9-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, ALI SHAYANFAR can be reached at 571-270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AUBREY H WYSZYNSKI/ Primary Examiner, Art Unit 2434
Prosecution Insights