DETAILED ACTION
This office action is in response to the application filed on 03/27/2025. Claim(s) 1-20 is/are pending and are examined.
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 Chinese parent Application No. 202211263500.5, filed on 10/10/2022.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 03/27/2025 and 08/13/2025 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered by the examiner.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 5, 14, 17, and 20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The term “intelligently” in claim 5 is a relative term which renders the claim indefinite. The term “intelligently” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. While the Applicant’s specification gives context, the claim itself doesn’t define what distinguishes “intelligent” revoking from any other automatic revoking. The term is subjective and the claim doesn’t incorporate the spec’s narrowing definitions (gradual vs. one-time).
The dependent claims included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Therefore, they are rejected based on the same rationale as applied to their parent claims above.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (an abstract idea) without significantly more. The following is Examiner’s analysis of the claimed invention.
Step 1 Is the claim to a process, machine, manufacture, or composition of matter? Claim 1 (and dependent claims 2-20) recites a method (process).
Step 2A Prong one: Does the claim recite an abstract idea, law of nature, or natural phenomenon? The claim recites the steps of, “determining whether an application program has behavior of abusing a permission of calling private data; and revoking the permission, of calling the private data, for the application program, in response to the application program having the behavior of abusing the permission of calling the private data.” Which fall with the “Mental Processes” grouping as concepts performed in the human mind (including observation, evaluation, judgment, and opinion). Each of these steps of determining an application programs behavior and revoking the permission is a mental process that can practically be performed in the human mind; therefore, the claimed limitations fall within the mental processes grouping, and the claims recite an abstract idea.
Step 2A Prong two: Does the claim recite additional elements that integrate the judicial exception into a practical application? The claimed preamble, “An application permission management method” generally links the use of the judicial exception to a particular technological environment, therefore the claim as a whole is no more than a drafting effort designed to monopolize the exception. Claim(s) 2-5, and “during the application program calling the private data, checking the permission of calling the private data… determining whether the application program has the behavior of abusing the permission…. determining a severity of the application program abusing the permission…. determining whether a switch for intelligently revoking the permission is turned on”, is so broad as to cover insignificant extra-solution activity.
Step 2B Does the claim recite additional elements that amount to significantly more than the judicial exception? The elements recited in claims 2-8 recite further determinations about the permissions, checks on switches, and displaying a dialog box which amounts to no more than mental processes. Claim 10 using a non-transitory computer readable medium which amounts to no more than mere instructions to apply the exception using a generic computer component. See Two-Way Media Ltd. V. Comcast Cable Communications, LLC, 2017 U.S. App. LEXIS 21706 at 14 (Fed. Cir. Nov. 1, 2017) finding “simply implementing an abstract concept on a computer without meaningful limitations to that concept, does not transform a patent-ineligible claim into a patent-eligible one.” Accenture Global Service v. Guidewire Software, Inc., 728 F.3d 1336 (Fed. Cir. 2013) at 1345; see also the prohibition against patenting an abstract principle by attempting to limit the use of the [principle] to a particular technological environment; Classen an example case identifying a mental process. Specifically, “[c]oncepts relating to data comparisons that can be performed mentally or are analogous to human mental work.” See MPEP 2106.04(a)(2), sections III and III A. Therefore, additionally recited limitations individually or in combination as a whole in Claims 1-20 fail to amount to significantly more than the abstract idea.
The dependent claims included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Therefore, they are rejected based on the same rationale as applied to their parent claims above.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 4, 8-10, 16 and 19 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Rao (US 2022/0269815 A1), hereinafter Rao.
Regarding Claim(s) 1 Rao teaches:
An application permission management method, comprising: (Rao ¶ 4 teaches, The method includes the step of detecting and identifying an access anomaly with respect to the set of data associated with a vendor access. The method includes the step of implementing a specified data minimization process to the access anomaly.)
determining whether an application program has a behavior of abusing a permission of calling private data; and (Rao ¶ 49-50 teaches, process analyzes abnormal request response patterns. For example, if a vendor passes different request patterns than the normal fingerprint, (i.e., application program) then process does not associate abnormal or risky behavior with such a vendor.)
revoking the permission, of calling the private data, for the application program, in response to the application program having the behavior of abusing the permission of calling the private data. (Rao ¶ 49-50 teachers, process determines if abnormal access methods are extant. If a vendor accesses different methods than the normal fingerprinted behavior, process disables access of the risky behavior with any vendor access permissions.)
Regarding Claim(s) 4 Rao teaches:
The application permission management method of claim 1, further comprising: (Rao teaches the parent claim above.)
determining a severity of the application program abusing the permission of calling the private data, in response to the application program having the behavior of abusing the permission of calling the private data; and (Rao ¶ 48-49 teaches, process analyzes abnormal vendor access based on access frequency. If a vendor access has a different access frequency or random access over a period of time, the risk associated with such an access is noted as high.)
revoking the permission, of calling the private data, for the application program, based on the severity. (Rao ¶ 48-49 teaches, In step, process determines if abnormal access methods are extant. If a vendor accesses different methods than the normal fingerprinted behavior, process disables access of the risky behavior with any vendor access permissions. (i.e., if there is deviation process is disabled, maximum severity. Otherwise the process continues, severity level lowest.))
Regarding Claim(s) 6 Rao teaches:
The application permission management method of claim 1, wherein determining whether the application program has the behavior of abusing the permission of calling the private data, comprises: (Rao teaches the parent claim above.)
determining whether the application program has the behavior of abusing the permission of calling the private data, based on at least one piece of following information:
a timing at which the application program calls the private data;
a number of times of the application program calling the private data;
a frequency of the application program calling the private data;
a position at which the application program stores the private data;
a fact that the application program transmits the private data in plaintext;
an object to which the application shares the private data; or
the permission of calling the private data for the application program. (Rao ¶ 48 teaches, process analyzes abnormal vendor access based on access frequency. If a vendor access has a different access frequency (i.e., frequency of call) or random access over a period of time, the risk associated with such an access is noted as high.)
Regarding Claim(s) 8 Rao teaches:
The application permission management method of claim 1, wherein revoking the permission, of calling the private data, for the application program, comprises at least one of: (Rao teaches the parent claim above,)
modifying the permission of calling the private data for the application program
into a permission at a lower level; or
modifying the permission of calling the private data for the application program into a permission at a lowest level. (Rao ¶ 48-49 teaches, In step, process determines if abnormal access methods are extant. If a vendor accesses different methods than the normal fingerprinted behavior, process disables access of the risky behavior with any vendor access permissions. (i.e., lowest level of not allowed))
Regarding Claim(s) 9 Rao teaches:
An electronic device, comprising:
at least one processor; and
a memory, storing thereon at least one computer program which, when executed by the at least one processor, causes the at least one processor to implement the application permission management method of claims 1. (Rao claim 11 teaches, A computer system for automatically identifying and solving for vendor data abuse in an enterprise network, comprising: a processor; a memory containing instructions when executed on the processor, causes the processor to perform operations that)
Regarding Claim(s) 10 Rao teaches:
A non-transitory computer-readable storage medium, storing thereon a computer program which, when executed by a processor, causes the processor to implement the application permission management method of claim 1. (Rao ¶ 54 teaches, it can be appreciated that the various operations, processes, and methods disclosed herein can be embodied in a machine-readable medium and/or a machine accessible medium compatible with a data processing system (e.g., a computer system), and can be performed in any order (e.g., including using means for achieving the various operations). Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. In some embodiments, the machine-readable medium can be a non-transitory form of machine-readable medium.)
Regarding Claim(s) 16 Rao teaches:
The application permission management method of claim 4, wherein revoking the permission, of calling the private data, for the application program, comprises at least one of: (Rao teaches the parent claim above.)
modifying the permission of calling the private data for the application program into a permission at a lower level; or
modifying the permission of calling the private data for the application program into a permission at a lowest level. (Rao ¶ 48-49 teaches, In step, process determines if abnormal access methods are extant. If a vendor accesses different methods than the normal fingerprinted behavior, process disables access of the risky behavior with any vendor access permissions. (i.e., lowest level of not allowed))
Regarding Claim(s) 19 Rao teaches:
The application permission management method of claim 4, wherein
determining whether the application program has the behavior of abusing the permission of calling the private data, comprises: (Rao teaches the parent claim above.)
determining whether the application program has the behavior of abusing the permission of calling the private data, based on at least one piece of following information:
a timing at which the application program calls the private data;
a number of times of the application program calling the private data;
a frequency of the application program calling the private data;
a position at which the application program stores the private data;
a fact that the application program transmits the private data in plaintext;
an object to which the application shares the private data; or the permission of calling the private data for the application program. (Rao ¶ 48 teaches, process analyzes abnormal vendor access based on access frequency. If a vendor access has a different access frequency (i.e., frequency of call) or random access over a period of time, the risk associated with such an access is noted as high.)
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.
Claim(s) 2, 15, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao in view of Singh (US 10,503,904 B1), hereinafter Singh.
Regarding Claim(s) 2 Rao teaches:
The application permission management method of claim 1, wherein whether the application program has the behavior of abusing the permission of calling the private data is determined during the application program calling the private data; and (Rao ¶ 37 teaches, System analyzes the traffic going in-out of any enterprise deployments. For all of this network traffic, the vendor recognizer module recognizes the Auth0 and also the regions)
Rao does not appear to explicitly teach but in related art:
the application permission management method further comprises:
in response to the application program having the behavior of abusing the permission of calling the private data, intercepting the behavior of the application program calling the private data. (Singh Col. 4 Ln. 18-25 teaches, A suspicious process is monitored by the user mode and kernel mode monitors, while the kernel mode agent intercepts any attempt to open a “protected file,” which may be broadly construed as one or more files, one or more folders, one or more file systems and/or any other collection of data in an organized structure, when the suspicious process has permissions to write to, or modify, the protected file.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Rao with Singh, to modify the method for prevention of data abuse of Rao with the intercepting of Singh. The motivation to do so, Singh Col. 3 Ln. 17-18, to prevent infection of an endpoint device, network device, etc.
Regarding Claim(s) 15 Rao in view of Singh teaches:
The application permission management method of claim 2, wherein revoking the permission, of calling the private data, for the application program, comprises at least one of: (Rao in view of Singh teaches the parent claim above.)
modifying the permission of calling the private data for the application program into a permission at a lower level; or
modifying the permission of calling the private data for the application program into a permission at a lowest level. (Rao ¶ 48-49 teaches, In step, process determines if abnormal access methods are extant. If a vendor accesses different methods than the normal fingerprinted behavior, process disables access of the risky behavior with any vendor access permissions. (i.e., lowest level of not allowed))
The motive given in Claim 2 is equally applicable to the above claim.
Regarding Claim(s) 18 Rao in view of Singh teaches:
The application permission management method of claim 2, wherein
determining whether the application program has the behavior of abusing the permission of calling the private data, comprises: (Rao in view of Singh teaches the parent claim above.)
determining whether the application program has the behavior of abusing the permission of calling the private data, based on at least one piece of following information:
a timing at which the application program calls the private data;
a number of times of the application program calling the private data;
a frequency of the application program calling the private data;
a position at which the application program stores the private data;
a fact that the application program transmits the private data in plaintext;
an object to which the application shares the private data; or the permission of calling the private data for the application program. (Rao ¶ 48 teaches, process analyzes abnormal vendor access based on access frequency. If a vendor access has a different access frequency (i.e., frequency of call) or random access over a period of time, the risk associated with such an access is noted as high.)
Claim(s) 3 and 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao in view of Singh as applied to claim 2 above, and further in view of Buck (US 2020/0285761 A1), hereinafter Buck.
Regarding Claim(s) 3 Rao in view of Singh teaches:
The application permission management method of claim 2, further comprising: (Rao in view of Singh teaches the parent claim above.)
Rao in view of Singh does not appear to explicitly teach but in related art:
during the application program calling the private data, checking the permission of calling the private data for the application program; and (Buck ¶ 16 teaches, permissions that an app requests can be checked before installing the app by reading the description in, for example, the Google Play Store)
determining whether the application program has the behavior of abusing the permission of calling the private data, based on the permission of calling the private data for the application program. (Buck ¶ 867 teaches, evaluation server determines a change of context to a new context. The evaluation server causes a permission to be revoked on a mobile device so long as the new context exists.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Rao in view of Singh with Buck, to modify the method for prevention of data abuse of Rao with the intercepting of Singh with the security manager of Buck. The motivation to do so, Buck ¶ 130, to prevent further access to the service by the device.
Regarding Claim(s) 11 Rao-Singh-Buck teaches:
The application permission management method of claim 2, wherein revoking the permission, of calling the private data, for the application program, comprises: (Rao in view of Singh teaches the parent claim above.)
popping up a dialog box for setting the permission of calling the private data for the application program, to enable a user to modify the permission of calling the private data for the application program. (Buck ¶ 808 teaches, each device that receives the above message sends a reply message if the recommended response was performed. For example, the recommended response is disabling of software (e.g., by a user via a user interface of the user's device) and/or changing a permission on a user device (e.g., automatically by MDM software, or by manual input via a user in response to a prompt displayed as an alert on the user's device).)
The motive given in Claim 3 is equally applicable to the above claim.
Regarding Claim(s) 12 Rao-Singh-Buck teaches:
The application permission management method of claim 3, wherein revoking the permission, of calling the private data, for the application program, comprises: (Rao-Singh-Buck teaches the parent claim above.)
popping up a dialog box for setting the permission of calling the private data for the application program, to enable a user to modify the permission of calling the private data for the application program. (Buck ¶ 808 teaches, each device that receives the above message sends a reply message if the recommended response was performed. For example, the recommended response is disabling of software (e.g., by a user via a user interface of the user's device) and/or changing a permission on a user device (e.g., automatically by MDM software, or by manual input via a user in response to a prompt displayed as an alert on the user's device).)
The motive given in Claim 3 is equally applicable to the above claim.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao as applied to claim 1 above, and further in view of Buck.
Regarding Claim(s) 7 Rao teaches:
The application permission management method of claim 1, wherein revoking the permission, of calling the private data, for the application program, comprises: (Rao teaches the parent claim above.)
Rao does not appear to explicitly teach but in related art:
popping up a dialog box for setting the permission of calling the private data for the application program, to enable a user to modify the permission of calling the private data for the application program. (Buck ¶ 808 teaches, Each device that receives the above message sends a reply message if the recommended response was performed. For example, the recommended response is disabling of software (e.g., by a user via a user interface of the user's device) and/or changing a permission on a user device (e.g., automatically by MDM software 1311, or by manual input via a user in response to a prompt displayed as an alert on the user's device).)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Rao in view of Buck, to modify the method for prevention of data abuse of Rao with the security manager of Buck. The motivation to do so, Buck ¶ 130, to prevent further access to the service by the device.
Regarding Claim(s) 13 Rao in view of Buck teaches:
The application permission management method of claim 4, wherein revoking the permission, of calling the private data, for the application program, comprises: (Rao teaches the parent claim above.)
popping up a dialog box for setting the permission of calling the private data for the application program, to enable a user to modify the permission of calling the private
data for the application program. (Buck ¶ 808 teaches, each device that receives the above message sends a reply message if the recommended response was performed. For example, the recommended response is disabling of software (e.g., by a user via a user interface of the user's device) and/or changing a permission on a user device (e.g., automatically by MDM software, or by manual input via a user in response to a prompt displayed as an alert on the user's device).)
The motive given in Claim 7 is equally applicable to the above claim.
Claim(s) 5, 17, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao as applied to claim 1 above, and further in view of Daoura (US 11,799,573 B2), hereinafter Daoura.
Regarding Claim(s) 5 Rao teaches:
The application permission management method of claim 1, further comprising: (Rao teaches the parent claim above.)
in response to the application program having the behavior of abusing the permission of calling the private data, (Rao ¶ 49-50 teaches, process analyzes abnormal request response patterns. For example, if a vendor passes different request patterns than the normal fingerprint, then process 500 does not associate abnormal or risky behavior with such a vendor.)
Rao does not appear to explicitly teach but in related art:
determining whether a switch for intelligently revoking the permission is turned on; and
in response to the switch for intelligently revoking the application permission being turned on, continuing to execute revoking the permission, of calling the private data, for the application program. (Daoura Col. 79 Ln. 27-45 teaches, The executable feature is selectable from, without limitation thereto: (i) make a notification or a display on a user interface of a smart device, (ii) wake up a program or a hardware component of a smart device; (iii) add a timestamp to any sensor data input or radio signal identifier received by a smart device; (iv) add a geostamp to any sensor data input or radio signal identifier received by a smart device; (v) store a sensor data input or a series of sensor data inputs decoded from a series of radio messages from a radiotag; (vi) map a sensor data input or a series of sensor data inputs on a virtual map and display a virtual map on a smart device display; (vii) forward a sensor data payload to a server or a cloud host; (viii) activate or deactivate a permission on a smart device (i.e., the system would check if the activate deactivate permission is enabled.))
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Rao in view of Daoura, to modify the method for prevention of data abuse of Rao with the checking of features enabled of Daoura. The motivation to do so constitutes applying a known technique of checking to see what features are active in a system to known devices and/or methods for permissions handling ready for improvement to yield predictable results allowing a more dynamic permissions flow.
Regarding Claim(s) 17 Rao in view of Daoura teaches:
The application permission management method of claim 5, wherein revoking the permission, of calling the private data, for the application program, comprises at least one of: (Rao in view of Daoura teaches the parent claim above.)
modifying the permission of calling the private data for the application program into a permission at a lower level; or
modifying the permission of calling the private data for the application program into a permission at a lowest level. (Rao ¶ 48-49 teaches, In step, process determines if abnormal access methods are extant. If a vendor accesses different methods than the normal fingerprinted behavior, process disables access of the risky behavior with any vendor access permissions. (i.e., lowest level of not allowed))
Regarding Claim(s) 20 Rao in view of Daoura teaches:
The application permission management method of claim 5, wherein
determining whether the application program has the behavior of abusing the permission of calling the private data, comprises: (Rao in view of Daoura teaches the parent claim above.)
determining whether the application program has the behavior of abusing the permission of calling the private data, based on at least one piece of following information:
a timing at which the application program calls the private data;
a number of times of the application program calling the private data;
a frequency of the application program calling the private data;
a position at which the application program stores the private data;
a fact that the application program transmits the private data in plaintext;
an object to which the application shares the private data; or the permission of calling the private data for the application program. (Rao ¶ 48 teaches, process analyzes abnormal vendor access based on access frequency. If a vendor access has a different access frequency (i.e., frequency of call) or random access over a period of time, the risk associated with such an access is noted as high.)
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rao in view of Daoura as applied to claim 5 above, and further in view of Duck.
Regarding Claim(s) 14 Rao in view of Daoura teaches:
The application permission management method of claim 5, wherein revoking the permission, of calling the private data, for the application program, comprises: (Rao teaches the parent claim above.)
Rao in view of Daoura does not appear to explicitly teach but in related art:
popping up a dialog box for setting the permission of calling the private data for the application program, to enable a user to modify the permission of calling the private data for the application program. (Buck ¶ 808 teaches, each device that receives the above message sends a reply message if the recommended response was performed. For example, the recommended response is disabling of software (e.g., by a user via a user interface of the user's device) and/or changing a permission on a user device (e.g., automatically by MDM software, or by manual input via a user in response to a prompt displayed as an alert on the user's device).)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Rao in view of Daoura with Buck, to modify the method for prevention of data abuse of Rao with the checking of features enabled of Daoura with the security manager of Buck. The motivation to do so, Buck ¶ 130, to prevent further access to the service by the device.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2024/0380748 A1 - A central authorization system comprising i) a plurality of application programming interfaces that receive authorization requests from a plurality of frameworks that execute workflows and ii) an authorization policy server. The authorization policy server receives from a first framework a first authorization request for access to a service by a first workflow.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB BENEDICT KNACKSTEDT whose telephone number is (703)756-5608. The examiner can normally be reached Monday-Friday 8:00 am - 5:00 pm.
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, Linglan Edwards can be reached on (571) 270-5440. 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.
/J.B.K./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights