DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is in response to Application with case number 19/205,644 filed on 5/12/2025 in which claims 1-20 are presented for examination.
Status of Claims
Claims 1-20 are pending, of which claims 1, 19 and 20 are in independent form.
The examiner notes that Abstract does not include any legal phraseology and is less than 15 lines.
The examiner notes that the Specification does not include any URL link(s) and any trademarks requiring capitalization.
The examiner notes that all claims include no limitations that invoke 35 USC § 112 6th paragraph.
IDS
References cited in the IDS filed on 5/12/2025 have been considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum,
686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321 (c) or 1.321 (d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321 (b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-l.jsp.
Claims 1-20 of the instant application are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over the claims 1-19 of US Patent No. 12,299,097.
Although the conflicting claims are not identical, they are not patentably distinct from each other because the subject matter of the instant application would have been obvious to one of ordinary skill in the art in light of the disclosure of each application or patent listed above and because both applications disclose method, apparatus, and memory for allowing or blocking an intercepted call for the particular transaction depending on whether a triggered enhanced user authentication requirement for the particular transaction is met or not.
Limitations of claims 1, 19 and 20 of instant application are included in/similar to the limitations of claims 1, 18 and 19 of US Patent No. 12,299,097. The comparison of the two claims is presented in the table below:
Claim 1 of Instant Application 19/205,644
Claim 1 of US Patent 12,010,120
1. A method, comprising:
intercepting, by a monitoring process, calls made for transactions within an
executing application;
determining, by the monitoring process, whether a particular intercepted call
triggers a user authentication requirement for a particular transaction;
initiating, by the monitoring process in response to the particular intercepted call
triggering the user authentication requirement, a corresponding challenge to adequately authenticate a user for the particular transaction; and
blocking, by the monitoring process, the particular transaction in response to the
corresponding challenge not being completed.
A method, comprising:
intercepting, by a monitoring process and with a Java agent that monitors execution of an executing application with instrumentation, calls made for transactions within the executing application;
determining, by the monitoring process, whether a particular intercepted call triggers an enhanced user authentication requirement for a particular transaction;
initiating, by the monitoring process in response to the particular intercepted call triggering the enhanced user authentication requirement, a corresponding challenge to adequately authenticate a user for the particular transaction; and
allowing, by the monitoring process, the particular intercepted call to proceed for the particular transaction in response to an adequately authenticated user for the particular transaction by passing the particular intercepted call through to a destination of the particular intercepted call.
Limitations of claims 19 and 20 of instant application are similar to the limitations of claim 1 and thus claims 19 and 20 are rejected under the same rationale as in claim 1.
Limitations of claims 1-16 of instant application are similar to the limitations of claims 1-16, respectively, of US Patent No. 12,299,097.
Limitations of claim 17 of instant application are similar to the limitations of claim 16 of US Patent No. 12,299,097.
Limitations of claim 18 of instant application are similar to the limitations of claim 17 of US Patent No. 12,299,097.
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) 1-5, 8, 10, 11-12, 14-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Foley (US 9,684,786 B2), in view of Suen (US 2016/0098710 A1) Suen, and in view of Nair (US 2021/0248249 A1).
As to claim 1, Foley teaches a method, comprising:
intercepting, by a monitoring process (e.g., STAP agents mentioned in col. 2, lines 50-56; e.g., application running in a process virtual machine, see col. 1, lines 39-45; see Figs 1, 2, 4) calls made for transactions within an executing application (see col. 1, lines 41-53, “The method includes receiving an identification of a target class of an application that runs in a process virtual machine on a computer system to a monitoring agent. The method includes configuring the target class for monitoring by listening code. In addition, the method includes running the monitoring agent, the process virtual machine, and the application on the computer system. Further, the method includes collecting data by the listening code and sending the collected data to the monitoring agent by the listening code. Moreover, the method includes sending the collected data to a collector by the monitoring agent. The collector is operable to analyze the collected data to identify an unauthorized access to the application.”; see also col. 8, lines 16-67, It is noted that STAP agent can be installed and listening code injected into the monitoring application using dynamic code instrumentation such that a target method of the target class of the monitored application can be monitored with the injected listening code and the collected data from the intercepted target method call is transmitted to STAP agent and further to collector 104.).
Foley does not explicitly teach but Suen teaches the following limitations -
determining, by the monitoring process (e.g., transaction logic 110 intercepting an attempted transaction (i.e., an incoming request to access an electronic resource) see para. [0019]), whether a particular intercepted call triggers a user authentication requirement for a particular transaction (see para. [0019] “The transaction logic 110 then determines if the attempted transaction requires authentication.”);
initiating, by the monitoring process in response to the particular intercepted call triggering the user authentication requirement, a corresponding challenge to adequately authenticate a user for the particular transaction (see para. [0046]-[0049], “[0049] In one embodiment, there is a matching threshold for each authentication level. For example, as described above, three authentication levels may be defined: light, baseline, and heightened. For example, if the transaction metadata matches 25 instances of a value of a particular factor, then the authentication level is set to light. If the transaction metadata matches 1-24 instances of a value of a factor, then the baseline authentication may be selected. If there are no instances of the transaction metadata, the heightened authentication level may be selected.”; see also para. [0028] “The authentication logic 130 applies a level of authentication to the attempted transaction based on the determination of the activity logic 120 despite any standardized authentication. The user may also select a level of authentication from a spectrum of authentication levels. For example, as described above, the authentication levels may include light, baseline, and heightened. In this example, the levels of authentication correspond to severity of the requirements to authenticate a user. For example, light authentication may require that a user enter a single piece of information (e.g., PIN) or biometrics (e.g., fingerprint, iris recognition, retina recognition facial recognition, hand geometry recognition, signature recognition, typing recognition, voice recognition, etc.). Baseline authentication may include preset authentication techniques for the electronic resource. For example, a bank card and PIN may be required to access an ATM or a username and password combination may be required to access online banking tools. Heightened authentication may include additional authentication techniques to be used in conjunction with the baseline authentication. For example, a user may have to respond to a security question or enter an alphanumeric sent to the user via a known device.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Foley and Suen before him or her, to modify the scheme of monitoring an application in a process virtual machine of Foley by including Suen’s intelligent authentication. The suggestion/motivation for doing so would have been to enhance the Foley with the Suen’s transaction/activity/authentication logic such that the likelihood of the user attempting the transaction is in fact the user can be accessed based on activity log of the user and a level of required authentication can be assigned to the user based on that likelihood on a per transaction basis for ultimate protection of the electronic resource reachable by the transaction, as briefly discussed in Suen para. [0002] and [0006].
The combination of Foley and Suen does not explicitly teach but Nair teaches the following limitation – “blocking, by the monitoring process, the particular transaction in response to the corresponding challenge not being completed” (see para. [0013] “If the user computing device detects data that imposes a risk to the data/processes that cause vulnerabilities to the device/user, the device may determine whether the risk violates any security settings that impose the limitation on device functionality (e.g., application processes) and/or access to the data. If a security setting is violated, the user computing device may apply the limitation to the device, application, data, or other device process/data. The user computing device may allow the limitation to be lifted through user authentication, and may automatically reverse or remove the limitation if the device data and/or proximate data to the device indicates the risk is no longer present.”; see also para. [0026], and [0065]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Foley, Suen, and Nair before him or her, to modify the scheme of Foley and Suen by including Nair’s limiting device functionalities based on data detection and processing. The suggestion/motivation for doing so would have been to enhance the web server application security by using Nair’s contextual nearby risk to limit the functionalities of the application or the transaction such that the limitation on the transaction can be lifted through user’s successful fulfillment of a presented authentication challenge, as briefly discussed briefly in Nair para. [0013]-[0014].
As to claims 19 and 20, claims 19 and 20 include limitations almost similar to claim 1 and thus claims 19 and 20 are rejected under the same rationale as in claim 1.
As to claim 2, in view of claim 1, Suen teaches wherein determining whether the particular intercepted call triggers the user authentication requirement for the particular transaction is based on whether the user is already adequately authenticated for the particular transaction (see para. [0008] “In one embodiment, a user may define an authentication level to be used under specified circumstances. Consider that a user lives with roommates and does not wish the authentication level to be reduced to light authentication when the user is home regardless of whether an online banking session times out. Instead, in this embodiment, the user may select not to allow for light authentication (even if the situation exists in which it is allowed). Accordingly, when the user's online banking session times out, the user's defined authentication levels are implemented. Thus, users have some control over the implementation of the different levels of authentication. The user can choose to forego a lighter version of authentication, however they cannot forgo a stronger version of authentication (if the system determines that it is needed).”; see also para. [0009]).
As to claim 3, in view of claim 2, Suen teaches wherein the user is already authenticated to a first level by the executing application, and wherein the particular transaction requires an enhanced authentication of the user to a higher level than the first level for the user to be adequately authenticated for the particular transaction (see para. [0009] “By dynamically employing authentication requirements based on the historical activity of a user as well as the context of the transaction being attempted (e.g., location, timing, originating device), authentication can be efficiently employed. Specifically, users are not encumbered with unnecessary security obstacles. Moreover, heightened security can be employed for anomalous activity. Thus, a user’s security is flexibly implemented to best meet the needs of that specific user.”; see also para. [0041]; It is noted that user banking session that authenticated user with a light authentication level while the user was at home would require a stronger authentication, after session expiration, than the light level as the time is after 5 pm during the week and/or is in weekend, for the roommates are present during those time periods.).
As to claim 4, in view of claim 2, Suen teaches wherein the user is not authenticated yet by the executing application, and wherein the particular transaction requires an authentication of the user for the user to be adequately authenticated for the particular transaction (see Fig. 4 and para. [0048]; It is noted that the user is authenticated as the user is requesting the transaction.).
As to claim 5 claim 1, Nair teaches determining one or more indicators of behavior of the user, wherein determining whether the particular intercepted call triggers the user authentication requirement for the particular transaction is based at least in part on the one or more indicators of behavior of the user (see para. [0037] “The setting may also be used to determine acceptable number or type of device actions, such as failed authentication attempts and/or application access/use. The settings may also dictate the contextual data that may be required to be detected with the device data, such as a time of day or other context. Once the setting requirements for a limitation have been met, digital wallet application 120 may execute a process to implement the limitation by imposing the required limits on digital wallet application 120 and/or executing the additional processes. Moreover, digital wallet application 120 may also remove the limits once the data is no longer detected, a user authenticates themselves and requests removal of the limitation, and/or other device data is detected that causes removal of the limitation (e.g., the owner or authorized user being within a certain distance of communication device 110).”).
As to claim 8, in view of claim 1, Suen teaches further comprising: determining a geographic location of the user, wherein determining whether the particular intercepted call triggers the user authentication requirement for the particular transaction is based at least in part on the geographic location of the user (see para. [0048] “At 440, the transaction metadata is compared to the factors of the activity log to determine the likelihood that the user is in fact the user. For example, the location that the attempted transaction originated from is compared to locations that the user previously conducted transactions. At 450, an authentication level for the transaction is selected based, at least in part, on the comparison. For example, in response to a match being identified between the transaction metadata and the values of the activity log, an authentication level is selected.”; see also para. [0049]-[0050]).
As to claim 10, in view of claim 1, Suen teaches wherein the corresponding challenge to adequately authenticate the user for the particular transaction comprises a multi-factor authentication (see para. [0004] “Authentication describes a number of methodologies used to verify that the user is in fact the user and not a fraudster impersonating the user. Specifically, a user is an individual attempting to access an electronic resource. Before the user is given access to the electronic resource, the user completes authentication to demonstrate that the user is who he/she claims to be. As described above, for example, authentication may include a username and password combination or a bankcard and PIN combination. Other examples of authentication may include biometric security, PIN alone, security questions, multi-factor authentication in which multiple forms of authentication are required that represent more than one of the following—who the person is, what the person knows, and what the person has.”).
As to claim 11, in view of claim 1, Suen teaches wherein the corresponding challenge to adequately authenticate the user for the particular transaction comprises a biometric identification of the user selected from a group consisting of: facial recognition; fingerprint recognition; and retina scanning (see para. [0028] “…the levels of authentication correspond to severity of the requirements to authenticate a user. For example, light authentication may require that a user enter a single piece of information (e.g., PIN) or biometrics (e.g., fingerprint, iris recognition, retina recognition facial recognition, hand geometry recognition, signature recognition, typing recognition, voice recognition, etc.).”).
As to claim 12, in view of claim 1, Suen teaches further comprising: determining, from a collection of possible challenges, a particular challenge necessary to adequately authenticate the user for the particular transaction (see para. [0028] “The authentication logic 130 applies a level of authentication to the attempted transaction based on the determination of the activity logic 120 despite any standardized authentication. The user may also select a level of authentication from a spectrum of authentication levels. ”).
As to claim 14, in view of claim 1, Suen teaches wherein whether the user is an adequately authenticated user for the particular transaction is based on a sufficient level of confidence that the user is who the user purports to be (see para [0047]-[0051]; It is noted that as the activity logic compares the current activity metadata with previous activity log and as there is a discrepancy as to the purported identity of the user, a stronger authentication level is presented and passing the heightened authentication represents the confidence the user is not a impersonating one.).
As to claim 15, in view of claim 1, Suen teaches wherein the corresponding challenge to adequately authenticate the user for the particular transaction comprises a pop-up window apart from the executing application (see para.[0020] “ In another embodiment, the transaction logic 110 may query the user for identifying information. For example, the user may be asked to provide a username or bankcard.”).
As to claim 16, in view of claim 1, Suen teaches wherein determining whether the particular intercepted call triggers the user authentication requirement for the particular transaction is performed without participation by the executing application (see para. [0049]-[0051]; It is noted that intelligent authentication system separate from the executing application is responsible for adequately authenticating the user for the attempted method for transaction.).
As to claim 17, in view of claim 1, Suen teaches wherein initiating the corresponding challenge to adequately authenticate the user for the particular transaction is performed without participation by the executing application (see para. [0049]-[0051]; It is noted that intelligent authentication system separate from the executing application is responsible for adequately authenticating the user for the attempted method for transaction.).
As to claim 18, in view of claim 1, Foley teaches wherein intercepting calls made for transactions within the executing application comprises intercepting calls into an application programming interface (API) of the executing application with a Java agent monitoring execution of the executing application (see col. 4, lines 39-53 “Embodiments are directed to linking components of an STAP or monitoring agent 103 to listening code 304 in a compiled native application code. This linking may be performed at runtime. In particular, embodiments are directed to a generalized monitoring agent for a process VM. The generalized monitoring agents can be used with the set of known (or hereafter developed) VMs for the Java® virtual machine (JVM or Java VM) specification. In this description, embodiments are described with reference to a typical VM in the set of VMs for the JVM specification. However, generalized agents according to the principles of the invention are not limited for use only with a Java VM.”).
Claim(s) 6, 7, 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Foley, in view of Suen, in view of Nair, and further in view of Zhai (US 2022/0138768 A1).
As to claim 6, in view of claim 5, the combination of Foley, Suen, and Nair does not explicitly teach but Zhai teaches “wherein determining whether the particular intercepted call triggers the user authentication requirement for the particular transaction is based on a machine learning based classification of the one or more indicators of behavior of the user as suspicious behavior” (see para. [0039] “Similarly, blacklist generation device 120 may apply another machine learning model (e.g., a rule-based model) on data of offline transactions 353 (e.g., transaction amount, transaction location, or transaction frequency) to generate rules of suspicious transaction behaviors. For example, an exemplary rule may be that if the transaction frequency exceeds 6 times for a single user within past 24 hours, the authentication information is required.”-[0040], and [0047]-[0052]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Foley, Suen, Nair and Zhai before him or her, to modify the scheme of Foley, Suen, and Nair by including Zhai’s limiting device functionalities based on data detection and processing. The suggestion/motivation for doing so would have been to enhance the web server application transaction security by mandating as a rule to enforce an enhanced authentication as the user transaction behavior is suspiciously deviant from normal user behavior based on a machine learning model.
As to claim 7, in view of claim 5, the combination of Foley, Suen, and Nair does not explicitly teach but Zhai teaches “wherein determining whether the particular intercepted call triggers the user authentication requirement for the particular transaction is based on a machine learning based classification of the one or more indicators of behavior of the user as anomalous behavior” (see para. [0039] “ Similarly, blacklist generation device 120 may apply another machine learning model (e.g., a rule-based model) on data of offline transactions 353 (e.g., transaction amount, transaction location, or transaction frequency) to generate rules of suspicious transaction behaviors. For example, an exemplary rule may be that if the transaction frequency exceeds 6 times for a single user within past 24 hours, the authentication information is required.”-[0040], and [0047]-[0052]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Foley, Suen, Nair and Zhai before him or her, to modify the scheme of Foley, Suen, and Nair by including Zhai’s limiting device functionalities based on data detection and processing. The suggestion/motivation for doing so would have been to enhance the web server application transaction security by mandating as a rule to enforce an enhanced authentication as the user transaction behavior is deviant from normal user behavior based on a machine learning model.
As to claim 9, in view of claim 1, the combination of Foley, Suen, and Nair does not explicitly teach but Zhai teaches “maintaining a list of transactions that require enhanced authentication, wherein determining whether the particular intercepted call triggers the user authentication requirement for the particular transaction is based on the particular transaction being within the list of transactions that require enhanced authentication” (see para. [0040] “Similarly, if the transaction amount exceeds the threshold transaction amount listed in blacklist 305, suspicious transaction determination unit 240 may generate call back 305 to request the user to enter the authentication information in frontend 301.”, and [0047]-[0052]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Foley, Suen, Nair and Zhai before him or her, to modify the scheme of Foley, Suen, and Nair by including Zhai’s limiting device functionalities based on data detection and processing. The suggestion/motivation for doing so would have been to enhance the web server application transaction security by mandating as a rule to enforce an enhanced authentication as the user transaction behavior is deviant from normal user behavior based on a machine learning model.
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Foley, in view of Suen, in view of Nair, and further in view of Himabindu et al. (US 10,915,613 B2) hereinafter Himabindu.
As to claim 13, in view of claim 1, the combination of Foley, Suen, and Nair does not explicitly teach but Himabindu teaches - further comprising: determining a username of the user (see col. 7, lines 34-42, “The authentication module 112a may, in examples in which two factor authentication is used, transmit a request for first authentication information. The request may include a request for a username, PIN, password, or the like. First authentication information response data may be received by the authentication module 112a and the authentication module 112a may determine whether the response data matches pre-stored authentication information (e.g., password, username, and the like). If so, second authentication request information may be generated.”); and determining a current authentication level of the user based on a database lookup using the username (see col. 7, lines 39-43; It is noted that the authentication module 112 determines whether the first authentication is successful or not using the received username and passcode and comparing them against the prestored username and passcode pair before proceeding onto a next authentication challenge.); wherein determining whether the particular intercepted call triggers the enhanced user authentication requirement for the particular transaction is based at least in part on the current authentication level of the user (see col. 7, lines 43-44; It is noted that the second factor authentication is only pursued only if the first factor authentication is verified.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Foley, Suen, Nair and Himabindu before him or her, to modify the scheme of Foley, Suen, and Nair by including Himabindu’s intelligent dynamic authentication system. The suggestion/motivation for doing so would have been to enhance the web server application transaction security by mandating as a rule to enforce an enhanced authentication for a particular transaction by adopting Himabindu’s dynamic authentication challenge that makes unauthorized user obtaining the user authentication credentials impossible.
Verma et al. (US 2017/0011079 A1) teaches tracking and auditing changes in one or more cloud-based systems including, at a Web application, intercepting requests between one or more users and the Web application associated with the one or more cloud-based systems and creating log messages based on the intercepted requests; at a log forwarder in the logging system, forwarding the log messages to a log indexer; at the log indexer in the logging system, receiving the forwarded log messages and indexing the forwarded log messages in a centralized storage; and, at the logging system, responsive to a query, forwarding responsive indexed data from the centralized storage, based on the query.
Suen et al. (US 2016/0098710 A1) teaches intelligent authentication system including a transaction logic configured to receive transaction metadata associated with an attempted transaction and configured to identify a user attempting the attempted transaction. The system further includes an activity logic configured to access an activity log associated with the user, the activity log including values corresponding to previous transactions made by the user and any additional information provided by third party feeds. The activity logic is also configured to compare transaction metadata to the values. The system also includes an authentication logic configured to select an authentication level for the transaction based, at least in part, on the comparison.
Nair (US 2021/0248249 A1) teaches limiting device functionality based on data detection and processing where a user computing device may include sensitive or confidential data and/or processes that utilize such data that a malicious party may wish to abuse, such as an electronic transaction processing application that uses financial data of a user. The device may therefore be compromised by the malicious party if the device becomes accessible to that party. The device may utilize one or more processes to detect device data determine data proximate to the device and/or contextual data in order to determine whether limitations on application processes are required based on the potential nearby risk. If the nearby risk indicates the device application processes may be in danger, the device may impose limitations on the processes and/or wipe data. The device may also alert other devices or nearby users.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HEE K SONG whose telephone number is (571)270-3260. The examiner can normally be reached on M-F 9:00 am – 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Eleni Shiferaw can be reached on (571)272-3867 . The fax phone number for the organization where this application or proceeding is assigned is 571-273-7291.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HEE K SONG/Examiner, Art Unit 2497
