DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office correspondence is in response to “Amendment and Response under 37 C.F.R. 1.111 filed on January 6, 2026 in response to a non-final office action dated August 11, 2025.
Claims 1 – 15 are pending.
Claims 10, 11, and 15 are amended.
Claims 1 – 15 are rejected.
Response to Arguments
Applicant’s arguments filed on 1/6/2026 have been fully considered:
In regard to claims 10 – 15 which were rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention, the applicant adequately amended claims 10, 11, and 15 to correct the issues that caused the claims to be indefinite. Therein the rejections are withdrawn.
In regard to claims 1 – 9 which were rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter, the applicant has mis-interpreted the premise of the rejection by arguing the judicial exception analysis and the framework set forth in Alice Corp v. CLS Bank Int’l. The applicant needs to reread the non-final rejection dated 8/11/2025 pages 4 – 6 ¶¶ [13 – 14]. A review of ¶ [14] describes:
“Claims 1 – 15 are directed to statutory subject matter and are not rejected under 35 USC 101 because of a judicial exception. The claimed subject matter is integrated into a practical application under prong 2 of the Step 2A analysis as documented in MPEP 2016.04(d). The claims are directed to non-abstract improvements in computer related technology. A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception . . . “
Therein, since the claims were found not pertaining to an abstract idea, the majority of the applicant’s argument is not relevant to the 35 USC 101 rejection applied as software per se which requires structural recitations applied to such elements as “a client part” and “a server part” which can reasonably interpreted to be software. The examiner explained this deficiency in ¶ [13] of the non-final office action. The applicant does present an argument in the response:
“ . . . Claim 1 is directed to a system comprising a client part and a server part, including an authenticator, an embedded browser, a data channel module, a program memory, a variables memory, a control module, and at least one authentication server of a browser control manager. These components are recited as interacting elements of a distributed client-server architecture configured to control access to service providers and target applications. The claim therefore falls squarely within the statutory categories of machines and systems under 35 U.S.C. §101 and is not directed to disembodied software or an abstract idea. . . .” (Applicant’s remarks page 7).
The applicant’s argument would not be persuasive based past traditional analysis requiring computer hardware elements to have a physical structure (e.g. comprising a processor that can execute instructions from a physical memory). However, in light of In re McFadden, 2024-2107 (Fed. Cir. Sept. 5, 2025), ,the court found broad based nonce words should be interpreted as means-plus-function and that recitation of corresponding generic computer hardware descriptions in the specification can provide sufficient structure to avoid “software per se” rejections. However, the court found it is proper to provide a 35 U.S.C. 112(f) analysis for such elements. Therein, in view of the McFadden decision, the 35 USC 101 rejection is withdrawn. However a claim interpretation under 35 USC 112(f) was performed, and the analysis is discussed below.
In regard to claims 1 – 15, the applicant argues that the prior art combination of Chauhan and Wilson fails to teach, anticipate or suggest the claimed invention which is, in accordance with claim 1 and substantially replicated in claim 10, a system and computerized method “for controlling access of a user to service providers and/or target applications that requires, among other things, a client part containing an authenticator, an embedded browser, a data channel module, a program memory, a variables memory, and a control module configured to control execution of programs stored in the program memory, as well as a server part containing at least one authentication server of a browser control manager.” (see applicant’s remarks pages 10 -11)
The applicant states:
“ . . . Chauhan is directed to systems and methods for enabling offline usage of software-as-a- service (SaaS) applications by managing application data and policies on a client device. In Chauhan, a client application residing on a user device is configured to access and synchronize application data and policies with one or more servers so that the application may continue to function when network connectivity is unavailable. The focus of Chauhan is thus on application management and data synchronization in support of offline operation, including maintaining local copies of data and policies and synchronizing such data when connectivity is restored.
Chauhan does not disclose or describe a system for controlling access to target applications through externally supplied executable programs and trigger rules. The client application of Chauhan is a monolithic application instance installed on a particular device, rather than a client part configured to receive, store, and execute programs supplied by a separate server-side browser control manager. Chauhan does not disclose a control module configured to control execution of programs based on trigger rules associated with target applications, nor does it disclose distributing such programs and trigger rules from a server to client devices in response to authentication. Rather, Chauhan's synchronization mechanisms are directed to maintaining consistency of application data for offline use, not to centrally managing access logic or execution behavior across devices.
Moreover, Chauhan's architecture does not include a browser control manager or an
authentication server thereof that maintains per-user synchronization queues of programs and trigger rules, as required by claim 1. Authentication in Chauhan, where present, is ancillary to enabling access to SaaS functionality and is not used to govern distribution and execution of client-side programs for controlling access to target applications. . . .” (Applicant’s remarks pages 9 – 10)
In response to applicant’s argument:
The applicant’s argument is not persuasive because the claims do nit have the level of detail argued by the applicant that would enable the claimed invention, as represented by claim 1, to be distinguishable from Chauhan when analyzed using broadest reasonable interpretation. See MPEP 2111 (“an examiner must construe claim terms in the broadest reasonable manner during prosecution as is reasonably allowed in an effort to establish a clear record of what applicant intends to claim. Thus, the Office does not interpret claims in the same manner as the courts. In re Morris, 127 F.3d 1048, 1054, 44 USPQ2d 1023, 1028 (Fed. Cir. 1997); In re Zletz, 893 F.2d 319, 321-22, 13 USPQ2d 1320, 1321-22 (Fed. Cir. 1989). Because applicant has the opportunity to amend the claims during prosecution, giving a claim its broadest reasonable interpretation will reduce the possibility that the claim, once issued, will be interpreted more broadly than is justified. In re Yamamoto, 740 F.2d 1569, 1571 (Fed. Cir. 1984); In re Zletz, 893 F.2d 319, 321, 13 USPQ2d 1320, 1322 (Fed. Cir. 1989) (“During patent examination the pending claims must be interpreted as broadly as their terms reasonably allow.”); In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-51 (CCPA 1969)). When mapping the claim limitations to the disclosure of Chauhan, the elements client part, server part, authenticator, embedded browser, and data channel module, and their functional purpose as recited in the claims, are representative using a broadest reasonable interpretation to the Chauhan’s Fig. 11 and accompanying disclosure:
PNG
media_image1.png
490
722
media_image1.png
Greyscale
The applicant reads in features of the invention, not recited in the claims. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The applicant needs to add more specificity to the claim language to distinguish the claims from a generic client server architecture with browsing and authentication functionality, as represented by Chauhan.
The applicant states:
“ . . . Wilson is directed to integrating an authentication service within a network architecture, particularly for controlling access to networks, gateways, or relying-party systems. Wilson describes authentication frameworks in which a user authenticates through one or more authentication devices, and upon successful authentication, is granted access to protected network resources or services, such as through an SSL VPN gateway or similar infrastructure.
Wilson's disclosure is centered on network-level or gateway-level authentication and authorization. Interaction with a browser in Wilson occurs through conventional web pages, HTML forms, and JavaScript executed within a browser context, rather than through an embedded browser whose operation is controlled by an authenticator using graphical and control primitives. Wilson does not disclose a client part containing a program memory and control module configured to control execution of programs supplied by a server, nor does it disclose a browser control manager that distributes executable programs and trigger rules to client devices.
Further, Wilson does not address controlling access to target applications through execution of client-side programs triggered by predefined rules. Instead, authentication in Wilson is used to establish trust and grant access at a network or service boundary. Wilson therefore does not supply the missing architectural and functional elements absent from Chauhan, nor does it suggest modifying Chauhan's offline-oriented SaaS client architecture to incorporate such elements. . .” (applicant’s remark’s page 10)
In response to the applicant’s argument:
Wilson, in combination with Chauhan, is used to teach the limitation wherein the authenticator (3) (see Fig. 5 201) is also configured to communicate with the user via a graphical user interface of the embedded browser (1) (see Fig. 5 512) using graphical and control primitives (2) of the authenticator and/or using a stand-alone graphical user interface of the authenticator (see Fig. 5 ¶ [0053]) Fig. 5 and accompanying documentation describes communications between a user on a browser receiving authentication information using a GUI provided by the authenticator.
PNG
media_image2.png
554
724
media_image2.png
Greyscale
As Wilson provides this functionality as is represented by the claim language recited in claim 1, the applicant’s argument is not persuasive.
The applicant states:
“ . . . Neither Chauhan nor Wilson, alone or in combination, teaches or suggests the claimed system architecture. As discussed above, Chauhan does not disclose a client part that receives and executes externally supplied programs under the control of a control module based on trigger rules, nor does it disclose a server-side browser control manager authentication server configured to manage such programs. Wilson, while addressing authentication, is directed to a different problem space-namely network and gateway authentication-and does not disclose or suggest the claimed client-side execution model or server-side program management.
The Office Action does not explain how the client application of Chauhan would be modified to include a program memory and control module that execute programs supplied by a browser control manager, nor does it explain how Wilson's network authentication framework would be incorporated into Chauhan's offline-oriented SaaS system to yield the claimed architecture. Absent such explanation, the rejection relies on high-level functional similarities, such as the general presence of authentication or client/server communication, rather than on the specific structural and functional limitations recited in claim 1.
Further, the Office Action does not articulate why a person of ordinary skill in the art would have been motivated to combine Chauhan and Wilson in the manner required by claim 1. Chauhan is concerned with ensuring continuity of application functionality during offline operation, while Wilson is concerned with securing access to networks and services at an authentication boundary. These references address different technical problems and employ different architectural solutions. The Office Action does not identify a reasoned basis why a skilled artisan would have combined these teachings to arrive at a system in which a browser control manager authentication server distributes executable programs and trigger rules to control access to target applications through an embedded browser.
Because the cited references do not teach or suggest all of the limitations of claim 1, and because the Office Action does not provide an articulated rationale with a reasonable expectation of success for combining Chauhan and Wilson to meet those limitations, a prima facie case of obviousness has not been established. Accordingly, the rejection of claim 1 under 35 U.S.C. §103 should be withdrawn. Claims 2 to 9, which depend from claim 1, are patentable for at least the same reasons as for claim 1 . . .” (Applicant’s remarks 11 – 12)
In response to the applicant’s argument:
The applicant argues that the motivation to combine Chauhan and Wilson is not a reasoned motivation and would not have been obvious to a person of skill in the art. The applicant’s argument is not persuasive because while the two references address different technical problems, they are analogous art with common components including a client, server, and authenticator for communications within a computerized network. It is well established that a flexible common sense approach to combining references can be used in light of KSR International v. Teleflex Inc. (2007). Specifically, for this case a person skilled in the art could reasonably apply the improvements from the authenticator taught in Wilson into the system of Chauhan.
The applicant offers similar arguments for the rejection of claims 10 – 15 (see applicants remarks pages 12- 14) but are not persuasive for the same reasons previously discussed. Therein the rejections under 35 USC 103 are not withdrawn. The applicant is referenced to the rejections described below.
The examiner recommends that the applicant review the specification for disclosure that if integrated into the independent claims would distinguish the amended claims from the cited prior art. The applicant is invited to contact the examiner for an interview to discuss how to move the prosecution forward.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
Priority
This application is a National Stage entry of PCT application No. PCT/CZ2022/050071 filed on 8/3/2022 with a 371 ( c) (1) date of 1/24/2024. The instant application claims foreign application priority to CZ-PV2021-366 filed in the Czech republic patent office on August 4, 2021. Receipt is acknowledged of certified copy of papers required by 37 CFR 1.55. As such the applicant is entitled to a priority date of 8/4/2021.
Double Patenting Analysis
The applicant has been granted a U.S. Patent 11,985,118, which names the inventor or at least one joint inventor in common, and is directed to similar subject matter as the instant application. At this time of examination, the instant application appears to claim only subject matter directed to an invention that is independent and distinct from that claimed in the issued patent. Therein, no non-statutory Double Patenting rejections have been applied. The applicant is required to maintain a clear line of demarcation between the instant application and the issued patent during prosecution, as the Double Patenting analysis can be revisited if the claims of the instant application and the issued patent converge to claiming the same subject matter. The applicant may wish to proactively file a terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) to overcome possible future Double Patenting rejections.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“a client part”, “a server part”, “an authenticator”, “a data channel module”, “a program memory”, “a variables memory”, “a control processor” in claims 1 - 9.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. The specification discloses Fig.1 ¶¶ [0063-0081], ¶¶ [0112-0149] that provides a structure to perform required functions of the invention.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
35 USC § 101 Analysis – Judicial Exception
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 – 15 are directed to statutory subject matter and are not rejected under 35 USC 101 because of a judicial exception. The claimed subject matter is integrated into a practical application under prong 2 of the Step 2A analysis as documented in MPEP 2016.04(d). The claims are directed to non-abstract improvements in computer related technology. A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement for controlling the access of a user to a service provider and/or to a target web application wherein utilizing a system which contains a client part and a server part. The client part contains an authenticator, an embedded browser and a data channel module. The authenticator is configured to authenticate the user. The authenticator is also configured to communicate with the user via a graphical user interface of the embedded browser using graphical and control primitives of the authenticator and/or using a stand-alone graphical user interface of the authenticator. The data channel module is configured to communicate with service provider servers via http/https protocol to communicate with the embedded browser and to communicate with the authenticator. The client part further contains a program memory, a variables memory and a control module configured to control the execution of programs stored in the program memory. The ordered steps address problems known in the art attributable to security risks due to a lack of manageable authentication of access and improves the process for preventing attacks caused by lapses in authentication. Therein the claimed invention is not an abstract idea under 35 USC 101.
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 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 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 - 15 are rejected under 35 U.S.C. 103 as being un-patentable over Chauhan (U.S. 2020/0104478 A1; herein referred to as Chauhan) in view of Wilson et al. (U.S. 2017/0034168 A1; herein referred to as Wilson).
In regard to claim 1, Chauhan teaches A system for controlling access of a user to service providers and/or to target applications (see ¶ [0001] “ . . . The present application generally relates to management of applications, including but not limited to systems and methods for using an embedded browser to manage and monitor web and software-as-a-service (SaaS) applications . . .”; see ¶ [0046] “ . . . “ . . . the operating system of the client device may be separated into a managed partition 210 and an unmanaged partition 212. The managed partition 210 may have policies applied to it to secure the applications running on and data stored in the managed partition. The applications running on the managed partition may be secure applications. In other embodiments, all applications may execute in accordance with a set of one or more policy files received separate from the application, and which define one or more security parameters, features, resource restrictions, and/or other access controls that are enforced by the client device management system when that application is executing on the device. By operating in accordance with their respective policy file(s), each application may be allowed or restricted from communications with one or more other applications and/or resources, thereby creating a virtual partition. Thus, as used herein, a partition may refer to a physically partitioned portion of memory (physical partition), a logically partitioned portion of memory (logical partition), and/or a virtual partition created as a result of enforcement of one or more policies and/or policy files across multiple apps as described herein (virtual partition). Stated differently, by enforcing policies on managed apps, those apps may be restricted to only be able to communicate with other managed apps and trusted enterprise resources, thereby creating a virtual partition that is not accessible by unmanaged apps and devices. . . .”) , said system comprising:
a client part (see Fig. 1 Fig. 11¶ [0038]” . . . the computing device 101 may execute an application on behalf of a user of a client computing device. For example, the computing device 101 may execute a virtual machine, which provides an execution session within which applications execute on behalf of a user or a client computing device, such as a hosted desktop session. The computing device 101 may also execute a terminal services session to provide a hosted desktop environment. The computing device 101 may provide access to a computing environment including one or more of: one or more applications, one or more desktop applications, and one or more desktop sessions in which one or more applications may execute. . . .”), and
a server part (see ¶ [0040]” . . . The present disclosure is directed towards systems and methods of an embedded browser. A client application executing on a client device can allow a user to access applications (apps) that are served from and/or hosted on one or more servers, such as web applications and software-as-a-service (SaaS) applications (hereafter sometimes generally referred to as network applications). A browser that is embedded or integrated with the client application can render to the user a network application that is accessed or requested via the client application, and can enable interactivity between the user and the network application. The browser is sometimes referred to as an embedded browser, and the client application with embedded browser (CEB) is sometimes referred to as a workspace application. The client application can establish a secure connection to the one or more servers to provide an application session for the user to access the network application using the client device and the embedded browser. . . “),
wherein the client part contains an authenticator (3) (see Fig. 11 authenticator 1110), an embedded browser (1) (see Fig. 11 embedded browser 1108) and a data channel module (4) (see Fig. 11 communication channel 1118) (see ¶ [0154]” . . . As a component of the client application 1106, the embedded browser 1108 further has the ability to authenticate the client application 1106 via an authenticator 1110 (sometimes referred to as an authentication client 1110), and the ability to synchronize data flowing across the communication channel 1118 to the network application 1102 via a synchronizer 1112 (sometimes referred to as a client synchronizer or synchronization client 1112). Similarly, the network application 1102 has the ability to verify user authentication via an authenticator 1114 (sometimes referred to as an authentication host, authentication server, or by similar terms), and also synchronize data flowing across the communication channel 1118 from the embedded browser 1108 via a synchronizer 1116 (sometimes referred to as a synchronization host, synchronization server, or a similar term). . . .”) ,
wherein the authenticator (3) is configured to authenticate the user (8) (see Fig. 12, ¶ [0162-0163]” . . . responsive to determining that the embedded browser 1108 was used to make the access request, the network application 1102 can perform or provide authentication and single-sign-on (SSO), and can allow the embedded browser 1108 to connect directly to the SaaS web service. The client application 1106 can establish a secure connection to the one or more servers 1104 to provide a communication session for the user to access the network application 1102 using the client application 1106 and the embedded browser 1108. In step 1218, the receipt of the authentication token, or other methods of establishing an authenticated connection to the network application 1102, allow the embedded browser 1108 to access to the data in the one or more servers 1104. The data accessed from the one or more servers 1104 may be accessible by any user upon authentication credential verification. . . .”) ; and
wherein the data channel module (4) (e.g. communications channel 1118) is configured to communicate with service provider (60) servers via http/https protocol, to communicate with the embedded browser (1) and to communicate with the authenticator (3) (see Fig. 11, ¶ [0153] “ . . . FIG. 11 illustrates one embodiment of interactions between a client application 1106 and a network application 1102. The client application 1106 resides in memory of the client device 1100 and, when executed by a processor of the client device, communicates via a communication channel 1118 to the network application 1102. The network application 1102 can be provided for by one or more servers 1104. The communication channel 1118 between the client device 1100 and one or more servers 1104 can be any form of internet communication and via any type and form of network. Protocols used may include any network layer protocol such as IPv4, IPv6, etc.; any transport layer protocol such as TCP, UDP, etc.; and/or any type of application layer protocol, such as HTTP, HTTPS, etc. . . .”) ;
wherein the client part further contains a program memory (5) (see Fig. 1 non-volatile memory 128) , a variables memory (6) (see Fig. 1 volatile memory122) , and a control module (7) (see Fig. 1 processor 103) configured to control the execution of programs stored in the program memory (5) (see Fig. 1 ¶ [0036] “ . . . Computer 101 as shown in FIG. 1 is shown merely as an example, as clients, servers, intermediary and other networking devices and may be implemented by any computing or processing environment and with any type of machine or set of machines that may have suitable hardware and/or software capable of operating as described herein. Processor(s) 103 may be implemented by one or more programmable processors to execute one or more executable instructions, such as a computer program, to perform the functions of the system. As used herein, the term “processor” describes circuitry that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations may be hard coded into the circuitry or soft coded by way of instructions held in a memory device and executed by the circuitry. A “processor” may perform the function, operation, or sequence of operations using digital values and/or using analog signals. In some embodiments, the “processor” can be embodied in one or more application specific integrated circuits (ASICs), microprocessors, digital signal processors (DSPs), graphics processing units (GPUs), microcontrollers, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), multi-core processors, or general-purpose computers with associated memory. The “processor” may be analog, digital or mixed-signal. In some embodiments, the “processor” may be one or more physical processors or one or more “virtual” (e.g., remotely located or “cloud”) processors. A processor including multiple processor cores and/or multiple processors multiple processors may provide functionality for parallel, simultaneous execution of instructions or for parallel, simultaneous execution of one instruction on more than one piece of data. . . .”) ; and
wherein the server part contains at least one authentication server (73) of a browser control manager (70) (see Fig. 11 application server 1104, authenticator 1114,(see Fig. 12, ¶ [0157]” . . . At step 1206, the network application 1102 evaluates whether the credentials received match stored credentials in the one or more servers 1104 or communicates with an authentication server to determine if the credentials indicate the user is authorized (e.g. by matching authorized credentials in a user database). The user may be registered with the network application 1102 such that the one or more servers 1104 or authentication server has stored the user's credentials. For example, the server may compare the string of characters received from the embedded browser 1108 to the string of characters stored in the one or more servers 1104. If the characters match identically, the decision can be made that the credentials match. In some implementations, the credentials may be encrypted or hashed (e.g. to prevent plaintext transmission of a password), and the hash may be compared to a hash of a use password. In step 1208, if the credentials do not match the stored credentials, the network application 1102 does not provide access to data in the embedded browser 1108. In step 1210, if the credentials do match the stored credentials, the one or more servers 1104 or an authentication server may transmit an authentication token to the client application 1106, authorizing the client device 1100. . . .”).
Chauhan fails to explicitly teach but Wilson teaches
wherein the authenticator (3) (see Fig. 5 201) is also configured to communicate with the user via a graphical user interface of the embedded browser (1) (see Fig. 5 512) using graphical and control primitives (2) of the authenticator and/or using a stand-alone graphical user interface of the authenticator (see Fig. 5 ¶ [0053]” . . . the interaction between the SSL VPN gateway 515, browser 510, and authentication server 202 is as follows. A user opens the web browser 510 and navigates to the SSL VPN gateway 515 which renders a web page 511 containing browser-executable code 512 such as JavaScript. In one embodiment, the browser-executable code 512 triggers authentication by establishing a communication channel with the authentication server 202 and triggering the authentication client 201 to authenticate the user. In one embodiment, the authentication server 202 and client 201 enter into a series of authentication transactions such as those described above with respect to FIG. 3. For example, the authentication server 202 may generate an authentication request which includes a random challenge (e.g., a cryptographic nonce) and may (or may not) identify the authenticator 110-112 to be used by the authentication client 201 for authentication. In response to receipt of the authentication request, the user may be presented with a graphical user interface (GUI) requesting authentication (e.g., in the form of a web page or a GUI of an authentication application/app). The user then performs the authentication (e.g., swiping a finger on a fingerprint reader, etc.). In response, the authentication client 201 generates an authentication response containing a signature over the random challenge with the private key associated with the authenticator. It may also include other relevant data such as the user ID code in the authentication response. Upon receipt of the authentication response, the authentication server 202 validates the signature over the random challenge (e.g., using the public key associated with the authenticator) and confirms the identity of the user. In one embodiment, the JavaScript or other browser executable code 512 passes the above authentication messages between the authentication server 202 and authentication client 201. . . “);
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s application to incorporate a system and method for integrating an authentication service within an existing network infrastructure, comprising configuring a gateway to restrict access to an internal network, configuring an authentication client of a client device to establish a communication channel with the authentication server and to register one or more authentication devices with the authentication server, further authenticating the user via a GUI of an embedded browser with the authentication server using one or more of the registered authentication devices in response to an attempt to gain access to the internal network via the gateway, as taught by Wilson, into a system and method for management of applications when using an embedded browser to manage and monitor web and software-as-a-service (SaaS) applications such that methods for storing, accessing, and synchronizing data from a SaaS application, enabling SaaS data to be interacted with, regardless of connectivity, while providing secure authentication when offline and during a first time period when online, a user may perform an authentication procedure and provide credentials to an application server, which may provide an authentication token for access to secure data or applications, as taught by Chauhan. Such incorporation enhances the use of the client’s embedded browser using a GUI to request authentication to the target application.
In regard to claim 2, the combination of Chauhan and Wilson teaches wherein the client part is provided on one or more devices of the user (see Chauhan ¶ [0006] ” . . . The method includes transmitting authentication credentials of a user to a network application executed by one or more application servers, by an embedded browser of a client application executed by a client device. The method also includes receiving, by the client application from the one or more application servers, an authentication token responsive to authorization of the client device by the network application based on the authentication credentials. The method also includes storing the authentication credentials in a memory of the client device, by the client application. . . “).
In regard to claim 3, the combination of Chauhan and Wilson teaches wherein the control module (7) is configured to monitor all communication of the embedded browser (1) with the servers of the service providers (60) (see Chauhan ¶ [0041] ” . . . The client application can terminate one end of a secured connection established with a server of a network application, such as a secure sockets layer (SSL) virtual private network (VPN) connection. The client application can receive encrypted traffic from the network application, and can decrypt the traffic before further processing (e.g., rendering by the embedded browser). The client application can monitor the received traffic (e.g., in encrypted packet form), and also have full visibility into the decrypted data stream and/or the SSL stack. This visibility can allow the client application to perform or facilitate policy-based management (e.g., including data loss prevention (DLP) capabilities), application control (e.g., to improve performance, service level), and collection and production of analytics. For instance, the local CEB can provide an information technology (IT) administrator with a controlled system for deploying web and SaaS applications through the CEB, and allow the IT administrator to set policies or configurations via the CEB for performing any of the forgoing activities. . . “).
In regard to claim 4, the combination of Chauhan and Wilson teaches wherein the authenticator (3) is configured to authenticate the data channel (41), and wherein the authenticator (3) is configured to bind the user authentication to the authenticated channel (41) (see Chauhan ¶ [0154] ” . . . As a component of the client application 1106, the embedded browser 1108 further has the ability to authenticate the client application 1106 via an authenticator 1110 (sometimes referred to as an authentication client 1110), and the ability to synchronize data flowing across the communication channel 1118 to the network application 1102 via a synchronizer 1112 (sometimes referred to as a client synchronizer or synchronization client 1112). Similarly, the network application 1102 has the ability to verify user authentication via an authenticator 1114 (sometimes referred to as an authentication host, authentication server, or by similar terms), and also synchronize data flowing across the communication channel 1118 from the embedded browser 1108 via a synchronizer 1116 (sometimes referred to as a synchronization host, synchronization server, or a similar term). . .”)
In regard to claim 5, the combination of Chauhan and Wilson teaches wherein the control module (7) is configured to pass over the program code to the embedded browser (1) for execution once a trigger rule for the launch of the program is fulfilled (see Chauhan ¶ [0093] ” . . . The client application 404 and CEB operate on the application layer of the operational (OSI) stack of the client device. The client application 404 can include and/or execute one or more agents that interoperate with the cloud services 408. The client application 404 can receive, obtain, retrieve or otherwise access various policies (e.g., an enterprise's custom, specified or internal policies or rules) and/or data (e.g., from an access gateway 422 and/or network device(s) of cloud services 408, or other server(s), that may be managed by the enterprise). The client application can access the policies and/or data to control and/or manage a network application (e.g., a SaaS, web or remote-hosted application). Control and/or management of a network application can include control and/or management of various aspects of the network application, such as access control, session delivery, available features or functions, service level, traffic management and monitoring, and so on. The network application can be from a provider or vendor of the enterprise (e.g., salesforce.com, SAP, Microsoft Office 365), from the enterprise itself, or from another entity (e.g., Dropbox or Gmail service). . . “; see Chauhan ¶ [0112] ” . . . the user can initiate connection to a sanctioned network application (e.g., a SaaS application), by selecting from the list of network applications presented to the user. For example, the user can click on an icon or other representation of the sanctioned network application, displayed via the client application or embedded browser. This user action can trigger the CEB to transmit a connection or access request to a server that provisions the network application. The request can include a request to the server (e.g., SaaS provider) to communicate with the access gateway to authenticate the user. The server can send a request to the access gateway to authenticate the user for example . . .”).
In regard to claim 6, the combination of Chauhan and Wilson teaches wherein the program is a computer program programmed to select from a pre-determined server or for a pre-determined web interface or for a pre-determined service provider webpage (see Chauhan ¶ [0010] ” . . . the method includes providing a first item of data of the network application requested by the embedded browser, and providing a second item of data of the network application, not requested by the embedded browser, to the client application for storage in the memory of the client computing device. In a further implementation, the second item of data is provided responsive to receipt of a request from the client application, by the one or more application servers, for the second item of data, the client application selecting the second item of data without user intervention. In another further implementation, the first item of data comprises a first page of a web application and the second item of data comprises a second page of the web application linked from the first page. In still another further implementation, the method includes receiving an authentication credential of a user, from the embedded browser, by one or more application servers; and the second item of data is selected from a subset of data of the network application associated with the authentication credential of the user. In some implementations, the method includes executing the recorded sequence, by the one or more application servers, faster than real time and without providing visual output to the embedded browser of the client application. . .”).
In regard to claim 7, the combination of Chauhan and Wilson teaches wherein the program is configured for verification of a certificate of the webpage by comparing the certificate with a copy of the certificate contained in the program or with information derived from the certificate contained in the program (see Chauhan ¶ [0053] ” . . . Cloud services can include an access gateway 260 and/or enterprise services 208. The enterprise services 208 may include authentication services 258, threat detection services 264, device manager services 224, file sharing services 268, policy manager services 270, social integration services 272, application controller services 274, and the like. Authentication services 258 may include user authentication services, device authentication services, application authentication services, data authentication services and the like. Authentication services 258 may use certificates. The certificates may be stored on the client device 202, by the enterprise resources 204, and the like. The certificates stored on the client device 202 may be stored in an encrypted location on the client device, the certificate may be temporarily stored on the client device 202 for use at the time of authentication, and the like. Threat detection services 264 may include intrusion detection services, unauthorized access attempt detection services, and the like. Unauthorized access attempt detection services may include unauthorized attempts to access devices, applications, data, and the like . . .”) ; and/or
the program is configured for authentication communication with the service provider webpage (see Chauhan ¶ [0116] ” . . . the access gateway can correspond to or include the gateway service. The gateway service can determine if the requested network application is a sanctioned network application. The gateway service can determine if a CEB initiated the request. The gateway service can detect or otherwise determine that the request is initiated from a source (e.g., initiated by the standard browser) in the client device other than a CEB. In some embodiments, there is no requirement for a designated gateway service to detect or determine if the request is initiated from a CEB, for example if the requested network application is sanctioned, that user is initiating the request via a standard browser, and/or that the predefined URL and/or corresponding webpage is accessed. . . “) ; and/or
the program is configured for simplification of user interaction (see Chauhan ¶ [0009] ” . . . The method also includes receiving a subsequent recorded sequence of user interactions with a cached version of the network application provided via the embedded browser and stored in a memory of the client computing device, by the one or more application servers from the client computing device, upon reestablishment of a communication session with the client computing device after loss of communications with the client computing device, the sequence of user interactions recorded by the client application during the period of lost communications, the sequence of user interactions modifying data of the cached version of the network application from the first state to a second state. The method also includes executing the recorded sequence of user interactions, by the one or more application servers transparently to the client computing device, to modify data of the network application stored in a storage device of the one or more servers from the first state to the second state; and providing updated data of the network application in the second state to the embedded browser of the client application, by the one or more application servers. . .”).
In regard to claim 8, the combination of Chauhan and Wilson teaches wherein the variables memory (6) is configured for storing encrypted values of variables, wherein information needed for the decryption of the values must be obtained from a server to which the user or the device must authenticate (see Chauhan ¶ [0049] ” . . . The secure applications may access data stored in a secure data container 228 in the managed partition 210 of the client device. The data secured in the secure data container may be accessed by the secure wrapped applications 214, applications executed by a secure application launcher 222, virtualization applications 226 executed by a secure application launcher 218, and the like. The data stored in the secure data container 228 may include files, databases, and the like. The data stored in the secure data container 228 may include data restricted to a specific secure application 230, shared among secure applications 232, and the like. Data restricted to a secure application may include secure general data 234 and highly secure data 238. Secure general data may use a strong form of encryption such as Advanced Encryption Standard (AES) 128-bit encryption or the like, while highly secure data 238 may use a very strong form of encryption such as AES 256-bit encryption. Data stored in the secure data container 228 may be deleted from the device upon receipt of a command from the device manager 224. The secure applications may have a dual-mode option 240. The dual mode option 240 may present the user with an option to operate the secured application in an unsecured or unmanaged mode. In an unsecured or unmanaged mode, the secure applications may access data stored in an unsecured data container 242 on the unmanaged partition 212 of the client device 202. The data stored in an unsecured data container may be personal data 244. The data stored in an unsecured data container 242 may also be accessed by unsecured applications 248 that are running on the unmanaged partition 212 of the client device 202. The data stored in an unsecured data container 242 may remain on the client device 202 when the data stored in the secure data container 228 is deleted from the client device 202. An enterprise may want to delete from the client device selected or all data, files, and/or applications owned, licensed or controlled by the enterprise (enterprise data) while leaving or otherwise preserving personal data, files, and/or applications owned, licensed or controlled by the user (personal data). This operation may be referred to as a selective wipe. With the enterprise and personal data arranged in accordance to the aspects described herein, an enterprise may perform a selective wipe. . . “)
In regard to claim 9, the combination of Chauhan and Wilson teaches wherein the system is configured to synchronize the program memory (5), the variables memory (6) and the trigger rules in the control module (7) between a plurality of devices of the same user (see Chauhan ¶ [0151] ” . . . methods for storing, accessing, and synchronizing data from a SaaS application, enabling SaaS data to be interacted with, regardless of connectivity, while providing secure authentication when offline. During a first time period when online, a user may perform an authentication procedure and provide credentials to an application server, which may provide an authentication token for access to secure data or applications. In some implementations, the authentication token may comprise a shared encryption key or other cryptographic key for decrypting provided data. The authentication token and user credentials may be cached locally. During a second time period when offline or when experiencing intermittent connectivity, a client application on the client device comprising an embedded browser for accessing the network application may act as a local authentication server: the user may provide authentication credentials to the network application. If the credentials match the previously provided and cached credentials, then the client application may retrieve the cached authentication token and allow the embedded browser to resume utilizing the network application and/or data; while if the new credentials do not match the previously provided and cached credentials, access may be denied. To prevent brute-force attacks, the locally cached credentials and/or token may be expired or deleted after a predetermined time period. . . .”).
In regard to claim 10, Chauhan teaches A computer-implemented method of controlling the access of a user to a service provider and/or to a target application, said method (see ¶ [0001], ¶ [0046] as described for the rejection of claim1 and is incorporated herein) comprising the steps of:
a) transmitting from an authentication server (73) of a browser control manager (70) (see Fig. 11 application server 1104, authenticator 1114,(see Fig. 12, ¶ [0157] as described for the rejection of claim 1 and is incorporated herein( to a user device (see Fig. 1 Fig. 11¶ [0038] as described for the rejection of claim1 and is incorporated herein) at least one program and trigger rule(s) for its/their launch (see¶ [0093], as described for the rejection of claim 5 and is incorporated herein) , whereby the at least one program is stored in a program memory (5) (see Fig. 1 non-volatile memory 128) and the trigger rule(s) is/are stored in a control module (7) (see Fig. 1 processor 103) ;
b) receiving a user (8) request to use a service of a service provider (60) and/or to access a service provider (60) data and/or to access a target application of a service provider (60) (see Fig. 11 embedded browser 1108 see ¶ [0154] as described for the rejection of claim1 and is incorporated herein) ,
c) launching a program according to the trigger rule(s) which are fulfilled by the user request (see ¶ [0112] as described for the rejection of claim 5 and is incorporated herein) , said launching step is performed by the control module (7) (see Fig. 1 processor 103) ¶ [0036] as described for the rejection of claim1 and is incorporated herein);
d) transmitting the user request, wherein the request is unauthenticated and unencrypted, to a data channel module (4) (see Fig. 12, ¶ [0157] as described for the rejection of claim1 and is incorporated herein) ;
e) creating a data channel (41) with http/https communication between the data channel module (4) and the service provider (60), initiating authentication by the data channel module (4) (see Fig. 11, ¶ [0153] as described for the rejection of claim1 and is incorporated herein), and
transmitting authentication data from the data channel module (4) to an authenticator (3) (see ¶ [0154] as described for the rejection of claim1 and is incorporated herein); wherein the executed program may provide data for authentication in the target application and/or to the service provider (60) authentication server, (see Fig. 12, ¶ [0157] as described for the rejection of claim1 and is incorporated herein);
wherein if the program specifies the need for user authentication to read the value of the variable, this authentication is performed by the authenticator (3) and the authentication server (73) of the browser control manager (70) or an authentication server (63) of the service provider (60) before passing the value of the variable to the program (see Fig. 12, ¶¶ [0162-0163] as described for the rejection of claim1 and is incorporated herein) ; and/or
if it is required to verify the certificate of the service provider (60) or other communication partner, the program compares the certificate received from the service provider (60) or other communication partner with a copy of the certificate contained in the program or stored in the variable corresponding to the program (see¶ [0053] as described for the rejection of claim1 and is incorporated herein) ;
f) transmitting the user request, via the data channel module (4) and via the data channel (41) to the service provider (60) (see ¶ [0154] as described for the rejection of claim1 and is incorporated herein); and
g) providing the service of the service provider (60) and/or access to the data of the service provider (60) and/or access to the target application of the service provider (60) to the user (see Fig. 12 ¶¶ [0163-0164] “ . . . In step 1218, the receipt of the authentication token, or other methods of establishing an authenticated connection to the network application 1102, allow the embedded browser 1108 to access to the data in the one or more servers 1104. The data accessed from the one or more servers 1104 may be accessible by any user upon authentication credential verification. The data accessed on the one or more servers 1104 can be user-specific, indicating that the specific data can only be accessed by that one user and not everyone else who has access to the one or more servers 1104. The user-specific data may be standard data or secured data, which is protected by any means of encryption. In addition, the user-specific data may be decrypted at the one or more servers 1104 and then transmitted to the embedded browser 1108 and encrypted again, or the user-specific data may be transmitted to the embedded browser 1108 and then decrypted, or any variation of decrypting/encrypting. The decryption may be accomplished by private key methods, for example using the authentication token associated with successful authentication credential verification, or public key methods, or other means of decryption. A description of successful authentication credential verification can be found in steps 1200-1218 . . .”).
Chauhan fails to explicitly teach but Wilson teaches
wherein the request is received via the embedded browser (1) (see Fig. 5 ¶ [0053] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Wilson with Chauhan is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 11, the combination of Chauhan and Wilson teaches wherein the transmitting to the user device is performed so that an authenticator (3) mediates the communication with the browser control manager authentication server (73) over a secure data channel (31) (see Chauhan ¶ [0154]” . . . As a component of the client application 1106, the embedded browser 1108 further has the ability to authenticate the client application 1106 via an authenticator 1110 (sometimes referred to as an authentication client 1110), and the ability to synchronize data flowing across the communication channel 1118 to the network application 1102 via a synchronizer 1112 (sometimes referred to as a client synchronizer or synchronization client 1112). Similarly, the network application 1102 has the ability to verify user authentication via an authenticator 1114 (sometimes referred to as an authentication host, authentication server, or by similar terms), and also synchronize data flowing across the communication channel 1118 from the embedded browser 1108 via a synchronizer 1116 (sometimes referred to as a synchronization host, synchronization server, or a similar term). . . “)
In regard to claim 12, the combination of Chauhan and Wilson teaches wherein the at least one program, the trigger rules and/or the variables are synchronized via synchronization queues on authentication servers (63, 73) (see Chauhan ¶ [0149] “ . . . client devices must be continuously connected to application servers to allow users to interact with the SaaS application, preventing the user from being able to work offline, such as when travelling or with poor or intermittent connectivity. Even in implementations in which some or all of the network application may be cached locally to provide offline use, users may be limited to specific portions of the application or functions, or may be limited in the data they may access. For example, one such implementation of a network application providing email may allow for local caching and offline view of some emails, but may not allow editing, composing new emails or replies. In another example, a network application providing a spreadsheet or database may similarly allow read-only viewing of data, but not allow editing. To counteract this, some implementations provide for synchronization of offline changes when the client device is once again connected to the application servers. However, much of the data or portions of the network application may be identified as non-cacheable, preventing typical browser-based caching mechanisms. . . .”)
In regard to claim 13, the combination of Chauhan and Wilson teaches further comprising the step of:
authenticating the data channel (41) created in step e) and authenticating the user through the authentication communication of the authenticator (3) with the authentication server of the service provider (60) (see Chauhan ¶ [0061] “ . . . Communications between the client agent 304 and gateway server 306 are essentially an extension of the management channel from the application management framework 314 wrapping each native managed application 310. The application management framework 314 requests policy information from client agent 304, which in turn requests it from gateway server 306. The application management framework 314 requests authentication, and client agent 304 logs into the gateway services part of gateway server 306 (also known as NetScaler access gateway). Client agent 304 may also call supporting services on gateway server 306, which may produce input material to derive encryption keys for the local data vaults 316, or provide client certificates which may enable direct authentication to PKI protected resources . . .”)
In regard to claim 14, the combination of Chauhan and Wilson teaches wherein the data channel (41) is preferably bound to the user authentication (see Chauhan ¶ [0062] “ . . .The application management framework 314 “wraps” each managed application 310. This may be incorporated via an explicit build step, or via a post-build processing step. The application management framework 314 may “pair” with client agent 304 on first launch of an application 310 to initialize the Secure IPC channel and obtain the policy for that application. The application management framework 314 may enforce relevant portions of the policy that apply locally, such as the client agent login dependencies and some of the containment policies that restrict how local OS services may be used, or how they may interact with the application 310. . . “)
In regard to claim 15, the combination of Chauhan and Wilson teaches wherein the step of transmitting to the user device requires authentication of the user or their device or the client part of the system to the browser control manager authentication server (73) (see Chauhan ¶ [0152] “ . . . The embedded browser and cached version of the network application may continue to operate normally in such implementations. For example, the embedded browser may display a typical log-in window in which the user may provide credentials, and may attempt to transmit the credentials to an authentication server or application server. While online, the client application may allow the transmission to proceed and/or may forward the transmission to the application server or authentication server. While offline, the client application may intercept the transmission and perform the comparison to locally cached credentials. Thus, the embedded browser may perform authentication agnostic to whether the device is online or offline at that time, requiring no changes to the browser or network application.. . .”).
Conclusion
There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri..
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, John A. Follansbee can be reached on 571-272-3964. 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.
/JAMES N FIORILLO/Examiner, Art Unit 2444
Prosecution Insights