DETAILED ACTION
This Final Office Action is in response to amendment filed on 06/16/2026. Claims 1,6, 7, 8, 9, and 10 have been amended. Claims 5 and 11 have been cancelled. Claims 1-4 and 6-10 remain pending in the application.
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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. KR10-2023-0087857, filed on 07/06/2023.
Drawings
The drawings filed on 08/30/2024 are accepted.
Response to Arguments
Rejections under 35 U.S.C. 101, as set forth in the previous office action mailed on 05/12/2026, have been waived in view of the remarks and claim amendments filed on 06/16/2026.
Claim interpretation under-112(f) and U.S.C. 112 rejections, as set forth in the previous office action mailed on 05/12/2026, has been waived in view of the remarks and claim amendments filed on 06/16/2026.
Regarding 35 U.S.C. § 103, Applicant’s arguments filed on 06/16/2026 have been fully considered but they are not persuasive.
Applicant stated, “The claimed subject matter provides an integrated anti-reverse-engineering architecture for Android applications. It does not merely separate code or protect displayed information in isolation, but instead combines external code offloading, strategic concealment of corresponding strings in a prepared storage space, and dynamic screen-element obfuscation into a coordinated protection framework” on page 8.
Examiner respectfully disagrees. Claim 1 recite the three operations joined only by “and” with no interdependency between them. Its components are “defined by functional distribution distinction rather than physical distinction,” and “the functions of two or more components by be implemented by being included in one component (Spec. p.5 ll. 17-24) – language describing separable, interchangeable functions, not a coordinated mechanism.
Applicant further stated, “Kim does not disclose or suggest storing the separated code on an external server, as recited in amended claim 1. Moreover, Kim's approach is limited to relocating protected code into another local file type and does not teach or suggest coordinated runtime protection of screen elements using multiple pre-prepared obfuscation techniques.” on page 9.
Examiner respectfully disagrees. Kim discloses “hiding a string corresponding to the separated code in a data storage space prepared in advance.” Kim discloses separating protection-target code from an executable file and storing it in a resource file, which is a file physically different from the executable file. A rejection based on a combination of references is not rendered improper by the fact that one reference in the combination does not, by itself, teach a limitation met by another reference.
Applicant further stated “The Examiner further relies on Yi as allegedly teaching storage of separated code on an external server. However, Yi is directed to management of calling codes and dynamic loading of native code via a management server for improving execution security. Yi does not disclose or suggest (i) hiding strings corresponding to separated code in a prepared data storage space, or (ii) protecting runtime screen elements using obfuscation techniques. Thus, Yi addresses a substantially different technical problem than the claimed subject matter.” on page 9.
Examiner respectfully disagrees. Yi discloses “storing it in an external server.” Yi discloses in paragraph [0025] “the control unit 150 separates the calling code from the general code and transmits the separated calling code to the management server 200 for registration.” A rejection based on a combination of references is not rendered improper by the fact that one reference in the combination does not, by itself, teach a limitation met by another reference.
Applicant further stated, “The Examiner additionally relies on Xia for allegedly teaching protection of screen elements. However, Xia is directed to visual privacy protection for displayed sensitive information, such as preventing shoulder surfing. Xia does not disclose or suggest any reverse- obfuscation protection architecture for Android applications. Specifically, Xia fails to teach code separation, external-server-based code management, hidden string insertion into prepared storage spaces, or coordinated application obfuscation. The claimed subject matter employs screen-element obfuscation as one component of an integrated reverse-obfuscation framework, whereas Xia merely provides visual privacy for displayed regions.” on page 9.
Examiner respectfully disagrees. Xia discloses “protecting a screen element of the Android terminal” and, separately from “wherein the protecting the screen element comprises, changing a screen element, which is information output through a screen, by using at least one of a plurality of obfuscation techniques prepared in advance.” Xia is relied upon to teach the first of these limitations in paragraph [0059], disclosing a “designated area configured to display data…in a secure manner,” updated in “real time according to the how the display screen in obscured.” The second limitation is met by Zadina in paragraph [0147], which discloses a displayed content item “shown obfuscated with dots (e.g. obscured text”) instead of text or data content” as one of the several available display options. Applicant’s remarks do not address Zadina, which was of record and was applied, in combination with Kim, Yi, and Xia, against this same claim language when it appeared in former claim 5. A rejection based on a combination of references is not rendered improper by the fact that one reference in the combination does not, by itself, teach a limitation met by another reference
Accordingly, the applied references teach or suggest all the limitations of independent Claims 1 and 7 (which recite similar distinguishing features), as well as the claims depending therefrom. Examiner respectfully submits that the rejections of Claims 1 and 7 (and their dependents) under 35 U.S.C. § 103 remain rejected.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 6, and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim (KR-20160114903-A) in view of Yi (KR-101328012-B1) and Xia (US 20180357984 A1) and in further view of Zadina (US-20220206995-A1).
Regarding claim 1, Kim teaches an obfuscation implementation method in an obfuscation implementation apparatus for preventing a reverse obfuscation attack on an application of an Android terminal, comprising ([2nd paragraph from bottom of Page 5] “[AltContent: ]According to various embodiments, the processor 120 may include a code separation processing module 121, a code concealment processing module 123, and a code obfuscation processing module 125 to obfuscate the codes of the application. The code separation processing module 121 may perform a function of separating at least one or more codes among the codes of the application. According to one embodiment, the code separation processing module 121 can isolate a code selected as a protection target (hereinafter, referred to as a protection target code) in the executable file of the application. In this regard, the electronic device 101 receives information corresponding to the protection target codes through the input / output interface 150, or refers to information corresponding to the protection target codes previously stored in the memory 130 The protection target codes can be selected from an executable file of the application”; [4th paragraph from bottom of Page 7] “3 is a diagram illustrating a method of obfuscating an Android application according to various embodiments”); and
hiding a string corresponding to the separated code in a data storage space prepared in advance (7th paragraph from bottom of page 5] “According to various embodiments, the code concealment processing module 123 may provide the protected codes to another file (e.g., a resource file) that is physically separate from a parent file (e.g., executable file) ). For example, the code concealment processing module 123 separates the protection target codes from an executable file to be attacked during reverse engineering and stores the code in a resource file such as an image, audio, or video, which is a file physically different from the executable file, can do”).
Kim further teaches separating at least a portion of code included in the application and storing it in an external [server] (where "different location" is disclosed in [Page 3])). While Kim discloses separating the code and storing the separated code in a "different location", however, Kim does not explicitly disclose external server, that maybe interpreted as a location outside the device. Yi further teaches separating at least a portion of code included in the application and storing it in an external server ([0025] “After the separation of the general code and the important code is preceded by the code separating unit 120, the control unit 150 separates the calling code from the general code and transmits the separated calling code to the management server 200 for registration. do. The controller 150 adds the calling code loading routine and the vector table loading routine to the function loading routine area”), separating important codes needed to be protected from an application forgery or falsification attack and general codes including call codes for calling the important codes; and separating the call codes from the general codes, and registering in a management server (see claim 1).
Kim and Yi are analogous in systems that implements obfuscation code. Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to have modified Kim to incorporate the teachings of Yi to implement a portion of code and storing it in an external or management server. Doing so would strengthen identifying changes in code and determine appropriate course of action (Yi [0006] “In addition, it is possible to convert the control flow through the dynamic vector, and the calling code which calls the important code converted into the native code, By managing them separately, you can enhance reverse-engineering analysis resistance by allowing applications to be loaded dynamically when they are executed.”).
Kim and Yi discloses an Android terminal and application protection. However, the combination of Kim and Yi does not explicitly disclose the limitation listed below. Xia discloses further protecting a screen element of the Android terminal ([0032] “According to various embodiments of the present disclosure, data displaying can be applied to any scenarios where data or information is to be displayed or presented to a user of a terminal device. Such a terminal device includes, for example, a mobile phone, a smart phone, a tablet computer, a notebook computer, a wearable device, an Internet of Things (IoT) device, an in-vehicle device, a desktop computer, a mobile Internet device (MID), and the like. Corresponding operating systems on these above-described terminal devices include, for example, iOS, Android, Sybian, Windows CE, Windows, and the like”; [0059] “In particular, the first region of the display screen is a designated area configured to display data (e.g., sensitive data or personal data) in a secure manner, which provides for enhanced security to data being displayed in the designated area. A designated first region can be updated in real time according to how the display screen is obscured. For example, the size, shape, position, brightness level, and/or opacity level of the first region can be modified based on which portion of the display screen is detecting an obscured object. After data to be displayed is identified, the first region is configured to display the data to be displayed. In other words, data to be displayed is displayed in a protected region of the display screen”; [0062] “According to various embodiments of the present disclosure, upon identifying data to be displayed, the displaying of data at a user-designated region at the display screen of the mobile device realizes the protection of the displayed data in the designated area, resulting in enhanced guards of users' privacy. As such, sensitive or personal data is less prone to be misappropriated at a mobile device”).
Kim, Yi, and Xia are analogous in systems that implements obfuscation code Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to have modified Kim in view of Yi to incorporate the teachings of Xia and to implement protecting a screen element. Doing so would strengthen security for protecting a mobile device. (Xia [0005] “Therefore, there exists a need for providing a secure and private way of displaying data on mobile device”).
Although Kim discloses an obfuscation implementation method in an obfuscation implementation apparatus for preventing a reverse obfuscation attack on an application of an Android terminal, Yi discloses separating at least a portion of code included in the application and storing it in an external server, and protecting a screen element of the Android terminal; however, the combination of references does not explicitly mention the limitation disclosed below.
Zadina further discloses wherein the protecting the screen element comprises, changing a screen element, which is information output through a screen, by using at least one of a plurality of obfuscation techniques prepared in advance ([0147] “A first example clipboard history UI 1202 includes a first text content item 1204, a first image content item 1206, a second image content item 1208, a second text content item 1210, and a link content item 1212. In this example, the second text content item 1210 is shown obfuscated with dots (e.g., obscured text) instead of text or data content. In addition, a no paste icon 1214 is depicted indicating to the user that the information is not configured to be pasted. For example, if a user selected content item 1210 to paste the item into a document, the system 200 may block the paste operation from occurring based on previously configured settings associated with the clipboard history UI 1202 or previously configured settings associated with the data content item 1210. A user may select a delete all item in UI 1202 to delete all items on the clipboard”), note that when an app displays a content item, the preview is shown in the user interface is hidden, and the actual content is replaced with dots instead of plain text or data; additionally, a text item is kept from being revealed; See paragraph [0151], and claims 11-12 of reference Zadina.
Kim, Yi, Xia, and Zadina are analogous in systems that implements obfuscation code Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to have modified Kim to incorporate the teachings of Zadina to implement changing a screen element. Doing so would strengthen modifying multiple items and determine appropriate course of action (Zadina [0002] “The systems and methods described herein may function to manage an enhanced clipboard history by generating a clipboard history user interface (UI) such that a user may access, modify, and/or simultaneously transfer multiple content items from one application (e.g., app, document, online app, or online document, etc.) to another such application”).
Regarding the non-transitory computer-readable recording medium claim 6 and obfuscation implementation apparatus 7, claims 6 and 7 recite similar limitations as the computer method claim 1, therefore, rejected based on the same rationale as claim 1.
Claim(s) 2 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim (KR-20160114903-A) in view of Yi (KR-101328012-B1), Xia (US 20180357984 A1), Zadina (US-20220206995-A1), and Ferrara (US 20180034857 A1).
Regarding claim 2, the combination of Kim, Yi, Xia, and Zadina teaches all of the limitations listed in claim 1 above. Kim further teaches separating the code ([2nd paragraph from bottom of Page 5] “[AltContent: ]According to various embodiments, the processor 120 may include a code separation processing module 121, a code concealment processing module 123, and a code obfuscation processing module 125 to obfuscate the codes of the application. The code separation processing module 121 may perform a function of separating at least one or more codes among the codes of the application”).
However, the combination of Kim, Yi, Xia, and Ferrara does not explicitly disclose the limitation listed below. Ferrara further teaches identifying data with a possibility of data leakage by performing static contamination analysis on the application ([0024] “Referring now to FIG. 2, system 100 may provide a security framework 200 for structured data-leakage detection and verification. Security framework 200 may track the flow of fine-grained privacy units, including tracking conversions between private objects in an efficient and scalable manner. In some aspects, security framework 200 may include a declarative interface 210, a static analysis component 220, and a policy verification component 230”);
wherein the data with a possibility of data leakage is data having flow starting from a source, which is an entry point of the static contamination analysis, to a sink through which data flows out ([0027] “Static analysis component 220 is configured to track the flow of the fine-grained privacy units. For example, static analysis component 220 may precisely and conservatively model semantic transformations (for example, the conversion of a location into its corresponding address), determine the confidential data that may be leaked, and determine the sink to which the confidential data may be leaked. For example, static analysis component 220 may apply a rich semantic static analysis, where each item of confidential data consists of multiple privacy units, such that the relationships and correlations between the units are modeled explicitly. As an example, a confidential data category “location” may include privacy units such as, for example, longitude, latitude, altitude, city, state, address, etc. For example, the longitude and latitude together may form the user's position. Static analysis component 220 may further account for semantic transformations of the privacy units. For example, if the longitude or latitude is cast into an integer, static analysis component 220 may infer that the fractional unit has been discarded. Based on the static analysis, static analysis component 220 determines what privacy units of confidential data have been leaked to what specific sinks. For example, static analysis component 220 may output pairings of privacy units of confidential data, e.g., longitude, latitude, etc., and the corresponding sinks, e.g., “log”, “write to file,” etc. to which the privacy units of confidential data have been leaked for use by policy verification component 230. In some aspects, the pairing may include more than one privacy unit of confidential data for each corresponding sink”), Note that a static analysis process uses data flow, obtained through reverse obfuscation, closely matches that of the original code. This enables static analysis, which detects source to sink flows and entry points, extracts information from files and performs the actual analysis. As a result, even source and sink data losses that went undetected due to obfuscation can be identified.
Kim,Yi, Xia, Zadina, and Ferrara are analogous in systems that implements detecting data regarding security purposes. Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to have modified Kim in view of Yi, Xia, and Zadina to incorporate the teachings of Ferrara to implement a static analysis process. Doing so would strengthen identifying changes in code and determine appropriate course of action (Ferrara [0014] Privacy testing, verification and enforcement are all problems that have received considerable attention from the research community. For instance, some privacy applications perform static taint-based privacy verification of Android® applications, while others feature low-overhead real-time privacy enforcement by detecting attempts to release sensitive data. ).
Regarding the obfuscation implementation apparatus 8, claim 8 recite similar limitations as the computer method claim 2, therefore, rejected based on the same rationale as claim 2.
Claim(s) 3 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim (KR-20160114903-A) in view of Yi (KR-101328012-B1), Xia (US 20180357984 A1), Zadina (US-20220206995-A1), Ferrara (US 20180034857 A1), and NPL, “Automated Multi-Layered Bytecode Generation for Preventing Sensitive Information Leaks From Android Applications”, August 24, 2021 (Geochang Jeon et al. ) (IEEE, Volume 3) (10.1109/ACCESS.2021.3107601).
Regarding claim 3, Kim discloses wherein a file of the code is a file having an extension of dex, wherein separating the code is separating a dex file of the code, check Kim [Last 3 paragraphs from bottom of page 7]. However, the combination of Kim, Yi, Xia, Zadina, and Ferrari does not explicitly teach the limitation listed below.
Geochang Jeon further discloses the method of claim 2, wherein separating the code is separating a dex file of the code corresponding to the identified data into an SC (sensitive) dex file, a UDC (User Define Class) dex file, and a Classes dex file ([Page 119581, Section IV] “The original dex file will be divided into 3 dex files which are the sensitive code Dex (called SC dex), all of the other user-defined classes Dex (called UDC dex), and classes.dex containing library classes such as java, android, and kotlin. By dividing the original dex file, we can manage them separately. Specifically, if we can hide the SC dex files securely, attackers will not discover sensitive data flows from applications. We discuss how we can achieve this goal in Section V-B”), an original dex file will be divided into three dex files which are sensitive code Dex”) - Note that reference Geochang Jeon et al. discloses (SC dex), user-defined classes Dex (UDC dex), and classes.dex (see pages 119580 and 119581).
Kim, Yi, Xia, Zadina, and Ferrari, and Geochang Jeon are analogous in systems that implements obfuscation code. Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to have modified Kim in view of Yi, Xia, Zadina and Ferrara to incorporate the teachings of Geochang Jeon to implement separating a dex file of the code. Doing so would strengthen identifying changes in code and determine appropriate course of action (Geochang Jeon [Page 119579, Section 1] “Our evaluation results show that AmpDroid can effectively mitigate the ReMaCi attack and show that AmpDroid imposes a reasonable performance and memory overhead on applications in comparison with other state-of-the-art obfuscation tools (i.e., Liapp [11], Obfuscapk [12], and Dexprotector [13])”).
Regarding the obfuscation implementation apparatus claim 9, claim 9 recites similar limitations as the computer method claim 3, therefore, rejected based on the same rationale as claim 3.
Claim(s) 4 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim (KR-20160114903-A) in view of Yi (KR-101328012-B1), Xia (US 20180357984 A1), Zadina (US-20220206995-A1), Ferrara (US-20180034857-A1) and Kao (US 9613223 B2).
Regarding claim 4, the combination of Kim, Yi, Xia, Zadina, and Ferrara discloses all of the limitations listed in claim 2 above. Kim further discloses the method of claim 2, wherein the hiding comprises (7th paragraph from bottom of page 5] “According to various embodiments, the code concealment processing module 123 may provide the protected codes to another file (e.g., a resource file) that is physically separate from a parent file (e.g., executable file) ). For example, the code concealment processing module 123 separates the protection target codes from an executable file to be attacked during reverse engineering and stores the code in a resource file such as an image, audio, or video, which is a file physically different from the executable file, can do”).
extracting the string from the file of the separated code ([7th paragraph from bottom of Page 5] “According to various embodiments, the code concealment processing module 123 may provide the protected codes to another file (e.g., a resource file) that is physically separate from a parent file (e.g., executable file) ). For example, the code concealment processing module 123 separates the protection target codes from an executable file to be attacked during reverse engineering and stores the code in a resource file such as an image, audio, or video, which is a file physically different from the executable file, can do”; [Last paragraph of page 7] “Referring to FIG. 3, the electronic device 101 may obfuscate the Android application 310. The electronic device 101 can separate a specific code (for example, a specific class (classN)) selected as a protection target from an executable file (e.g., classes.dex file) 320 constituting the Android application 310. [ According to one embodiment, the electronic device 101 may generate a temporary file (e.g., a classN.dex file) 350 using the separated specific code”).
identifying a location where the extracted string is to be inserted in the data storage space ([4th paragraph from bottom of Page 5] “[AltContent: ][AltContent: ]According to various embodiments, the memory 130 may store information corresponding to the protected codes. For example, the memory 130 may store information such as classes or functions related to security, such as security, among codes that the electronic device 101 supports. Also, the memory 13 may store information corresponding to the protection-target codes input through the input / output interface 150”; [Page 6] “As described above, the electronic device 101 includes a memory 130 for storing an application and a code for separating some codes from an executable file of the application, adding connection information and loading information of the separated code to the executable file , And a processor (120) for controlling to store the separated partial code in a predetermined portion of the resource file of the application”).
inserting the extracted string into the data storage space, repackaging it, [and then signing it using a signature], thereby generating an Android application package (APK) file in which the string is hidden ([4th paragraph from bottom of page 5] “According to various embodiments, the input / output interface 150 may include at least one of an application input from a user or other external device, a plurality of codes constituting a specific application, or information corresponding to the protected codes, Or to the memory 130 or the like. In addition, the input / output interface150 can output the repackaged application to the user or another external device by separating and concealing the protection target codes by the processor 120”; [Claim 5] “The method according to claim 1,And the processor re-configures the application by packaging the resource file in which at least the executable file in which the partial code is separated and the partial code is stored
However, the combination of Kim, Yi, Xia, Zadina, and Ferrara does not explicitly mention the limitation listed below. Kao further teaches signing it using a signature ([Col 5, lines 27-35] “However, since the Java programming language is easy to be disassembled, in order to avoid attacks of reverse engineering, the repackaging module 110 dynamically obfuscates the first intermediate file to generate at least one second intermediate file. Thereafter, an assembler is used to assemble the second intermediate file, and execute a digital signature procedure required by the Android system on all of the applications, so as to generate the repackaged application”).
Kim, Yi, Xia, Ferrara, and Kao are analogous in systems that implements obfuscation code. Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to have modified Kim in view of Yi, Xia, Zadina, and Ferrara to incorporate the teachings of Kao to implement a signature. Doing so would allow independent threads of the applications based on a sandbox to ensure security of the system”).
Regarding the obfuscation implementation apparatus claim 10, claim 10 recites similar limitations as the computer method claim 4, therefore, rejected based on the same rationale as claim 4.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Barton (US 20140032758 A1) discloses a method for managing applications on mobile devices and their associated policies ([Abstract] “Managed applications are typically allowed to exchange data with other managed applications, but are blocked from exchanging data with other applications, such as the user's own personal applications. Policies may be defined to manage data sharing, mobile resource management, application specific information, networking and data access solutions, device cloud and transfer, dual mode application software, enterprise app store access, and virtualized application and resources, among other things”).
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 VIVIAN D. HO whose telephone number is (571)272-9957. The examiner can normally be reached M- TH 9:00 - 6:00; F 9:00-1:00.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
/VIVIAN D HO/Examiner, Art Unit 2497
/BASSAM A NOAMAN/Primary Examiner, Art Unit 2497
