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 13, filed 12/22/2025, with respect to the objection(s) to the abstract of the disclosure have been fully considered and are persuasive. The associated objections to the abstract have been withdrawn.
Applicant’s arguments, see page 14, filed 12/22/2025, with respect to the rejection of claims 1-20 under 35 USC 112(b) have been fully considered; however, the issues have been only partially addressed.
Regarding the rejections directed to claims 1-3, 7, 8, 14, and 19:
issues regarding the use of the term “beacon” have been addressed, and this portion of the rejections is withdrawn.
Issues regarding the relationship between the claimed “new browser extension,” a “browser extension,” and a “user device” have not been sufficiently addressed, and this portion of the rejections is maintained. Please see the below section titled, Claim Rejections - 35 USC § 112 for further details.
Regarding the rejection of claim 5:
While some issues regarding the “first code” have been sufficiently addressed, other issues remain; particularly in regards to the source of the code which is used to replace the code determined to be missing. As these issues were presented in a single rejection, this rejection is withdrawn with the understanding that portions are restated in a new rejection found in the below section titled, Claim Rejections - 35 USC § 112.
Applicant's arguments, see pages 14-15, filed 12/22/2025, with respect to the rejection of claims 1-20 under 35 USC 103 have been fully considered and are persuasive. Therefore, the 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, 7, 8, 14, and 19:
The claims are indefinite because the metes and bounds of the claims are unclear, and it is thus unclear what would constitute infringement of the claims. Each claim group includes a “new browser extension” (hereafter “new BE”), a “browser extension” (hereafter “BE”), and a “user device”. The claims are ambiguous as to some relationships between these elements.
The claims each recite various versions of “using” a code snippet. It is unclear what “using” means in the context of the claims, as no claim explains where any of the BE’s are located. While independent claim 1 indicates the new BE is located on the user device, it is even then unclear what relationship the “system” of claim 1 has with the recited “user device” (i.e. whether the “system” is a part of the device or a distinct entity). Given that it is ambiguous what relationship the invention has with any given BE, it is unclear whether “using” a code snippet located in a BE refers to executing the BE, and by extension the snippet; instructing a device on which the BE is installed to execute the BE/snippet; searching through the code of the snippet; or some other action.
Regarding claims 1-4, 7, 8, 14, and 19:
Where applicant acts as his or her own lexicographer to specifically define a term of a claim contrary to its ordinary meaning, the written description must clearly redefine the claim term and set forth the uncommon definition so as to put one reasonably skilled in the art on notice that the applicant intended to so redefine that claim term. Process Control Corp. v. HydReclaim Corp., 190 F.3d 1350, 1357, 52 USPQ2d 1029, 1033 (Fed. Cir. 1999). The term “code snippet” in the claims is used to refer to a program which performs retrieval of identifiers, comparisons of identifiers, generating notifications, execution of an API to send notifications, accessing multiple files, and combining multiple identifier portions, while the accepted meaning refers to a small amount of reuseable code meant to be inserted as needed. A snippet generally performs a single function or assignment, as opposed to the numerous and varied functions attributed to it in the claims. The term is indefinite because the specification does not clearly redefine the term.
Regarding claim 1:
Examiner first notes that the “system” and “user device” are referred to as separate entities, yet actions taken by the system imply it closely monitors the user device at a minimum, or is perhaps part of the user device itself.
The claim recites, “… in response to installation of a new browser extension …”. The claim goes on to recite, “… retrieving, … based on an activation of a new browser extension …, a second unique identifier associated with the new browser extension …”. It is unclear whether the second recital of a new BE is meant to refer to the same new BE previously recited, or another new BE not previously recited. Given the context and previous understanding of the invention by the examiner, it would be assumed that only one new BE is recited; however, the most recent draft of the claims includes an amendment which changes the second instance from “the new BE” to “a new BE.” This would imply the intent to recite two new BE’s. The ambiguity of the claim renders the claim indefinite.
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 browser extension comprises a code snippet that 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 “code snippet” located in the “browser extension.” The dependent claims contradict this limitation by claiming the “first unique identifier” is 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 code snippet is missing, executing a second copy of the code snippet …”. It is unclear from where this “second copy of the code snippet” is obtained. The original “code snippet” 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 a 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, “…the browser extension comprises a code snippet that includes a first unique identifier …”. The depended-on claim is explicit in that the “first unique identifier” is a part of the “code snippet” located in the “browser extension.” The dependent claim contradicts this limitation by claiming the “first unique identifier” is 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, 9-11, 13, 17, 18, and 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, 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 having instructions recorded thereon that, when executed by the one or more processors, 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 on a user device, executing code comprising ([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 a browser extension, wherein the browser extension comprises a code snippet that includes a first unique identifier corresponding to 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 code snippet and based on an activation of a new browser extension that includes the copy of the code snippet, a second unique identifier associated with 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 code snippet, whether 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 ([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
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 code snippet, 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, using the copy of the code snippet included in a new browser extension, the first unique identifier corresponding to the browser extension associated with the code snippet further comprises: accessing, using the copy of the code snippet, 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 corresponding to the browser extension associated with the code snippet, 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 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 corresponding to the browser extension associated with the code snippet 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 a 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:
further comprising: determining whether the copy of the code snippet 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 code snippet is missing, executing a second copy of the code snippet to determine whether 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, using the code snippet, whether the new browser extension is a spoofed version of the browser extension further comprises: retrieving a third unique identifier corresponding to the browser extension, wherein the third unique identifier corresponds to the browser extension associated with the code snippet (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 whether 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:
The method of claim 2, wherein executing, using the code snippet, the API function to transmit a notification to an 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 9 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 PRAKASH et al (Doc IDUS 20200092326 A1).
Regarding claim 9:
The combination of BALDWIN and TIKKANEN teaches:
The method of claim 2,
PRAKASH teaches the following limitation(s) not taught by the combination of BALDWIN and TIKKANEN:
further comprising: identifying reference metadata from the browser extension associated with the code snippet, wherein the reference metadata comprises characteristics and attributes of the browser extension ([0042] "... The URL store 215 stores assessments of authenticity of each of a plurality of known URLs.");
identifying second metadata from the new browser extension, wherein the second metadata comprises characteristics and attributes of the new browser extension ([0042] "… The browser extension 116 may determine 404 if the received URL matches any known URL in the store 215 …"); and
determining whether the new browser extension is the spoofed version of the browser extension based on comparing the reference metadata and the second metadata ([0042] "... The browser extension 116 may determine 404 if the received URL matches … by comparing the received URL to the known URLs using heuristics.").
Utilizing a network request to transmit data over a network is a known technique in the art, as demonstrated by PRAKASH. 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 PRAKASH 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.
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:
The method of claim 2, wherein retrieving a first unique identifier corresponding to a browser extension associated with the code snippet 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
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
/BENJAMIN E LANIER/Primary Examiner, Art Unit 2437