DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the Amendment filed on 01/26/2024.
In the instant Amendment: Claims 1-4, 14-16 have been amended and claims 1 and 14 are independent claims. Claims 1-4, 7-10, 13-16, 18-20 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Rejection under 35 U.S.C. 112(b) is withdrawn in response to amendment.
Applicants’ arguments with respect to amended claims 1 and 14 have been considered but are moot in view of the new ground(s) of rejection. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
Claim Rejections - 35 USC § 103
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 discloses as set forth in section 102 of this title, 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 1-3, 6-7, 10, 14, 15, 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Jurss et al. (“Jurss,” US 20240405994, filed Sept. 19, 2022) in view of Van Cleve et al. (“Van Cleve,” US 20230308277, filed Aug. 26, 2021).
Regarding claim 1, Jurss discloses A method for operating an electronic device, the method comprising:
storing, by a first application, a first authentication value of the first application in a storage area, the first application having a first digital signature capable of accessing the storage area (Jurss [0034], [0072], [0074], [0125]. A mobile application 22 can be installed on the mobile device 20 which can be serviced by a mobile application server 30. The mobile application 22 can have an in-application SDK 40 which can communicate directly with a processing computer 50. In step S20, after receiving nonce and the signed nonce from the processing computer 50, the in-application SDK 40 make the nonce and the signed nonce available to the mobile device 20. In step S24, after the user 10 selects a user device, the mobile device 20 can transmit a get encrypted payload message comprising the nonce, the signed nonce, an access credential identifier for the selected user device, and an application identifier for the mobile application server 30. The get encrypted payload message can be a request for the main credential and additional data associated with the main credential of the selected user device. The mobile device 800 may comprise a processor 802, which may be coupled to a memory 804, a network interface 806, a computer readable medium 808, and a display 810.);
transmitting, by the first application, a function execution request including a second authentication value to a [second application] (Jurss [0074]. In step S24, after the user 10 selects a user device, the mobile device 20 can transmit a get encrypted payload message comprising the nonce, the signed nonce, an access credential identifier for the selected user device, and an application identifier for the mobile application server 30. The get encrypted payload message can be a request for the main credential and additional data associated with the main credential of the selected user device.);
identifying a second digital signature of the [second application] based on identifying a request for the [second application] to access the storage area; based on the second digital signature corresponding to the first digital signature, allowing the [second application] to access the storage area (Jurss [0052], [0075]. In step S208A, after receiving the credential identifier, the processing computer 50 can access a service provider database 72 using the credential identifier to retrieve the main credential and additional data associated with the main credential. The service provider database 72 can store a mapping between main credential identifiers and main credentials/additional data. In step S26, after receiving the get encrypted payload message, the mobile application server 30 can retrieve the one or more of the data elements. The mobile application server 30 can then verify the signed nonce using the one or more data elements. For example, the mobile application server 30 can retrieve the verification key in the data elements to verify the digital signature on the signed nonce. After verifying the signed nonce, the mobile application server 30 can generate a payload comprising an access credential identifier (e.g., as described in FIG. 2 , an access credential identifier can be an encrypted primary account number (PAN) or a credential identifier that uniquely identifies the user device can be used), and an expiration date.);
performing, [by the second application], authentication on the first application based on the first authentication value identified [by the second application] in the storage area and the second authentication value included in the function execution request (Jurss [0075]. [0109]. In step S26, after receiving the get encrypted payload message, the mobile application server 30 can retrieve the one or more of the data elements. The mobile application server 30 can then verify the signed nonce using the one or more data elements. For example, the mobile application server 30 can retrieve the verification key in the data elements to verify the digital signature on the signed nonce. After verifying the signed nonce, the mobile application server 30 can generate a payload comprising an access credential identifier (e.g., as described in FIG. 2 , an access credential identifier can be an encrypted primary account number (PAN) or a credential identifier that uniquely identifies the user device can be used), and an expiration date. For example, the second platform computer 58 can compare the OTP in the OTP payload to the OTP generated in step S72 and determine if they are the equal.); and
based on the performing the authentication, performing, [by the second application], a function corresponding to the function execution request (Jurss [0075]. In step S26, after receiving the get encrypted payload message, the mobile application server 30 can retrieve the one or more of the data elements. The mobile application server 30 can then verify the signed nonce using the one or more data elements. For example, the mobile application server 30 can retrieve the verification key in the data elements to verify the digital signature on the signed nonce. After verifying the signed nonce, the mobile application server 30 can generate a payload comprising an access credential identifier (e.g., as described in FIG. 2 , an access credential identifier can be an encrypted primary account number (PAN) or a credential identifier that uniquely identifies the user device can be used), and an expiration date.),
wherein data regarding the first application is stored in a partial area of an entire storage area in a memory of the electronic device (Jurss [0021], [0033]. An “application” may be computer code or other data stored on a computer readable medium (e.g. memory element or secure element) that may be executable by a processor to complete a task. In embodiments of the invention, a method can be performed by a mobile device comprising a processor, a memory, and a display coupled to the processor.),
wherein the partial area includes a first area and a second area (Jurss [0126]. The memory 804 may be coupled to the processor 802 internally or externally (e.g., via cloud-based data storage), and may comprise any combination of volatile and/or non-volatile memory such as RAM, DRAM, ROM, flash, or any other suitable memory device. The memory 804 can store the mobile application, and data relating to the mobile application.), and
wherein the storage area is included in the first area (Jurss [0034], [0126]. A mobile application 22 can be installed on the mobile device 20 which can be serviced by a mobile application server 30. The memory 804 may be coupled to the processor 802 internally or externally (e.g., via cloud-based data storage), and may comprise any combination of volatile and/or non-volatile memory such as RAM, DRAM, ROM, flash, or any other suitable memory device. The memory 804 can store the mobile application, and data relating to the mobile application.).
Juress does not explicitly disclose: a second application, and
wherein the first area is an area accessible by the at least one application having the same digital signature as the first digital signature, and the second area is an area accessible by all applications.
However, in analogous art, Van Cleve discloses a method, comprising the steps of: a second application, and wherein the first area is an area accessible by the at least one application having the same digital signature as the first digital signature, and the second area is an area accessible by all applications (Van Cleve [0042], [0079], [0193]. The attestation token can be digitally signed by the attestation token issuing server using a private key that the attestation token issuing server keeps confidential. A public key that corresponds to this private key can be provided to the recipient system…by verifying the digital signature of the attestation token using the public key. In step A, the application 111 can generate a request 120 for one or more attestation tokens and provide the token request 120 to a trusted program 114. For example, the application 111 can be a web browser through which a user of client device 110 is accessing various websites, such as website 140, and/or requesting access to or content from various resources such as resource 145, publishers 130, and content platform 150, among other entities. In this example, the trusted program 114 can be an application on the client device 110 that is trusted by the entity from which the application 111 is requesting resources or to which the application 111 is requesting access. In one example, trusted program 114 can be an application created and hosted by Example News Organization for the smartphone, and the user may be requesting access through a news aggregator on web browser 111 to a news article on website 140 hosted by Example News Organization. [See [0124]. In step J, website 140 attempts to verify the SRR provided in the access request. If website 140 can verify the SRR, website 140 can provide access to the portion of the website 140 indicated in the access request 125 or provide access to the resource 145 requested.] The apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system [i.e., part of stored codes or files that are accessible by both application 111 and 114.]. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine teachings of Van Cleve and Jurss to include the step of: a second application, and wherein the first area is an area accessible by the at least one application having the same digital signature as the first digital signature, and the second area is an area accessible by all applications. One would have been motivated to provide users with a means for a web-browser application to authenticate itself to other applications installed on the mobile device and access requested contents. (See Van Cleve [0127].)
Regarding claim 2, Jurss and Van Cleve disclose the method of claim 1. Van Cleve further discloses: wherein the function execution request includes information about a storage path of the first authentication value (Van Cleve [0145]-[0146]. Having obtained a batch of attestation tokens, as illustrated in the example of FIG. 2 , the client device can use the attestation tokens to assemble and send attestation tokens as part of various requests heading toward websites, content publisher domains, or other attestation token recipients, as discussed above. To prepare a request, an application 300 can retrieve an attestation token from local storage of the application (301). Thus, the application 300 can retrieve an attestation token based on the application or website for which the request is generated or the current time at which the request is generated.).
The motivation is the same as that of claim 1 above.
Regarding claim 3, Jurss and Van Cleve disclose the method of claim 1. Van Cleve further discloses
wherein identifying the request for the second application to access to the storage area includes: identifying a specified access path for the second application (Van Cleve [0146]. To prepare a request, an application 300 can retrieve an attestation token from local storage of the application (301). Thus, the application 300 can retrieve an attestation token based on the application or website for which the request is generated or the current time at which the request is generated.); and
identifying the storage area among areas accessible through the specified access path (Van Cleve [0146], [0175]. To prepare a request, an application 300 can retrieve an attestation token from local storage of the application (301). Thus, the application 300 can retrieve an attestation token based on the application or website for which the request is generated or the current time at which the request is generated. To prepare a request, the application 500 can retrieve a signed redemption result, e.g., from a secure cache of the application (501).)
The motivation is the same as that of claim 1 above.
Regarding claim 7, Jurss and Van Cleve disclose the method of claim 1. Van Cleve further discloses wherein performing the function corresponding to the function execution request by the second application includes providing data regarding the function to the first application by the second application (Van Cleve [0101], [0127]. For example, if a user of client device 110 attempts to access a feature to add a custom background to their profile on Example Social Media Website 140, Example Social Media Website 140 may request validation from application 111 prior to granting access to the feature. In one particular example, the trusted program 114 is a mobile application installed on client device 110, a user's smartphone, and is Example News Organization's official trusted application. The application 111 is a web browser installed on client device 110, and website 140 is Example News Organization's official website. A user who is a subscriber of Example News Organization and is signed on to Example News Organization's application 114 and wishes to access content on Example News Organization's official website 140 on client device 110 can have a seamless browsing experience. For example, web browser 111 can generate a token request and provide the request to Example News Organization application 114. Upon receiving and verifying user's credentials and/or the request 121, ATI server 170 can issue attestation token 122 to the web browser 111. The attestation token 122 can be stored in a secure cache of web browser 111.).
The motivation is the same as that of claim 1 above.
Regarding claim 10, Jurss and Van Cleve disclose the method of claim 1. Jurss further discloses wherein the first authentication value includes a value randomly generated according to a time when the first authentication value is generated (Jurss [0099]. The OTP can be a string of random or pseudorandom characters that is used to authenticate the user 10 for the request to view the main credential and the additional data associated with the main credential.).
Regarding claim 14, claim 14 is directed to a device corresponding to the method of claim 1. Claim 14 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed to a device corresponding to the method of claim 3. Claim 15 is similar to claim 3 and is therefore rejected under similar rationale.
Regarding claim 18, Jurss and Van Cleve disclose the device of claim 14. Jurss further discloses wherein the specified digital signature includes the first digital signature including a digital signature of the first application (Jurss [0074]. In step S24, after the user 10 selects a user device, the mobile device 20 can transmit a get encrypted payload message comprising the nonce, the signed nonce, an access credential identifier for the selected user device, and an application identifier for the mobile application server 30.).
Regarding claim 19, Jurss and Van Cleve disclose the device of claim 18. Van Cleve further discloses wherein at least one processor, individually or collectively, is configured to provide a data response including data corresponding to the function execution request of the first application (Van Cleve [0079]. In step A, the application 111 can generate a request 120 for one or more attestation tokens and provide the token request 120 to a trusted program 114. For example, the application 111 can be a web browser through which a user of client device 110 is accessing various websites, such as website 140, and/or requesting access to or content from various resources such as resource 145, publishers 130, and content platform 150, among other entities. In this example, the trusted program 114 can be an application on the client device 110 that is trusted by the entity from which the application 111 is requesting resources or to which the application 111 is requesting access. In one example, trusted program 114 can be an application created and hosted by Example News Organization for the smartphone, and the user may be requesting access through a news aggregator on web browser 111 to a news article on website 140 hosted by Example News Organization. [See [0124]. In step J, website 140 attempts to verify the SRR provided in the access request. If website 140 can verify the SRR, website 140 can provide access to the portion of the website 140 indicated in the access request 125 or provide access to the resource 145 requested.]).
The motivation is the same as that of claim 14 above.
Claims 4, 8, 13, 16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jurss et al. (“Jurss,” US 20240405994, filed Sept. 19, 2022) in view of Van Cleve et al. (“Van Cleve,” US 20230308277, filed Aug. 26, 2021) and Poliashenko et al. (“Poliashenko,” US 20120291114, published Nov. 15, 2012).
Regarding claim 4, Jurss and Poliashenko disclose the method of claim 1.
Jurss and Van Cleve do not explicitly disclose: wherein data regarding an application other than the first application is not stored in the data storage area.
However, in an analogous art, Poliashenko further discloses wherein data regarding an application other than the first application is not stored in the data storage area (Poliashenko [0040]-[0041], [0045]. App A 216 may then send the request ID directly to app B 220 (block 310). The SSO service 218 may determine if app B 220 has previously stored mapping information on which user id in app A corresponds to which user id in app B (block 314). The SSO service 218 will, when available, return a mapping token to app B 220 (block 324), as well as any payload deposited at the SSO service 218 during the request process. The mapping token will typically also include information originally supplied by app B as discussed at block 320 Such information may include a hash of the user's current password or another additional data app B wishes to store.)
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine teachings of Poliashenko, Van Cleve and Jurss to include: wherein data regarding an application other than the first application is not stored in the data storage area. One would have been motivated to provide users with a means for validating and enabling single sign-on functions across a plurality of applications. (See Poliashenko [0047].)
Regarding claim 8, Jurss and Van Cleve disclose the method of claim 1. Jurss further discloses based on information regarding the extracted first digital signature not being the same as information regarding the second digital signature (Jurss [0074]-[0075]. In step S24, after the user 10 selects a user device, the mobile device 20 can transmit a get encrypted payload message comprising the nonce, the signed nonce, an access credential identifier for the selected user device, and an application identifier for the mobile application server 30. The mobile application server 30 can then verify the signed nonce using the one or more data elements. For example, the mobile application server 30 can retrieve the verification key in the data elements to verify the digital signature on the signed nonce.).
Poliashenko further discloses comprising displaying a user interface informing that data corresponding to the function execution request may not be provided (Poliashenko [0047], [0053]. If the credentials are not acceptable, the SSO login may be rejected (block 330). The user may be offered the opportunity to log in directly with app B 220, app B 220 may send an error message, or app B 220 may simply cease the process without error message. [N]etwork connected computing device could include, but is not limited to, a server, a desktop computer, a laptop computer, a smart phone, a personal digital assistant (PDA).).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine teachings of Poliashenko, Van Cleve and Jurss to include: displaying a user interface informing that data corresponding to the function execution request may not be provided. One would have been motivated to provide users with a means for validating and enabling single sign-on functions across a plurality of applications. (See Poliashenko [0047].)
Regarding claim 13, Jurss and Van Cleve disclose the method of claim 1. Poliashenko further discloses wherein the first application includes an application installed on the electronic device, and wherein the second application includes an application installed on an external electronic device connected with the electronic device (Poliashenko [0031], [0040]. A trust relationship 208 may be built between the application 216 on the first computer 202 and the SSO service 218. One reason for trust between entities is the verification of messages sent between those entities. Further descriptions of such use are found below. Similarly, a trust relationship 210 may be built between the application 220 on the second computer 204 and the SSO service 218. App A 216 may then send the request ID directly to app B 220 (block 310).).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine teachings of Poliashenko, Van Cleve and Jurss to include: wherein the first application includes an application installed on the electronic device, and wherein the second application includes an application installed on an external electronic device connected with the electronic device. One would have been motivated to provide users with a means for validating and enabling single sign-on functions across a plurality of applications. (See Poliashenko [0047].)
Regarding claim 16, claim 16 is directed to a device corresponding to the method of claim 4. Claim 16 is similar to claim 4 and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is directed to a device corresponding to the method of claim 8. Claim 20 is similar to claim 8 and is therefore rejected under similar rationale.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Jurss et al. (“Jurss,” US 20240405994, filed Sept. 19, 2022) in view of Van Cleve et al. (“Van Cleve,” US 20230308277, filed Aug. 26, 2021) and Celkonas (“Celkonas,” US 20140058862, published Feb. 27, 2014).
Regarding claim 9, Jurss and Van Cleve disclose the method of claim 1. Jurss and Van Cleve do not explicitly disclose: wherein the user interface includes an object for identifying an input regarding whether to provide a function regarding the second application to the first application.
However, in an analogous art, Celkonas discloses a method, comprising the step of:
wherein the user interface includes an object for identifying an input regarding whether to provide a function regarding the second application to the first application (Celkonas [0104]. When the user selects the WebPay transaction from the home interface using the mobile application, the mobile application displays details regarding the payment request and provides the user with the option to accept the transaction and pay the specified amount or to decline the transaction. FIG. 13 presents an exemplary WebPay transaction interface for accepting or declining an online transaction using the mobile application in accordance with some embodiments. To pay for the transaction, the user selects a payment account that is linked to the user profile and the user enters the PIN for the selected payment account in order to transfer the requested funds from the user selected payment account to an account of the merchant. [Note that both the user and merchant can have user’s and merchant’s applications respective devices. See [0110],[0136].)
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine teachings of Celkonas, Jurss and Van Cleve to include the step of: wherein the user interface includes an object for identifying an input regarding whether to provide a function regarding the second application to the first application. One would have been motivated to provide users with a means for approving or denying a mobile payment request across a plurality of parties. (See Celkonas [0104].)
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system.
Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only.
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDWARD LONG/
Examiner, Art Unit 2439
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights