DETAILED ACTION
In a communication received on 25 March 2026, applicants amended claims 1-5, 8, 10-12, 15 and 17-19.
Claims 1-20 are pending.
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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 8, and 15 have been considered but are moot because 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.
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 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.
Claim(s) 1-4, 6, 8-11, 13, 15-18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over He et al. (US 2021/0281555 A1) in view of Harrison (US 2014/0195649 A1), and further in view of Seibert, JR et al. (US 2015/0312256 A1).
With respect to claim 1, He discloses: a data processing system comprising: a processor; and a machine-readable storage medium storing executable instructions that, when executed, cause the processor alone or in combination with other processors to perform operations (i.e., server with memory, communication fabric, and processors coupled together in He, ¶0071)of:
receiving a request for an access token from an authentication handler (i.e., receiving request from client computer program and receiving a generated API key in order to access a service in He, ¶0024, ¶0028, ¶0051),
the access token providing access to content on a resource server remote from the client device (i.e., with receipt of valid API key generating a token for accessing the service from the service server in He, ¶0051),
the native application being configured to obtain the access token from a remote server over a network connection in response to the request for the access token (i.e., exchanging api key with an resource authorization server for an access token via a private internal network connection in He, ¶0020, ¶0039, ¶0043);
receiving, at the first web-based nested application, the access token from the native application via the secure authentication channel (i.e., client receives and completes the token from local authorization server; utilizing the token to access the service in He, ¶0048)
sending a request to access content on the resource server and the access token from the first web-based nested application to the resource server (i.e., client application receives the access token and uses it to communicate and access the service on a service server in He, ¶0048); and
performing one or more actions on the content on the resource server in response to obtaining access to the content on the resource server. (i.e., client application consumes a service provided by the server such as retrieving email, interacting with video game content, or a chat service in He, ¶0015).
He discloses exchanging api key with an authorization server for an access token via a private internal network connection (¶0020, ¶0039). He do(es) not explicitly disclose the following. Harrison, in order to improve interoperability and cross-domain function of any frame in a hierarchy of window to communicate with any other identified frame directly (¶0088), discloses:
of a first web-based nested application hosted (i.e., an iframe within a hierarchy may be hosted within a top level window of a browser application loading webcontent of the hierarchy of iframes in Harrison, ¶0088, ¶0149),
by a native application on a client device (i.e., sandboxed application such webpage or script hosted by the operating system or browser application in Harrison, ¶0170, ¶0176);
creating a secure authentication channel between the first web-based nested application and the native application using the authentication handler of the first web-based nested application (i.e., message listener to receive message and return results to the calling frame in Harrison, ¶0088),
the secure authentication channel (i.e., post message calling any other window in a hierarchy directly in Harrison, ¶0088),
bypassing one or more intermediary nested applications between the first web-based nested application and the native application to prevent the one or more intermediary nested applications from accessing data exchanged between the first web-based nested application and the native application (i.e., creating a communication mechanism using scripts to implement postmessage to call any other window in a hierarchy directly, for example the top level window may have a listener to receive message using postmessage and return communication to the calling iframe further down the hierarchy; the calling of the communication mechanism is performed using an identifier corresponding to each of the low and top level frame bypassing the frames in between in Harrison, ¶0088, ¶0149);
sending the request for the access token to the native application via the secure authentication channel (i.e., postMessage utilized to directly call another window in a hierarchy in Harrison, ¶0088, ¶0149).
Based on He in view of Harrison, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Harrison to improve upon those of He in order to improve interoperability and cross-domain function of any frame in a hierarchy of window to communicate with any other identified frame directly.
He discloses exchanging api key with an authorization server for an access token via a private internal network connection (¶0020, ¶0039). Harrison discloses a hierarchical message listener infrastructure to call another window in a hierarchy (¶0088). He and Harrison do not disclose the following. Seibert, in order to reduce complexity of a gatekeeping app by delegating the authentication to trusted intermediaries (¶0010), discloses:
requesting an authentication key from the native application by forwarding the request through each intermediary nested application of one or more intermediary nested applications disposed between the first web-based nested application and the native application (i.e., authentication request forwarded from one application to another requesting key through an intermediary in Seibert , ¶0031, ¶0034-0035);
determining, at each intermediary nested application, that the forwarded request has been received by a trusted nested application to ensure that the authentication key is returned to the first web-based nested application through trusted intermediary nested applications (i.e., request is authorized if it comes from trusted application, determining forwarded request was received by a trusted application in Seibert , ¶0030, ¶0037);
receiving the authentication key at the first web-based nested application from the native application (i.e., a nonce which is used to authenticate trusted application is transmitted to the requesting application in Seibert , ¶0038);
using the authentication key to identify the first web-based nested application to the native application (i.e., nonce, application identifier and signed verification create authenticated communication path, the key/identifier identifies the requesting application to the authenticating side in Seibert , ¶0032-0033, ¶0036-0037).
Based on He in view of Harrison, and further in view of Seibert, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Seibert, to improve upon those of He in order to improve reduces complexity of a gatekeeping app by delegating the authentication to trusted intermediaries.
With respect to claim 2, He discloses exchanging api key with an authorization server for an access token via a private internal network connection (¶0020, ¶0039). He do(es) not explicitly disclose the following. Harrison, in order to improve interoperability and cross-domain function of any frame in a hierarchy of window to communicate with any other identified frame directly (¶0088), discloses: the data processing system of claim 1, wherein the secure authentication channel is implemented using JavaScript to establish communications between the first web-based nested application and the native application (i.e., implementation of the direct communication between any frames in a hierarchy using javascript in Harrison, ¶0084, ¶0088).
Based on He in view of Harrison, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Harrison to improve upon those of He in order to improve interoperability and cross-domain function of any frame in a hierarchy of window to communicate with any other identified frame directly.
With respect to claim 3, He discloses authorization server receiving request from client computer program and receiving a generated API key in order to access a service (¶0028, ¶0051) the api key uniquely identifies the client application for getting access to service server (¶0002, ¶0029). Harrison discloses a hierarchical message listener infrastructure to call another window in a hierarchy (¶0088). He and Harrison do not disclose the following. Seibert, in order to reduce complexity of a gatekeeping app by delegating the authentication to trusted intermediaries (¶0010), discloses: the data processing system of claim 1,
wherein the authentication key is a unique identifier that is provided to trusted nested applications to permit the trusted nested applications to request and receive access tokens (i.e., previously authenticated applications have corresponding unique identifier; trusted application as an intermediary signs the authentication request being forwarded with private key of the trusted application, in Seibert, ¶0024, ¶0036).
Based on He in view of Harrison, and further in view of Seibert, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Seibert, to improve upon those of He in order to improve reduces complexity of a gatekeeping app by delegating the authentication to trusted intermediaries.
With respect to claim 4, He discloses: the data processing system of claim 3, wherein the machine-readable storage medium further includes instructions configured to cause the processor alone or in combination with other processors to perform operations of:
generating the authentication key using a key generator of the native application (i.e., API key module generating an API key for client to access the service in He, ¶0028),
wherein the authentication key is a Universally Unique Identifier (UUID) (i.e., the API key is a unique identifier to authenticate user, developer, or program in He, ¶0002).
With respect to claim 6, He discloses exchanging api key with an authorization server for an access token via a private internal network connection (¶0020, ¶0039). He do(es) not explicitly disclose the following. Harrison, in order to improve interoperability and cross-domain function of any frame in a hierarchy of window to communicate with any other identified frame directly (¶0088), discloses: the data processing system of claim 1, wherein the machine-readable storage medium further includes instructions configured to cause the processor alone or in combination with other processors to perform operations of:
obtaining context information from an intermediate nested frame disposed between the first web-based nested application and the native application (i.e., postmessage communication may be used to call and post information for any frame in a hierarchy including intermediary frames in Harrison, ¶0064),
the context information including information for establishing the secure authentication channel between the first web-based nested application and the native application (i.e., frames in a hierarchy can pass arguments directly to each other through the frame and the URI including attributes in the URI, such that loading them in a frame effectively passes the information through to the next frame in Harrison, ¶0090-0092).
Based on He in view of Harrison, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Harrison to improve upon those of He in order to improve interoperability and cross-domain function of any frame in a hierarchy of window to communicate with any other identified frame directly.
With respect to claim 8, the limitation(s) of claim 8 are similar to those of claim(s) 1. Therefore, claim 8 is rejected with the same reasoning as claim(s) 1.
With respect to claim 9, the limitation(s) of claim 9 are similar to those of claim(s) 2. Therefore, claim 9 is rejected with the same reasoning as claim(s) 2.
With respect to claim 10, the limitation(s) of claim 10 are similar to those of claim(s) 3. Therefore, claim 10 is rejected with the same reasoning as claim(s) 3.
With respect to claim 11, the limitation(s) of claim 11 are similar to those of claim(s) 4. Therefore, claim 11 is rejected with the same reasoning as claim(s) 4.
With respect to claim 13, the limitation(s) of claim 13 are similar to those of claim(s) 6. Therefore, claim 13 is rejected with the same reasoning as claim(s) 6.
With respect to claim 15, the limitation(s) of claim 15 are similar to those of claim(s) 1. Therefore, claim 15 is rejected with the same reasoning as claim(s) 1.
With respect to claim 16, the limitation(s) of claim 16 are similar to those of claim(s) 2. Therefore, claim 16 is rejected with the same reasoning as claim(s) 2.
With respect to claim 17, the limitation(s) of claim 17 are similar to those of claim(s) 3. Therefore, claim 17 is rejected with the same reasoning as claim(s) 3.
With respect to claim 18, the limitation(s) of claim 18 are similar to those of claim(s) 4. Therefore, claim 18 is rejected with the same reasoning as claim(s) 4.
With respect to claim 20, the limitation(s) of claim 20 are similar to those of claim(s) 6. Therefore, claim 20 is rejected with the same reasoning as claim(s) 6.
Claim(s) 5, 12, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over He et al. (US 2021/0281555 A1) in view of Harrison (US 2014/0195649 A1) and Seibert, JR et al. (US 2015/0312256 A1), and further in view of Surale et al. (US 2019/0073373 A1).
With respect to claim 5, He discloses: the data processing system of claim 4, wherein the machine-readable storage medium further includes instructions configured to cause the processor alone or in combination with other processors to perform operations of:
determining that the first web-based nested application is included in a list of applications trusted by the native application (i.e., a policy module with a whitelist/blacklist that authorizes client to use API keys in He, ¶0035).
He discloses authorization server receiving request from client computer program and receiving a generated API key in order to access a service (¶0028, ¶0051). He, Harrison, and Seibert do(es) not explicitly disclose the following. Surale, in order to improve security and scalability such as in IoT data pipelines where security risks increase with the complexity of the environment (¶0004), discloses: providing the authentication key to the first web-based nested application responsive to determining that the first web-based nested application is included in the list of applications trusted by the native application (i.e., determining that the device is registered to use the platform and generating the API key based on the information of the registered device in Surale, ¶0064).
Based on He in view of Harrison and Seibert, and further in view of Surale, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Surale to improve upon those of He in order to improve security and scalability such as in IoT data pipelines where security risks increase with the complexity of the environment.
With respect to claim 12, the limitation(s) of claim 12 are similar to those of claim(s) 5. Therefore, claim 12 is rejected with the same reasoning as claim(s) 5.
With respect to claim 19, the limitation(s) of claim 19 are similar to those of claim(s) 5. Therefore, claim 19 is rejected with the same reasoning as claim(s) 5.
Claim(s) 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over He et al. (US 2021/0281555 A1) in view of Harrison (US 2014/0195649 A1) and Seibert, JR et al. (US 2015/0312256 A1), and further in view of Obasanjo et al. (US 2013/0067568 A1).
With respect to claim 7, He discloses: the data processing system of claim 1, causing the native application to obtain the access token from a token service on a remote server over a network connection (i.e., exchanging api key with an authorization server for an access token via a private internal network connection in He, ¶0020, ¶0039); and
receiving the access token from the platform broker implemented by the operating system of the client device (i.e., resource authorization server receives the API key and generates and returns the at least an access token for accessing a service server in He, ¶0043).
He discloses authorization server receiving request from client computer program and receiving a generated API key in order to access a service (¶0028, ¶0051). He, Harrison, and Seibert do(es) not explicitly disclose the following. Obasanjo, in order to improve security and privacy of user identity while allowing authorization of applications to access user data (¶0001), discloses: further comprises: sending a request to a platform broker implemented by an operating system of the client device to obtain the access token (i.e., using application identifiers of various applications determine authorizations for those applications with a native access broker module in Obasanjo, ¶0031).
Based on He in view of Harrison and Seibert, and further in view of Obasanjo, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Obasanjo to improve upon those of He in order to improve security and privacy of user identity while allowing authorization of applications to access user data.
With respect to claim 14, the limitation(s) of claim 14 are similar to those of claim(s) 7. Therefore, claim 14 is rejected with the same reasoning as claim(s) 7.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHERMAN L LIN whose telephone number is (571)270-7446. The examiner can normally be reached Monday through Friday 9:00 AM - 5:00 PM (Eastern).
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, Joon Hwang can be reached at 571-272-4036. 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.
Sherman Lin
4/18/2026
/S. L./Examiner, Art Unit 2447
/JOON H HWANG/Supervisory Patent Examiner, Art Unit 2447
Prosecution Insights