DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the America Invents Act (AIA ).
Request for Continued Examination (RCE)
An RCE under 37 C.F.R. § 1.114, including the fee set forth in § 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under § 1.114, and the fee set forth in § 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to § 1.114. Applicants’ submission filed on May 6, 2026 has been entered.
Response and Claim Status
The instant Office action is responsive to the response received May 6, 2026 (the Response).
In response to the Response, the previous (1) objection to the Specification under 37 C.F.R. § 1.75(d)(1); (2) rejection of claims 15–17 under 35 U.S.C. § 112(b); and (3) rejection of claims 1–8 and 10–17 under 35 U.S.C. § 103
are WITHDRAWN.
Claims 1–8, 11–14, and 18–25 are currently pending.
Information Disclosure Statement (IDS)
The IDSs filed May 6, 2026 and June 5, 2026 each comply with the provisions of 37 C.F.R. §§ 1.97, 1.98 and MPEP § 609. The IDSs have been placed in the application file, and the information referred to therein has been considered.
Response to Arguments
Applicants’ arguments with respect to the rejection of claims 1, 13, and 14 under 35 U.S.C. § 103 as being obvious over Belisario et al. (US 2014/0068733 A1; Feb. 27, 2013) in view of Kim (US 2015/0089228 A1; Sept. 23, 2014) (see Response 8–10) have been considered but are now moot.
Claim Rejections – 35 U.S.C. § 112
The following is a quotation of 35 U.S.C. § 112(b): “The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.”
Claim 20 is rejected under § 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
In particular, claim 20, lines 2–3, “the browser executable code” lacks clear antecedent basis.
Claim Rejections – 35 U.S.C. § 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.
Todorov and Belisario
Claims 1, 5–8, 11, 13, 14, 19, 20, 23, and 25 are rejected under 35 U.S.C. § 103 as being obvious over Todorov (US 2011/0296509 A1; filed May 27, 2010) in view of Belisario.
Regarding claim 1, while Todorov teaches a method (fig. 4, item 400) for protecting a client computer (fig. 1, item 135; “The client 135 can be a computing system such as a personal computer, a laptop, a PDA, a mobile phone, etc.” at ¶ 13), which includes a processor (fig. 6, item 602) and a display (fig. 6, item 610), the method comprising:
analyzing a web page (fig. 4, item 403) that was downloaded to the client computer;
identifying, by the processor, a password input field (“Web page data 341 can include . . . a password field” at ¶ 24) in the web page;
capturing, after rendering the password input field to the display, an input (“At block 405, the client receives user input of a . . . password” at ¶ 35) to the password input field; and
evaluating the captured input against a specified password policy (fig. 4, item 407; ¶ 35), wherein the evaluating comprises applying a hash function (“If the client receives a web page that includes JavaScript for performing a one-way hash on the password, the client computes a hash value for the password at block 409.” at ¶ 35; fig. 4, item 409) to the captured input, encrypting (fig. 4, items 413, 415; “The client combines . . . the password hash with the CAPTCHA answer at block 413.” at ¶ 36; “At block 415, the client performs a one-way hash function on the combination of . . . the password hash with the CAPTCHA answer and generates a client hash value for the combination.” at ¶ 37) a result of the hash function, and conveying the encrypted result of the hash function to a password analysis server (fig. 4, item 417; fig. 1, item 115),
Todorov does not teach generating an alert upon detecting a violation of the specified password policy.
Belisario teaches generating an alert (“processing continues to step 630 where a message is provided to the user explaining that the password is weak.” at ¶ 61; fig. 6, item 630) upon detecting a violation of a specified password policy (“maintaining strong passwords across the user’s various on-line accounts and websites accessed by the user” at ¶ 36).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Todorov to include generating an alert upon detecting a violation of the specified password policy as taught by Belisario “reducing the likelihood of a breach.” Belisario ¶ 42.
Regarding claim 5, Todorov teaches wherein the captured input comprises a captured password (“At block 405, the client receives user input of a . . . password” at ¶ 35).
Regarding claim 6, Todorov does not teach wherein evaluating the captured input against the specified password policy comprises searching for a specified substring in the captured password, and wherein detecting the violation comprises detecting the specified substring in the captured password.
Belisario teaches searching for a specified substring (“each data item of the user can be compared in whole to all sequential parts of the password. For example, a data item of ABC may be found in a password of XABCYZ.” at ¶ 61) in a captured password (“in step 605, it is determined whether a password is being entered by the user.” at ¶ 60; fig. 6, item 605), and
detecting the specified substring in the captured password (“This comparison can be by using a black and white algorithmic test where any duplication of a data item by any part of the password is deemed weak.” at ¶ 61).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Todorov’s evaluating the captured input against the specified password policy to comprise searching for a specified substring in the captured password and for Todorov’s detecting the violation to comprise detecting the specified substring in the captured password as taught by Belisario “reducing the likelihood of a breach.” Belisario ¶ 42.
Regarding claim 7, Todorov does not teach wherein evaluating the captured input against the specified password policy comprises classifying, using a set of criteria, the captured password as either weak or strong, and wherein detecting the violation comprises classifying the captured password as weak.
Belisario teaches classifying, using a set of criteria (¶ 61), a captured password (“in step 605, it is determined whether a password is being entered by the user.” at ¶ 60; fig. 6, item 605) as either weak or strong (fig. 6, item 625; ¶ 61), and classifying the captured password as weak (Yes to fig. 6, item 625; ¶ 61).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Todorov’s evaluating the captured input against the specified password policy to comprise classifying, using a set of criteria, the captured password as either weak or strong and for Todorov’s detecting the violation to comprise classifying the captured password as weak as taught by Belisario “reducing the likelihood of a breach.” Belisario ¶ 42.
Regarding claim 8, Todorov teaches further comprising rendering a user identifier (ID) input field (“Web page data 341 can include the content for the web page, such as a login form with a user name field” at ¶ 24) on the display, capturing an additional input (“the user to provide a user name” at ¶ 34; fig. 4, item 403) to the user ID field, wherein the captured additional input comprises a captured user ID (“At block 405, the client receives user input of a user name” at ¶ 35; fig. 4, item 405), and wherein evaluating the captured input comprises conveying, to the password analysis server, a tuple (“At block 417, the client sends the data to the server. The client can send the client hash value for the combination and the user name received from the user.” at ¶ 38; fig. 4, item 417) comprising the captured user ID and the captured password.
Regarding claim 11, Todorov does not teach wherein detecting the violation of the specified password policy comprises receiving an indication from the password analysis server that the conveyed tuple comprises a compromised password.
Belisario teaches receiving an indication (yes to fig. 6, item 625; yes to fig. 6, item 645; fig. 7A, item 710; fig. 7B, item 760) from a password analysis server (fig. 3B, item 340) that a conveyed tuple comprises a compromised password (¶¶ 61–62).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Todorov’s detecting the violation of the specified password policy to comprise receiving an indication from the password analysis server that the conveyed tuple comprises a compromised password as taught by Belisario “reducing the likelihood of a breach.” Belisario ¶ 42.
Regarding claim 13, Todorov teaches a client computer (fig. 1, item 135; “The client 135 can be a computing system such as a personal computer, a laptop, a PDA, a mobile phone, etc.” at ¶ 13), comprising: a display (fig. 6, item 610); and one or more processors (fig. 6, item 602) configured to perform operations according to claim 1. Thus, references/arguments equivalent to those present for claim 1 are equally applicable to claim 13.
Regarding claim 14, Todorov teaches a computer software product for protecting a client computer (fig. 1, item 135; “The client 135 can be a computing system such as a personal computer, a laptop, a PDA, a mobile phone, etc.” at ¶ 13), which includes a display (fig. 6, item 610), the computer software product comprising a non-transitory computer-readable medium (fig. 6, item 604), in which program instructions are stored, which instructions, when read by the client computer, cause the client computer to perform operations according to claim 1. Thus, references/arguments equivalent to those present for claim 1 are equally applicable to claim 14.
Regarding claim 19, Todorov does not teach further comprising aborting an attempted login to a web server associated with the web page upon detecting the violation of the specified password policy.
Belisario teaches aborting (Yes to fig. 6, item 640 followed by item 645) an attempted login (Yes to fig. 6, item 605) to a web server (fig. 3B, item 340) associated with a web page (fig. 6, item 600; “monitoring the webpages and accounts accessed to determine if there is a password field to be completed by the user.” at ¶ 60) upon detecting a violation (Yes to fig. 6, item 640) of a specified password policy (“maintaining strong passwords across the user’s various on-line accounts and websites accessed by the user” at ¶ 36).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Todorov to further comprise aborting an attempted login to a web server associated with the web page upon detecting the violation of the specified password policy as taught by Belisario “reducing the likelihood of a breach.” Belisario ¶ 42.
Regarding claim 20, Todorov teaches further comprising, upon determining (Yes to fig. 4, item 407; ¶ 35) that the captured input complies with the specified password policy, forwarding the captured input to the browser executable code (fig. 4, item 409 involves browser executable code) for transmission to a web server (intended use in italics).
Regarding claims 23 and 25, claim 19 recites substantially similar features. Thus, references/arguments equivalent to those present for claim 19 are equally applicable to claims 23 and 25.
Todorov, Belisario, and Magyar
Claim 2 is rejected under 35 U.S.C. § 103 as being obvious over Todorov in view of Belisario, and in further view of Magyar et al. (US 2019/0020646 A1; July 12, 2018).
Regarding claim 2, while Todorov teaches wherein the steps of analyzing, identifying, capturing, evaluating and generating are performed by a web browser (“The client 135 can receive the web page 107 from the server 115 using a general purpose browser 103” at ¶ 20; fig. 1, item 103) configured to download the web page (fig. 4, item 403), and to render the password input field (“Web page data 341 can include . . . a password field” at ¶ 24),
Todorov does not teach the web browser being a browser extension for the web browser.
Magyar teaches a browser extension for a web browser (“user 160 then opens the browser extension 152a within the web browser 152” at ¶ 30).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Todorov’s web browser to be a browser extension for the web browser as taught by Magyar to provide “an improved technique for providing federated login to a password vault.” Magyar ¶ 8.
Todorov, Belisario, and Litty
Claim 3 is rejected under 35 U.S.C. § 103 as being obvious over Todorov in view of Belisario, and in further view of Litty et al. (US 11,979,383 B1; May 3, 2021).
Regarding claim 3, while Todorov teaches wherein identifying the password input field comprises identifying the password input field in the web page (“Web page data 341 can include . . . a password field” at ¶ 24),
Todorov does not teach (A) wherein the web page comprises browser executable code and (B) identifying the password input field in the browser executable code.
Litty teaches a web page comprising browser executable code (“web pages (e.g., comprising HTML . . .)” at 12:39–40); and
identifying a password input field in the browser executable code (“identifying a password field is as an HTML <input> element with a ‘password’ attribute” at 28:21–22).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Todorov’s web page to comprise browser executable code and for Todorov’s identifying the password input field to be in the browser executable code as taught by Litty for providing “improvements to securing computing interactions (e.g., with browsers and websites).” Litty 1:39-40. Moreover, “for protecting a browsing session.” Id. 1:60–61.
Todorov, Belisario, and Lupien
Claim 4 is rejected under 35 U.S.C. § 103 as being obvious over Todorov in view of Belisario, and in further view of Lupien et al. (US 2017/0126653 A1; Oct. 30, 2015).
Regarding claim 4, while Todorov teaches wherein identifying the password input field comprises identifying the password input field in one of input fields (“Web page data 341 can include the content for the web page, such as a login form with a user name field, a password field, and text.” at ¶ 24),
Todorov does not teach (A) wherein the web page comprises browser executable code, and further comprising generating document object model (DOM) elements in response to executing the browser executable code; and (B) identifying the password input field in one or more of the DOM elements.
Todorov teaches wherein a web page comprises browser executable code (“HTML of the web page” at ¶ 30), and further comprising generating document object model (DOM) elements (“Document Object Model (DOM) is a cross-platform and language-independent convention for representing and interacting with objects in HTML” at ¶ 14; “the HTML document has been parsed into the Document Object Model (DOM)” at ¶ 13) in response to executing the browser executable code; and
identifying a password input field in one or more of the DOM elements (“the credential manager application finds a relevant field in the DOM for the web page” at ¶ 21; “DOM objects for a password field may be identified by a ‘type=password’ attribute.” at ¶ 21).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Todorov’s web page to comprise browser executable code, and further comprising generating document object model (DOM) elements in response to executing the browser executable code and for Todorov’s identifying the password input field to be in one or more of the DOM elements as taught by Lupien “for logging a user into the user’s online accounts using web pages received over the internet.” Lupien ¶ 3.
Todorov, Belisario, and Liang
Claims 18, 22, and 24 are rejected under 35 U.S.C. § 103 as being obvious over Todorov in view of Belisario, and in further view of Liang et al. (US 2024/0267210 A1; Feb. 8, 2023).
Regarding claim 18, while Todorov teaches wherein encrypting the result of the hash function comprises encrypting the result of the hash function using a CAPTCHA challenge (“At block 411, the client receives user input of an answer to the CAPTCHA challenge. . . . The client uses the CAPTCHA answer received from the user as `salt` to be added to either the password or the password hash” at ¶ 36; “At block 415, the client performs a one-way hash function on the combination of the password or the password hash with the CAPTCHA answer and generates a client hash value for the combination.” at ¶ 37),
Todorov does not teach the CAPTCHA challenge being an encryption key.
Liang teaches an encryption key (“encryption key” at ¶ 52).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Todorov’s CAPTCHA challenge to be an encryption key as taught by Liang “to protect their computing resources from attackers.” Liang ¶ 24.
Regarding claims 22 and 24, claim 18 recites substantially similar features. Thus, references/arguments equivalent to those present for claim 18 are equally applicable to claims 22 and 24.
Todorov, Belisario, and Ricchuiti
Claim 21 is rejected under 35 U.S.C. § 103 as being obvious over Todorov in view of Belisario, and in further view of Ricchuiti et al. (US 2023/0115553 A1; Oct. 8, 2021).
Regarding claim 21, while Todorov teaches wherein conveying the encrypted result of the hash function to the password analysis server comprises conveying a tuple comprising the encrypted result of the hash function, a user name, and a category (“At block 417, the client sends the data to the server. The client can send the client hash value for the combination and the user name received from the user. The client can also send additional user input, such as form content, or other content, to the web server.” at ¶ 37),
Todorov does not teach the tuple including a web-based application identifier (ID).
Ricchuiti teaches receiving a web-based application ID (“web application identifiers” at ¶ 23).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Todorov’s tuple to include a web-based application ID as taught by Ricchuiti “to ensure protection of the data.” Ricchuiti ¶ 1.
Allowable Subject Matter
Claim 12 is objected to as being dependent upon rejected base claim 1 and intervening claims 5 and 8, but would be allowable if rewritten to include all of the limitations of base claim 1 and intervening claims 5 and 8.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicants’ disclosure: US-8769637-B2.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to DAVID P. ZARKA whose telephone number is (703) 756-5746. The Examiner can normally be reached Monday–Friday from 9:30AM–6PM ET.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Vivek Srivastava, can be reached at (571) 272-7304. 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://portal.uspto.gov/external/portal. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at (866) 217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, Applicants are encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
/DAVID P ZARKA/PATENT EXAMINER, Art Unit 2449
Prosecution Insights