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 .
Detailed Action
2. Claims 1-19 are pending in Instant Application.
Election/Restrictions
Applicant’s election without traverse of claims 1-10 and 11-19 in the reply filed on 01/23/2026 is acknowledged.
Priority
Examiner acknowledges that this application claims the benefit of and priority to U.S. provisional
patent application no. 63/405,370 entitled SYSTEMS AND METHODS FOR TOKEN-BASED BROWSER EXTENSION FRAMEWORK filed on September 9, 2022. The entire contents of this document is herein incorporated by reference.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
Claims 1-5, 9, 11-14, and 18 are rejected under 35 U.S.C. 102 (a) (1) as being anticipated by
US2017/0212794 issued to Fadel et al. (Fadel).
As per claim 1, Fadel teaches a computer-implemented system for orchestrating at least two browser extensions installed on a browser (Fadel: Fig. 3A - multiple extension points are installed by operating system), the system comprising: a communication interface (Fadel: ¶ 0063 - the application extension generates content, such as graphical user interface (GUI) content, to be displayed to a user); at least one processor (Fadel: Fig. 13 (processor(s) (1301)); non-transitory computer readable memory in communication with said at least one processor; software code stored in said non-transitory computer readable memory (Fadel: ¶ 0114 - electronic devices store and communicate (internally and/or with other electronic devices over a network) code and data using computer readable media, such as non-transitory computer-readable storage media), which when executed at said at least one processor causes said system to: receive, from a browser launched on a user device, a request from a first extension manager associated with a first extension installed on the browser, the request comprising a first extension ID for the first extension and a second extension ID for a second extension installed on the browser (Fadel: ¶ 0035 - teaches allow a first application to invoke an extension of a second application to access a set of predefined functionalities associated with the second application, which is extended by the extension, while ¶ 0039 - teaches when an extension is being installed, based on the type of the extension (e.g., identified by a uniform type identifier or UTI) and an extension provider identifier (ID)); retrieve, based on the first and second extension IDs, a first extension configuration for the first extension and a second extension configuration for the second extension from a metadata database (Fadel: ¶ 0037 - When the extension of the second application is developed, a developer can utilize an extension template associated that particular extension point as part of a software development kit (SDK) to generate executable images of both the second application, referred to herein as a container application, and the associated extension. The extension and the container application may be released in a bundle. The bundle includes the container application and its metadata describing the container application, and the extension and its metadata describing the extension.); and route a response to the first extension manager, the response comprising the first and second extension configurations and an extension ranking (Fadel: ¶ 0062 - in response to a request from the first application for invoking an application extension (e.g., plugin), processing logic launches the application extension within a second sandboxed environment (e.g., second process address space) based on a second security profile (ranking) associated with the application extension).
As per claim 2, Fadel teaches the system of claim 1, wherein the extension ranking is obtained from the metadata database (Fadel: ¶ 0067 - database contains information (metadata) for configuring a sandboxed operating environment when launching an extension).
As per claim 3, Fadel teaches the system of claim 2, wherein the extension ranking comprises the first or second extension ID (Fadel: ¶ 0077 - An extension provider ID is an identifier uniquely identifying an extension provider and certified by a predetermined authority (e.g., an operating system provider)).
As per claim 4, Fadel teaches the system of claim 3, wherein the extension ranking is determined based on a set of priority rules stored in the metadata database (Fadel: ¶ 0037 - all extensions designed for a particular extension point must comply with the specification set forth in the predefined policies of that particular extension point).
As per claim 5, Fadel teaches the system of claim 1, wherein the response further comprises a list of domains that support the first extension or the second extension (Fadel: ¶ 0037 - an extension point acts as an interface for a software developer for an extension and provides a domain that the extension operates).
As per claim 9, Fadel teaches the system of claim 4, wherein the set of priority rules comprises a set of logics for selecting a priority extension from a plurality of extensions for a specific feature (Fadel: ¶ 0062 - in response to a request from the first application for invoking an application extension (e.g., plugin), processing logic launches the application extension within a second sandboxed environment (e.g., second process address space) based on a second security profile associated with the application extension).
As per claim 11, the claim resembles claim 1 and is rejected under the same rationale.
As per claim 12, the claim resembles claim 2 and is rejected under the same rationale.
As per claim 13, the claim resembles claim 3 and is rejected under the same rationale.
As per claim 14, the claim resembles claim 4 and is rejected under the same rationale.
As per claim 18, the claim resembles claim 9 and is rejected under the same rationale.
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.
6. Claims 6-8, 10, 15-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US2017/0212794 issued to Fadel et al. (Fadel) in view US 2023/0353556 issued to Levy et al. (Levy).
As per claim 6, Fadel teaches the system of claim 1 however does not explicitly teach wherein based on the extension ranking in the response, the first extension manager is configured to be a master extension manager in control of the second extension.
Levy however explicitly teaches wherein based on the extension ranking in the response, the first extension manager is configured to be a master extension manager in control of the second extension (Levy: ¶ 0019 - performing user operations by a first system (e.g., a manager, portal or another system that needs to access, activate and/or connect to other systems on behalf of a user) on at least a second system using user impersonation (e.g., in the absence of a common IDP). For example, a management system may need to control one or more additional systems to perform one or more user operations on the one or more additional systems, on behalf of one or more users).
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 teaching of Fadel in view of Levy to teach wherein based on the extension ranking in the response, the first extension manager is configured to be a master extension manager in control of the second extension. One would be motivated to do so as a management system may need to control one or more additional systems to perform one or more user operations on the one or more additional systems, on behalf of one or more users by performing user operations by a first system (e.g., a manager, portal or another system that needs to access, activate and/or connect to other systems on behalf of a user) on at least a second system using user impersonation (e.g., in the absence of a common IDP) (Levy: ¶ 0019).
As per claim 7, the modified teaching of Fadel teaches the system of claim 6, wherein the first extension manager, acting as the master extension manager, transmits one or more control commands from the system to a second extension manager on the second extension manager (Levy: ¶ 0067 - the process sends an impersonation request (command), by the first system to the second system, to obtain an impersonated user access token of the given user for the second system).
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 teaching of Fadel in view of Levy to teach wherein the first extension manager, acting as the master extension manager, transmits one or more control commands from the system to a second extension manager on the second extension manager. One would be motivated to do so as the process sends an impersonation request (command), by the first system to the second system, to obtain an impersonated user access token of the given user for the second system (Levy: ¶ 0067).
As per claim 8, the modified teaching of Fadel teaches the system of claim 7, wherein the transmission is encapsulated in one or more inter-extension messages (Fadel: ¶ 0072 - when application and application extension would like to communicate with each other, they establish a connection to the IPC service, for example, by connecting to a pre-agreed upon IPC service (e.g., IPC service name) and start sending and receiving data or messages via the connection).
As per claim 10, Fadel teaches the system of claim 9 however does not explicitly teach wherein the set of logics includes selection logics based on a user account associated with one or more of the plurality of extensions.
Levy however explicitly teaches wherein the set of logics includes selection logics based on a user account associated with one or more of the plurality of extensions (Levy: ¶ 0088 - each of the VMs can implement user impersonation control logic and associated functionality for allowing a first system to perform user operations on a second system on behalf of a given user (user account) while ¶ 0058 - teaches user authentication can be based on their account that consist of username/password, certificate-based TLS (Transport Layer Security)/mTLS (Mutual TLS), multi-factor authentication, or another secure connection method).
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 teaching of Fadel in view of Levy to teach wherein the set of logics includes selection logics based on a user account associated with one or more of the plurality of extensions. One would be motivated to do so as it can be implemented that user impersonation control logic and associated functionality for allowing a first system to perform user operations on a second system on behalf of a given user (user account) while user authentication can be based on their account consist of username/password, certificate-based TLS (Transport Layer Security)/mTLS (Mutual TLS), multi-factor authentication, or another secure connection method (Levy: ¶ 0058, ¶ 0088).
As per claim 15, the claim resembles claim 6 and is rejected under the same rationale.
As per claim 16, the claim resembles claim 7 and is rejected under the same rationale.
As per claim 17, the claim resembles claim 8 and is rejected under the same rationale.
As per claim 19, Fadel teaches the system of claim 18 however does not explicitly teach wherein the set of priority rules comprises user-specific priority rankings based on a user account associated with one or more of the plurality of extensions.
Levy however explicitly teaches wherein the set of priority rules comprises user-specific priority rankings based on a user account associated with one or more of the plurality of extensions (Levy: ¶ 0088 - each of the VMs can implement user impersonation control logic and associated functionality for allowing a first system to perform user operations on a second system on behalf of a given user (user account) while ¶ 0058 - teaches user authentication can be based on their account that consist of username/password, certificate-based TLS (Transport Layer Security)/mTLS (Mutual TLS), multi-factor authentication, or another secure connection method).
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 teaching of Fadel in view of Levy to teach wherein the set of priority rules comprises user-specific priority rankings based on a user account associated with one or more of the plurality of extensions. One would be motivated to do so as it can be implemented that user impersonation control logic and associated functionality for allowing a first system to perform user operations on a second system on behalf of a given user (user account) while user authentication can be based on their account consist of username/password, certificate-based TLS (Transport Layer Security)/mTLS (Mutual TLS), multi-factor authentication, or another secure connection method (Levy: ¶ 0058, ¶ 0088).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SM AZIZUR RAHMAN whose telephone number is (571)270-7360. The examiner can normally be reached on M-F Telework;
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ali Shayanfar can be reached on 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 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.
/SM A RAHMAN/Primary Examiner, Art Unit 2434