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 .
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 08/22/2026, for application 18/604,033 has been entered.
This Office Action is in response to the Amendment filed on 07/20/2026. In the instant amendment: Claims 1 and 14 have been amended. Claims 1-4, 7-10, 13-16, 18-20 have been examined and are pending.
Response to Arguments
Applicant’s argument with respect to amended independent 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, 10, 14, 18 and 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 Couillard et al. (“Couillard,” US 20200097682, published Mar 26, 2020).
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 of the electronic device, 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, Couillard discloses a method, comprising the steps of: a second application (Couillard [0080]. [T]he systems and methods described herein also provide, in accordance with different embodiments, different examples in which a hardware security module (HSM) is operable to concurrently service multiple applications and/or functions while minimizing system security risks that may otherwise be introduced when interfacing with a traditional HSM via an intermediary HSM access appliance, application layer or HSM access software.), 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 (Couillard [0083], [0109]-[0110], [0112]. [T]he HSM1 100 generally comprises a plurality of hardware ports 102 each operatively linked through hardware, e.g. direct hardware link or channel logic 108, to a corresponding port-specific hardware storage resource and key space 104 (e.g. distinct embedded memory storage device, hardware memory storage partition and/or zone). Each storage resource 104 can be configured to store secured port-specific cryptographic data (e.g. private encryption/decryption key 112) that is only retrievable upon input of corresponding input cryptographic data from a corresponding port. This validation process may, in some embodiments, only accept validated inputs by means of administrative port 338 and/or hardware ports 302 through a “chain of trust” process via digital signatures using quantum safe algorithms, such as hash-based signature algorithms. [T]he HSM (100, 200, 300) may be configured to share a common cryptographic engine (110, 210, 310), that is an embedded resources executing one or more cryptographic processed predefined in firmware and secured within the confines of the HSM's hardware architecture. Accordingly, respective secured cryptographic data (e.g. private key data) can be respectively accessed and used by the common cryptographic engine from respective port-specific storage spaces (104, 204, 304) to render secure HSM functions to respective port-specific masters (e.g. users, clients, applications, etc.). HSM resources may leverage an external storage resource such as a co-located or integrated flash drive or hard drive to store private key or other secured cryptographic data for exclusive access via embedded port-specific cryptographic engines [flash drive or hard drive of a computing device may not have restrictions for other applications. On the other hand, accessing keys or other information stored on the HSM may require validating a chain of digital signatures.].).
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 Couillard 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 using a HSM to securely store and execute sensitive crypto/digital key information. (See Couillard [0110].)
Regarding claim 10, Jurss and Couillard 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 18, Jurss and Couillard 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 Couillard disclose the device of claim 18. V Couillard 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 (Couillard [0102], [0110]. [A] number of discrete incoming digital events, data, processes and/or service requests per unit time 806 may be tracked and/or monitored in a trusted fashion. As shown in FIG. 8A, the flow of discrete data/events 806 entering and exiting hardware interconnection device and/or integrated HSM 809 via embedded hardware data channels is channeled through a trusted flow meter function 811, which is operable to measure said flow (number per unit time) of incoming events travelling through hardware interconnection device and/or integrated HSM 809. [T]he HSM (100, 200, 300) may be configured to share a common cryptographic engine (110, 210, 310), that is an embedded resources executing one or more cryptographic processed predefined in firmware and secured within the confines of the HSM's hardware architecture. Accordingly, respective secured cryptographic data (e.g. private key data) can be respectively accessed and used by the common cryptographic engine from respective port-specific storage spaces (104, 204, 304) to render secure HSM functions to respective port-specific masters (e.g. users, clients, applications, etc.)).
The motivation is the same as that of claim 14 above.
Claims 2-3, 7, 14, 15 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 Couillard et al. (“Couillard,” US 20200097682, published Mar 26, 2020) and Van Cleve et al. (“Van Cleve,” US 20230308277, filed Aug. 26, 2021).
Regarding claim 2, Jurss and Couillard disclose the method of claim 1. Jurss and Couillard do not explicitly disclose: wherein the function execution request includes information about a storage path of the first authentication value.
However, in an analogous art, Van Cleve further discloses a method comprising the steps of: 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.).
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, Couillard and Jurss to include the step of: wherein the function execution request includes information about a storage path of the first authentication value. 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 3, Jurss and Couillard 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).)
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, Couillard and Jurss to include the step of: wherein identifying the request for the second application to access to the storage area includes: identifying a specified access path for the second application, identifying the storage area among areas accessible through the specified access path. 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 through storage pathways. (See Van Cleve [0127].)
Regarding claim 7, Jurss and Couillard 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.).
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, Couillard and Jurss to include the step of: 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. 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 through storage pathways. (See Van Cleve [0127].)
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.
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 Couillard et al. (“Couillard,” US 20200097682, published Mar 26, 2020) and Poliashenko et al. (“Poliashenko,” US 20120291114, published Nov. 15, 2012).
Regarding claim 4, Jurss and Couillard disclose the method of claim 1.
Jurss and Couillard 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, Couillard 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 Couillard 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, Couillard 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 Couillard 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, Couillard 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 Couillard et al. (“Couillard,” US 20200097682, published Mar 26, 2020) and Celkonas (“Celkonas,” US 20140058862, published Feb. 27, 2014).
Regarding claim 9, Jurss and Couillard disclose the method of claim 1. Jurss and Couillard 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 Couillard 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
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
1 A hardware security module (HSM) … traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server. A hardware security module contains one or more secure cryptoprocessor chips. https://en.wikipedia.org/wiki/Hardware_security_module#cite_note-1
Prosecution Insights