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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/22/2025 has been entered.
Response to Arguments
Applicant’s arguments, see page 11, filed 4/22/2026, with respect to the rejection of claims 1-20 under 35 USC 112(b) have been fully considered.
Regarding the rejection(s) directed to claim(s) 1-3, 7, 8, 14, and 19:
The issues regarding use of the term “using” in relation to the recited code have not been resolved by amendments. “Using” the “particular code” is indefinite for the same reasons given for “using” a “code snippet.” Please see the updated rejection in the below section titled, Claim Rejections - 35 USC § 112 for further details. This rejection is maintained.
The amendments address the rejection regarding use of the term “code snippet.” This rejection has been withdrawn.
Regarding the rejection(s) directed to claim(s) 1:
The amendments address the rejection regarding the relationship between the “system” and “user device.” This rejection has been withdrawn.
Regarding the rejection(s) directed to claim(s) 3, 4, 15, and 16:
The amendments do not address the rejections regarding these claims being mutually exclusive from their depended-on claims. This rejection is maintained.
Regarding the rejection(s) directed to claim(s) 5:
The amendments do not address the rejection regarding the origin of the copy of the code. This rejection is maintained.
Regarding the rejection(s) directed to claim(s) 12:
The amendments do not address the rejection regarding this claim being mutually exclusive from its depended-on claim. This rejection is maintained.
Applicant's arguments, see pages 11-15, filed 4/22/2026, with respect to the rejection of claims 1-20 under 35 USC 103 have been fully considered.
Regarding the argument:
“… BALDWIN, TIKKANEN, and PRAKASH do not disclose at least "determining, using the copy of the particular code, that the new browser extension is a spoofed version of the browser extension based on whether the first unique identifier of the browser extension matches the second unique identifier of the new browser extension and whether metadata of the browser extension matches metadata of the new browser extension," …
…
“BALDWIN describes a two-program setup. … BALDWIN stresses isolation: the two resources are "separate," potentially "a first operating system" and "a second operating system" under a hypervisor so that "the validation is performed in the second operating system... and, therefore, has no knowledge about the operation of the main operating system" ( BALDWIN para. 21, 23). These are comparisons of code, not unique identifiers.” …
Examiner respectfully disagrees. Neither the specification nor the claims provide an explicit definition of any format, structure, or data type associated with the “unique identifiers.” In fact, the claims themselves indicate that the identifiers are part of and identified in and among the code of the browser extension. Put another way, “comparisons of code” is precisely what is recited by the claims. The mapping to the prior art of BALDWIN is appropriate. This rejection is maintained.
“… BALDWIN does not disclose browser extensions, nor determining whether a new browser extension is a spoofed version based on matching extension unique identifiers and metadata. Its brief mention of "plugins" simply means extra modules added to the agent, the guard tables are updated and a signed reference copy of the plugin is given to the second program so the same hash comparison can include the new code (See BALDWIN para. 35). Even then BALDWIN still relies on integrity comparison between two different programs/domains and does not teach in-browser self-verification or extension spoof detection using identifiers and metadata. …”
Examiner respectfully disagrees. No particular distinction is given to the recited “browser extension” which makes the cited methods of the prior art incompatible with the claims. The claimed invention executes code which locates and compares an “identifier” from one place (extension) with that from another place. The claims are vague or silent regarding the location of the two extensions, their relationship to each other, and the manner in which their “particular code” is “used” to perform the various recited functions. Were the scope of the claims narrowed and the indefiniteness issues under 35 USC 112(b) resolved, it is possible the current prior art would be overcome.
“The cited passage in paragraph 42 of PRAKASH … is about runtime heuristic matching of URL strings. … Comparing heuristics of URLs is not the same as comparing browser extension metadata or identifiers and PRAKASH neither compares browser extension identifiers nor matches browser extension metadata.”
This argument is persuasive. This rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of BALDWIN et al (Doc ID US 20180276374 A1).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. — 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.
Claims 1-20 are rejected under 35 U.S.C. 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.
Regarding claims 1-3, 8, and 14:
The claims each recite various versions of “using” what is referred to as “particular code” and a “copy of the particular code.” It is unclear what “using” means in the context of the claims, as no claim explains where any of the browser extensions (BEs) are located in relation to each other, or what entity is performing the “using.” Given that it is ambiguous what relationship the invention has with any given BE, it is unclear whether “using” particular code located in a BE refers to executing the BE, and by extension the particular code; instructing a device on which the BE is installed to execute the BE/code; searching through the particular code; or some other action.
Regarding claims 3, 4, 15, and 16:
Claim 3 recites, “… accessing … a local file to retrieve the first unique identifier …”. Claim 4 recites, “… accessing a first local file to retrieve a first portion of the first unique identifier …; accessing a second local file to retrieve a second portion of the first unique identifier …”. Claims 15 and 16 recite similar language. The claims are indefinite because they recite mutually exclusive subject matter from their respective depended-on claims. Claim 2, on which claims 3 and 4 depend, recites, “… the particular code includes a first unique identifier …”. Claim 14, on which claims 15 and 16 depend, recites similar language. The depended-on claims are explicit in that the “first unique identifier” is a part of the “particular code” located in the browser extension. The dependent claims contradict this limitation by reciting the “first unique identifier” being instead retrieved from a file or files. This rejection can be overcome by amending the claims such that they are compatible with their depended-on claims.
Regarding claim 5:
Claim 5 recites, “… in response to determining that the copy of the particular code is missing, executing a second copy of the particular code …”. It is unclear from where this “second copy of the particular code” is obtained. The original “particular code” is recited in depended-on claim 2 as being “included in a new browser extension.” It is unclear whether the claimed “second copy” is included elsewhere in the “new browser extension,” or obtained from some other unclaimed location.
Regarding claim 12:
The claim recites, “… retrieving the first unique identifier … comprises: … receiving, from the server, one or more of the plurality of unique identifiers.” The claim is indefinite because they recite mutually exclusive subject matter from their respective depended-on claims. Claim 2, on which claim 12 depends, recites, “… identifying particular code associated with a browser extension, wherein the particular code includes a first unique identifier …”. The depended-on claim is explicit in that the “first unique identifier” is a part of the “particular code” located in the “browser extension.” The dependent claim contradicts this limitation by reciting the “first unique identifier” being instead retrieved from a server as one of a plurality of identifiers. This rejection can be overcome by amending the claim such that it is compatible with its depended-on claim.
Regarding claims 6, 7, 9-11, 13, and 17-20:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 9, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over BALDWIN et al (Doc ID US 20180276374 A1), and further in view of TIKKANEN et al (Doc ID US 20170140150 A1).
Regarding claim 1:
BALDWIN teaches:
A system for identifying fraudulent browser extensions, the system comprising: one or more processors ([0020] "The first processing resource ..., and the second processing resource … are run on a single client system including a processor and memory …"); and
one or more non-transitory, computer-readable media that are configured to cause operations comprising ([0039] "Examples described herein may be realized in the form of ... machine readable instructions .... Any such machine readable instructions may be stored in the form of volatile or non-volatile storage …"):
in response to installation of a new browser extension previously not present ([0035] "… the technique described herein also supports plugin extensions …. Installing the plugin which is combined with checking functionality, allows the plugins to also be covered within the checking network or guard network."):
identifying particular code associated with a browser extension, wherein the particular code includes a first unique identifier that identifies the browser extension ([0037] "… During execution of the program code 100, at 404, a first security value for a part of the program code 100 is calculated …");
retrieving, using a copy of the particular code embedded in the new browser extension and based on an activation of the new browser extension, a second unique identifier that identifies the new browser extension ([0037] "… The validation program 204 receives the first security value at 406 and, at 408, checks the first security value against the second security value calculated from a corresponding part of a reference copy of the program code …"),
wherein the new browser extension comprises at least a partial copy of the browser extension ([0035] "… a certified, for example, signed copy of the plugin may also be given to the validation program 204 as a reference copy so as to allow for the verification of the generated security values.");
determining, using the copy of the particular code that the new browser extension is a spoofed version of the browser extension based on whether the first unique identifier of the browser extension matches the second unique identifier of the new browser extension and whether first metadata of the browser extension matches second metadata of the new browser extension ([0037] "... The validation program 204 receives the first security value at 406 and, at 408, checks the first security value against the second security value … to obtain a check result."); and
Examiner notes that the specification defines metadata in ¶ [0033] as, “... The reference metadata can include characteristics and attributes (e.g., title, release or publication date, hash values, or a unique identifier).” The specification is explicit that the “unique identifiers” are considered exemplary of the metadata and “characteristics and attributes” of the browser extension.
TIKKANEN teaches the following limitation(s) not taught by BALDWIN:
in response to determining that the new browser extension is a spoofed version of the browser extension, executing, using the particular code, an application programming interface (API) function to transmit a notification to an external server, the API function configured to generate information to include in the notification regarding the new browser extension ([0044] "S2. The anti-virus application 7 sends a message to the server 10 requesting ... removal components 16. The message may also include information identifying the nature of the malware 9 …").
Obtaining unique values from a program and a copy of the program, and comparing the values to determine whether they match are known techniques in the art, as demonstrated by BALDWIN. Further, transmitting a notification based on discovering malicious data is a known technique in the art, as demonstrated by TIKKANEN. It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to modify the code matching method of BALDWIN with the browser extension detection of TIKKANEN with the motivation to enable the detection of spoofed extensions through their unique identifiers. It is obvious to use a known technique such as the comparison of identifiers on a particular type of data, such as browser extensions, in order to narrow the scope of the system.
Regarding claim 2:
This claim is rejected with the same justification, mutatis mutandis, as its counterpart claim 1 above.
Regarding claim 3:
The combination of BALDWIN and TIKKANEN teaches:
The method of claim 2, wherein retrieving the first unique identifier further comprises: accessing, using the copy of the particular code, a local file to retrieve the first unique identifier (BALDWIN [0018] "... To validate the first security value 206 a corresponding second security value may be accessed and compared to the first security value 206 provide the check result 210."),
wherein the local file comprises the first unique identifier that identifies the browser extension associated with the particular code, and wherein the local file is stored on a user device that stores the browser extension (BALDWIN [0018] "... the second security value may be calculated remote from the validation program 204 .... The pre-calculated security values ... may be stored in the second processing environment 202 together with the validation program 204.").
Regarding claim 9:
Examiner reiterates the note regarding the specification’s definition of “metadata,” provided in the rejection of claim 1 above.
The combination of BALDWIN and TIKKANEN teaches:
The method of claim 2, further comprising: identifying first metadata from the browser extension associated with the particular code, wherein the first metadata comprises characteristics and attributes of the browser extension (BALDWIN [0037] "… During execution of the program code 100, at 404, a first security value for a part of the program code 100 is calculated …");
identifying second metadata from the new browser extension, wherein the second metadata comprises characteristics and attributes of the new browser extension (BALDWIN [0037] "… The validation program 204 receives the first security value at 406 and, at 408, checks the first security value against the second security value calculated from a corresponding part of a reference copy of the program code …"); and
determining whether the new browser extension is the spoofed version of the browser extension based on comparing the first metadata and the second metadata (BALDWIN [0037] "... The validation program 204 receives the first security value at 406 and, at 408, checks the first security value against the second security value … to obtain a check result.").
Regarding claims 14 and 15:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 1-3 above.
Claims 4, 10, 11, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over BALDWIN et al (Doc ID US 20180276374 A1) and TIKKANEN et al (Doc ID US 20170140150 A1) as applied to claims 2 and 14 above, and further in view of ALSOLAMI (Doc ID US 20210026942 A1).
Regarding claim 4:
The combination of BALDWIN and TIKKANEN teaches:
The method of claim 2, wherein retrieving the first unique identifier comprises: accessing a first local file to retrieve a first portion of the first unique identifier, wherein the first local file is stored on a user device that stores the browser extension (BALDWIN [0018] "... To validate the first security value 206 a corresponding second security value may be accessed and compared to the first security value 206 provide the check result 210.");
ALSOLAMI teaches the following limitation(s) not taught by the combination of BALDWIN and TIKKANEN:
accessing a second local file to retrieve a second portion of the first unique identifier, wherein the second local file is stored on the user device that stores the browser extension ([0188] "2. Split the user ID into eight shares and determine the threshold shares (three shares) by using the secret sharing scheme." Examiner notes that it would be trivial to split the user ID [unique identifier] into fewer shares [portions].); and
combining the first portion of the first unique identifier and the second portion of the first unique identifier, wherein the first unique identifier is a combination of the first portion of the first unique identifier and the second portion of the first unique identifier ([0191] "4. Distribute the fingerprint data over eight cloud storage locations …". Examiner notes that it would be likewise trivial to distribute the shares [portions] to local locations instead of cloud locations.).
Splitting an identifier into at least two portions, stored separately, is a known technique in the art, as demonstrated by ALSOLAMI. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the spoofed extension detection of BALDWIN and TIKKANEN with the portioned identifier of ALSOLAMI with the motivation to prevent illicit access to one file from revealing the entirety of the identifier. It is obvious to portion the sensitive data so that it can be reassembled as needed.
Regarding claim 10:
The combination of BALDWIN and TIKKANEN teaches:
The method of claim 2,
ALSOLAMI teaches the following limitation(s) not taught by the combination of BALDWIN and TIKKANEN:
wherein the first unique identifier of the browser extension is broken apart into a plurality of portions and distributed in the new browser extension ([0191] "4. Distribute the fingerprint data over eight cloud storage locations …"), and
wherein each of the plurality of portions is encoded ([0189] "3. Embed each share of a user ID in his/her a fingerprint data share.").
Splitting an identifier into multiple portions, stored separately, is a known technique in the art, as demonstrated by ALSOLAMI. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the spoofed extension detection of BALDWIN and TIKKANEN with the portioned identifier of ALSOLAMI with the motivation to prevent illicit access to one file from revealing the entirety of the identifier. It is obvious to portion the sensitive data so that it can be reassembled as needed.
Regarding claim 11:
The combination of BALDWIN, TIKKANEN, and ALSOLAMI teaches:
The method of claim 10, wherein encoding the first unique identifier of the browser extension further comprises transforming the first unique identifier into a human-unreadable format (BALDWIN [0010] "… The check may be the calculation of a first security value, e.g., a checksum or a crypto hash.").
Regarding claims 16 and 17:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 4 and 10 above.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over BALDWIN et al (Doc ID US 20180276374 A1) and TIKKANEN et al (Doc ID US 20170140150 A1) as applied to claim 2 above, and further in view of VALENCIA (Doc ID US 20150040112 A1).
Regarding claim 5:
The combination of BALDWIN and TIKKANEN teaches:
The method of claim 2,
VALENCIA teaches the following limitation(s) not taught by the combination of BALDWIN and TIKKANEN:
The method of claim 2, further comprising: determining whether the copy of the particular code is missing ([0022] "… operations to identify necessary portions, segments, data, variables, blocks, functions … missing from the second binary (or the library of the second binary)."); and
in response to determining that the copy of the particular code is missing, executing a second copy of the particular code to determine that the new browser extension is the spoofed version of the browser extension ([0024] "Once … the code associated with the missing functions is identified, the computing device may insert that code into the second binary …").
Identifying and replacing missing code is a known technique in the art, as demonstrated by VALENCIA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the spoofed extension detection of BALDWIN and TIKKANEN with the missing code identification and replacement of VALENCIA with the motivation to make the system aware that necessary code is missing and to replace it so that execution can continue. It is obvious to not attempt to execute code which is found missing from the system.
Claims 6, 7, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over BALDWIN et al (Doc ID US 20180276374 A1) and TIKKANEN et al (Doc ID US 20170140150 A1) as applied to claims 2 and 14 above, and further in view of https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Build_a_cross_browser_extension.
Regarding claim 6:
The combination of BALDWIN and TIKKANEN teaches:
The method of claim 2,
MOZILLA.ORG teaches the following limitation(s) not taught by the combination of BALDWIN and TIKKANEN:
wherein the browser extension is available from a plurality of sources (Website describes developing a cross-platform browser extension for a variety of web browsers.),
wherein each source provides a different unique identifier for the browser extension (Website describes how each web browser extension's implementation would require different programming for various web browsers. These differences would reveal which app store (Chrome, Firefox, Safari, etc.) was the source of the browser extension in question.).
Utilizing browser extensions from multiple sources is a known technique in the art, as demonstrated by MOZILLA.ORG. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the spoofed extension detection of BALDWIN and TIKKANEN with the multiple extension sources of MOZILLA.ORG with the motivation to ensure that the system is capable of differentiating between extensions downloaded from various sources. It is obvious to consider the source of an extension when assessing whether the extension is fraudulent.
Regarding claim 7:
The combination of BALDWIN, TIKKANEN, and MOZILLA.ORG teaches:
The method of claim 6, wherein determining that the new browser extension is the spoofed version of the browser extension further comprises: retrieving a third unique identifier that identifies the browser extension, wherein the third unique identifier that identifies the browser extension associated with the particular code (BALDWIN [0018] "... the second security value may be calculated remote from the validation program 204 .... The pre-calculated security values ... may be stored in the second processing environment 202 together with the validation program 204.");
comparing the second unique identifier of the new browser extension with the third unique identifier (BALDWIN [0037] "... The validation program 204 receives the first security value at 406 and, at 408, checks the first security value against the second security value … to obtain a check result."); and
determining that the second unique identifier of the new browser extension matches the third unique identifier (BALDWIN [0037] "... The validation program 204 receives the first security value at 406 and, at 408, checks the first security value against the second security value … to obtain a check result.").
Regarding claims 18 and 19:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 6 and 7 above.
Claims 8 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over BALDWIN et al (Doc ID US 20180276374 A1) and TIKKANEN et al (Doc ID US 20170140150 A1) as applied to claims 2 and 15 above, and further in view of SVETAL (Doc ID US 20200210665 A1).
Regarding claim 8:
The combination of BALDWIN and TIKKANEN teaches:
The method of claim 2,
SVETAL teaches the following limitation(s) not taught by the combination of BALDWIN and TIKKANEN:
wherein executing, using the particular code, the API function to transmit the notification to the external server comprises a network request and wherein the network request comprises the second unique identifier of the spoofed version of the browser extension ([0022] "… transmit the identifier to a store database server, via a network, in a request for the store database server to correlate the identifier to a price at which the first object is to be sold and to respond to the scanning device with the price;).
Utilizing a network request to transmit data over a network is a known technique in the art, as demonstrated by SVETAL. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the spoofed extension detection of BALDWIN and TIKKANEN with the network request of SVETAL with the motivation to engage in the proper first step in sending data via HTML. It is obvious to use a network request when operating within an HTML framework, as this allows data such as the identifiers to be transmitted to the destination.
Regarding claim 20:
This claim is rejected with the same justification, mutatis mutandis, as its counterpart claim 8 above.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over BALDWIN et al (Doc ID US 20180276374 A1) and TIKKANEN et al (Doc ID US 20170140150 A1) as applied to claim 2 above, and further in view of MENCH et al (Doc ID US 20230214534 A1).
Regarding claim 12:
The combination of BALDWIN and TIKKANEN teaches:
The method of claim 2,
MENCH teaches the following limitation(s) not taught by the combination of BALDWIN and TIKKANEN:
wherein retrieving the first unique identifier corresponding to the browser extension associated with the particular code comprises: transmitting requests to a server ([0032] "… the expected ID database is stored on server 330 ..."),
wherein the server maintains a plurality of unique identifiers ([0032] "… the expected ID database can include an entry for each component type."); and
receiving, from the server, one or more of the plurality of unique identifiers ([0032] "… device 320 queries server 330 to provide the expected ID for the first component type.").
Retrieving stored identifiers from a server is a known technique in the art, as demonstrated by MENCH. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the spoofed extension detection of BALDWIN and TIKKANEN with the identifier retrieval of MENCH with the motivation to keep a master list of known identifiers in a location accessible to dispersed instances of the system. It is obvious to use a server to provide known identifiers as needed so that each device utilizing the system does not need to maintain and update its own repository of identifiers.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over BALDWIN et al (Doc ID US 20180276374 A1) and TIKKANEN et al (Doc ID US 20170140150 A1) as applied to claim 2 above, and further in view of SANTAUS et al (Doc ID US 20240020359 A1).
Regarding claim 13:
The combination of BALDWIN and TIKKANEN teaches:
The method of claim 2,
SANTAUS teaches the following limitation(s) not taught by the combination of BALDWIN and TIKKANEN:
wherein the new browser extension is not verified by a trusted third-party authority ([0042] "FIG. 5 discloses aspects of sharing an untrusted executable."), and
wherein the new browser extension does not have a valid certificate ([0016] "… an operating system may prevent a user from running an executable that … does not have a valid certificate.").
Analyzing data which is not trusted or does not have a valid certificate is a known technique in the art, as demonstrated by SANTAUS. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the spoofed extension detection of BALDWIN and TIKKANEN with the untrusted and uncertified data of SANTAUS with the motivation to pay particular attention to the installation of untrusted and uncertified extensions. It is obvious to consider extensions without a valid certification to be untrustworthy until proven otherwise.
Conclusion
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 BRANDON BINCZAK whose telephone number is (703)756-4528. The examiner can normally be reached M-F 0800-1700.
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, Alexander Lagor can be reached on (571) 270-5143. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BB/Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights