DETAILED ACTION
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the application filed on 07/31/2025.
Claims 1-12 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure Statement(s) filed 07/31/2025, 01/22/2026 and 04/05/2025 have been considered. Initialed copies of the Form 1449 are enclosed herewith.
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-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more, and fails step 2 of the analysis because the focus of the claims is not on the devices themselves or a practical application but rather directed towards an abstract idea, the analysis is provided below.
Step 1 (Statutory Categories) - The claims pass step 1 of the subject matter eligibility test (see MPEP 2106(III)) as the claims are directed towards a system, method and non-transitory computer-readable medium.
Step 2A – Prong One (Do the claims recite an abstract idea?) - The idea is recited in the claims, in part, by:
acquire user information relating to a user who uses a predetermined service; and
determine whether the user information satisfies a predetermined authentication condition relating to an authentication in the predetermined service.
The steps recited above under Step 2A Prong One of the analysis under the broadest reasonable interpretation covers commercial or legal interactions (including sales activities or behaviors; business relations) but for the recitation of generic computer components. That is other than reciting at least one processor, and a (first and second) user terminal nothing in the claim elements are directed towards anything other than commercial or legal interactions for determining whether user information satisfies an authentication condition for a service. If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, then it falls within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas. Accordingly, 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?) - This judicial exception is not integrated into a practical application. In particular, the claims only recite the additional elements of at least one processor, and a (first and second) user terminal. The at least one processor, and a (first and second) user terminal are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components and limits the judicial exception to the particular environment of computers. Mere instructions to apply the judicial exception using generic computer components and limiting the judicial exception to a particular environment are not indicative of a practical application (see MPEP 20106.05(f) and MPEP 20106.05(h)). As MPEP 2106.05(f) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone);. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed towards an abstract idea.
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) - The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, with respect to integration of the abstract idea into a practical application, using the additional elements of at least one processor, and a (first and second) user terminal to perform the steps recited in Step 2A Prong One of the analysis amounts to no more than mere instructions to apply the exception using generic computer components and limits the judicial exception to the particular environment. Mere instructions to apply an exception using generic computer components and limiting the judicial exception to a particular environment does not provide an inventive concept. The additional elements have been considered separately, and as an ordered combination, and do not add significantly more (also known as an “inventive concept”) to the judicial exception. Further, MPEP 2106.05(d)(ii) provides that receiving and transmitting data over a network (see buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), and Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 224-26, 110 USPQ2d 1984-1985 (2014) (see also creating and maintaining "shadow accounts", "create electronic records, track multiple transactions, and issue simultaneous instructions" (, Alice Corp. Pty. Ltd. v. CLS Bank Int'l 573 U.S. at 224-26, 110 USPQ2d at 1984-85);, Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); are well-understood routine and conventional. Further, the displaying step falls to transform the claims into patent eligible material, as this is part of the field of use and technical environment in which the abstract idea is being implement and does not result in an improvement to additional elements (see MPEP 2106.05(h) Electric Power Group court decision). The claims are not patent eligible.
The dependent claims have been given the full analysis including analyzing the additional limitations both individually and in combination as a whole. For instance, claims 2-10 are all steps that fall within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas further defining abstract concepts and generally linking the use of the judicial exemption to a particular technical computing environment similar to as discussed above. The Dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 for the same reasoning as above and the additional recited limitations fail to establish that the claims are not directed to an abstract idea. The additional limitations of the dependent claims when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
Claim Rejections - 35 USC § 102
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 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 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(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-9, and 11-12 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Lindemann (US Patent Application Publication 20250124438).
As per claims 1, 11, and 12, Lindemann discloses:
An authentication system, comprising at least one processor configured to: [0583]
acquire user information relating to a user who uses a predetermined service; and [0077], [0114] The term “relying party” is sometimes used herein to refer, not merely to the entity with which a user transaction is attempted (e.g., a Website or online service performing user transactions), but also to the secure transaction servers implemented on behalf of that entity which may performed the underlying authentication techniques described herein... In one embodiment, once a client device 200 connects to the relying party 250 (e.g., to initiate a transaction), the risk engine 812 determines the risk (or an assurance level) based on all data currently available. This may include, for example, a geo-location of the client device 200 (e.g., as derived from the IP address, or provided by a mobile network operator), the round-trip delay times of packets transmitted between the client device 200 and relying party 250, the number of hops for network packets sent between the client device 200 and relying party 250, a specific “user agent” string sent by a user agent executed on the client device 200, to name a few. In one embodiment, the risk engine 812 then evaluates this data to arrive at an implicit “risk score” (or a preliminary assurance level inversely related to the risk score), which may be used to determine the amount of additional assurance required to authenticate the user for a given transaction.
determine whether the user information satisfies a predetermined authentication condition relating to an authentication in the predetermined service. [0077], [0115], [0120], [0302] In one embodiment, based on the implicit risk score, the adaptive authentication module on the relying party 810 or the client device 800 determines a set of one or more authentication modules 222, 230 with the potential of increasing the overall assurance level to the required level for an intended transaction (i.e., when combined with the preliminary assurance level/implicit risk score). In one embodiment, the assurance level gain analysis module 811 determines the amount of gain required and the adaptive authentication module 800, 810 is provided with an indication of the required assurance level gain as a parameter. The adaptive authentication module 800, 810 then uses this “gain” parameter in order to determine the most convenient set of authentication techniques (non-intrusive 230 and/or explicit 222) in order to achieve (at least) the required gain. The adaptive authentication module 800 may include a formal description of the selected set of authentication techniques in a response to the relying party 250 (e.g. as an authenticated extension). The relying party 250 may then verify whether the resulting overall assurance level meets the required level… In such a case, the risk value may be set to a relatively high value (or, conversely, the implicit assurance level may be low). However, if the user has just recently explicitly authenticated to the device (e.g., entering a PIN), then this would tend to decrease the risk level (or raise the implicit assurance level)… In addition, another non-intrusive technique involves the authentication engine 2610 monitoring the time which has passed since the last explicit user authentication. For example, if the user has authenticated using a fingerprint or other biometric device 2620-2621 or has entered a password recently (e.g., within 10 minutes), then it will use this information to increase the assurance level 2606.
As per claim 2, Lindemann discloses:
wherein the at least one processor is configured to avoid, when it is determined that the user information does not satisfy the predetermined authentication condition, displaying authentication content relating to the authentication on a user terminal of the user, and display, when it is determined that the user information satisfies the predetermined authentication condition, the authentication content on the user terminal. [0120-122], [0302-0306] At 901, the client device connects to the relying party to perform a transaction (e.g., a transaction to log in to an online account, a monetary transaction, etc). At 902, the relying party analyzes any available data related to the client device to determine a risk value and the required assurance level gain needed to authenticate the user. For example, the data may indicate that the user is connecting to the relying party from an unknown network location (e.g., a foreign country never previously visited by the user) and/or that the number of network routing hops or latency between the client and relying party is above a threshold. In such a case, the risk value may be set to a relatively high value (or, conversely, the implicit assurance level may be low). However, if the user has just recently explicitly authenticated to the device (e.g., entering a PIN), then this would tend to decrease the risk level (or raise the implicit assurance level)… In addition, another non-intrusive technique involves the authentication engine 2610 monitoring the time which has passed since the last explicit user authentication. For example, if the user has authenticated using a fingerprint or other biometric device 2620-2621 or has entered a password recently (e.g., within 10 minutes), then it will use this information to increase the assurance level 2606. By contrast, if the user has not explicitly authenticated for several days, then it may require more rigorous authentication by the facial recognition module 2605 and eye tracking module 2605 (e.g., it may require a higher correlation with the template data than usual to increase the assurance level to an acceptable value for the current transaction)…. In one embodiment, the user is prompted to speak a particular sequence of words and/or phrases displayed on the display 2601 of the client device. These may be the same words/phrases or similar words/phrases as those used during the enrollment process so that the voice recognition module 2660 can compare similar voice characteristics to those captured in the voice print.
As per claim 3, Lindemann discloses:
wherein the at least one processor is configured to display, when it is determined that the user information does not satisfy the predetermined authentication condition, other-authentication content relating to another authentication different from the authentication on the user terminal. [0120-122], [0302-0306], [0181], [0229] In one embodiment, the location class determination module 1740 provides the determined class to an authentication policy module 1711 which implements a set of rules to identify the authentication techniques 1712 to be used for the determined class. By way of example, and not limitation, FIG. 18 illustrates an exemplary set of rules 1-5 specifying one or more authentication techniques 1-5 which may be used for each defined location class 1-5. Although illustrated as a table data structure in FIG. 18, the underlying principles of the invention are not limited to any particular type of data structure for implementing the rule set… In such a case, the risk value may be set to a relatively high value (or, conversely, the implicit assurance level may be low). However, if the user has just recently explicitly authenticated to the device (e.g., entering a PIN), then this would tend to decrease the risk level (or raise the implicit assurance level)… In addition, another non-intrusive technique involves the authentication engine 2610 monitoring the time which has passed since the last explicit user authentication. For example, if the user has authenticated using a fingerprint or other biometric device 2620-2621 or has entered a password recently (e.g., within 10 minutes), then it will use this information to increase the assurance level 2606. By contrast, if the user has not explicitly authenticated for several days, then it may require more rigorous authentication by the facial recognition module 2605 and eye tracking module 2605 (e.g., it may require a higher correlation with the template data than usual to increase the assurance level to an acceptable value for the current transaction)…. In one embodiment, the user is prompted to speak a particular sequence of words and/or phrases displayed on the display 2601 of the client device. These may be the same words/phrases or similar words/phrases as those used during the enrollment process so that the voice recognition module 2660 can compare similar voice characteristics to those captured in the voice print… If a fingerprint device is not available, the authentication rule may define other authentication parameters that are acceptable. For example, the user may be required to enter a PIN or password and also to answer a series of personal questions (e.g., previously provided by the user to the relying party).
As per claim 4, Lindemann discloses:
wherein the at least one processor is configured to preferentially display, when it is determined that the user information satisfies the predetermined authentication condition, the authentication content on the user terminal. [0232-0232], [0305] In addition, a rule or set of rules may be used to create ordered, ranked combinations of authentication policies for an interaction. For example, the rules may specify combinations of policies for individual authentication policies, allowing the creation of rich policies that accurate reflect the authentication preferences of the relying party. This would allow, for example, the relying party to specify that fingerprint sensors are preferred, but if none is available, then either trusted platform module (TPM)-based authentication or face recognition are equally preferable as the next best alternatives (e.g., in a prioritized order)… In one embodiment, the user is prompted to speak a particular sequence of words and/or phrases displayed on the display 2601 of the client device. These may be the same words/phrases or similar words/phrases as those used during the enrollment process so that the voice recognition module 2660 can compare similar voice characteristics to those captured in the voice print.
As per claim 5, Lindemann discloses:
wherein the at least one processor is configured to display, when it is determined that the user information satisfies the predetermined authentication condition, other-authentication content relating to another authentication different from the authentication on the user terminal based on a selection status of the authentication content by the user. [0498-0500], see also [0117], [0522-0523], [0548] The secure transaction plugin 4705 receives this information from the secure transaction service 4701 and, in one embodiment, passes the information to the web page's JavaScript via a registered callback. It then chooses how to display the information in the browser 4704. The list, filtered by the website, may be shown to the user and the user may select one or a combination of authentication devices… The enrollment operation may be initiated as soon as devices are detected. The user may choose to use one or a group of discovered devices for enhanced security. In operation, the user may select a device from the displayed device list in the browser, application or mobile device app. For the browser-based implementation illustrated in FIG. 48, the secure transaction plugin 4705 displays a device-specific enrollment graphical user interface (GUI). The secure transaction plugin 4705 transmits the device identifier and an enrollment request to secure transaction service 4701 and waits for completion. If the user is already enrolled with an authentication device on the client, the user may only need to verify their identity (i.e., they will not be required to enroll again)… Alternatively, or in addition, at 5307, the user may be provided with an opportunity to review the list and/or select specific authentication capabilities to be used with this particular server 4730. For example, the filtered list may indicate the option to use authentication with a fingerprint scan, facial recognition, and/or voice recognition. The user may then choose to use one or more of these options when authenticating with the server 4730.
As per claim 6, Lindemann discloses:
determine whether the user information satisfies the predetermined authentication condition for each of a plurality of the authentications; and [0523] Alternatively, or in addition, at 5307, the user may be provided with an opportunity to review the list and/or select specific authentication capabilities to be used with this particular server 4730. For example, the filtered list may indicate the option to use authentication with a fingerprint scan, facial recognition, and/or voice recognition. The user may then choose to use one or more of these options when authenticating with the server 4730.
display, when it is determined that the user information satisfies the predetermined authentication condition for the each of the plurality of the authentications, the authentication content for at least one of the plurality of the authentications on the user terminal based on a priority associated with the each of the plurality of the authentications. [0232-0233], [0523] Alternatively, or in addition, at 5307, the user may be provided with an opportunity to review the list and/or select specific authentication capabilities to be used with this particular server 4730. For example, the filtered list may indicate the option to use authentication with a fingerprint scan, facial recognition, and/or voice recognition. The user may then choose to use one or more of these options when authenticating with the server 4730…In addition, a rule or set of rules may be used to create ordered, ranked combinations of authentication policies for an interaction. For example, the rules may specify combinations of policies for individual authentication policies, allowing the creation of rich policies that accurate reflect the authentication preferences of the relying party. This would allow, for example, the relying party to specify that fingerprint sensors are preferred, but if none is available, then either trusted platform module (TPM)-based authentication or face recognition are equally preferable as the next best alternatives (e.g., in a prioritized order).
As per claim 7, Lindemann discloses:
wherein the at least one processor is configured to determine whether the user information satisfies the predetermined authentication condition by determining whether predetermined information is associated with the user information. [0232], [0344] In addition to explicit user authentication, one embodiment of the authentication engine 3010 collects data from sensors 3043 to be used by the assurance calculation module 3006 to generate the assurance level. By way of example, the sensors 3043 may include location sensors such as GPS sensors to indicate a current location of the user. If the client device 3000 is in an expected location such as the user's work or home, then this increases the likelihood that the user is the legitimate user. By contrast, if the user is in an unexpected location such as a foreign country which the user has not previously visited, then this increases the likelihood that the user is not the legitimate user. Thus, in one embodiment, the assurance calculation module 3006 will tend to increase the assurance level if the user is in an expected location and decrease the assurance level if the user is in an unexpected location…In addition, a rule or set of rules may be used to create ordered, ranked combinations of authentication policies for an interaction. For example, the rules may specify combinations of policies for individual authentication policies, allowing the creation of rich policies that accurate reflect the authentication preferences of the relying party. This would allow, for example, the relying party to specify that fingerprint sensors are preferred, but if none is available, then either trusted platform module (TPM)-based authentication or face recognition are equally preferable as the next best alternatives (e.g., in a prioritized order).
As per claim 8, Lindemann discloses:
wherein the predetermined service comprises a payment service, and [0356] The embodiments of the invention described herein include techniques for authenticating a user for a local transaction initiated through a local secure transaction device. By way of example, the local transaction may be a withdrawal, transfer, or other user-initiated operation and the secure transaction device may be an ATM or other local device capable of executing financial transactions. Similarly, the local transaction may involve completing a payment to purchase goods or services at a retail store or other retail location equipped with a local secure transaction device.
wherein the at least one processor is configured to determine whether the predetermined information relating to a payment type that is settable in the payment service is associated with the user information. [0241-243]m [0356-0358] In response to a successful authentication, the relying party 3351 may transmit a signal to the local secure transaction device 3350 to perform an operation. For example, if the local secure transaction device is an ATM, the signal may instruct the ATM to dispense a specified amount of cash. If the local secure transaction device 3350 is a retail checkout device then an indication of successful payment may be transmitted and the user's account may be debited… At 2403, one or more rules associated with the category of transaction are identified. Returning to the above example, if the transaction is categorized as a “high value transaction” then a rule associated with this transaction type may be selected. At 2404, the rule(s) associated with the transaction type are executed and, as discussed above, information is sent to the client indicating the authentication requirements to complete the transaction.
As per claim 9, Lindemann discloses:
acquire the user information when a user who used the predetermined service from a first user terminal logs in to the predetermined service from a second user terminal different from the first user terminal; and [0406-0410], [0496] In operation, the user authenticates with username and password in browser and logs in to web site. This is the only time that the user will be required to provide a user name and password… In one embodiment, once the secure connection is established between the trusted client device 3902 and new client device 3900, a secure protocol is implemented (described in detail below) to transfer and integrate the registration data from the trusted device to the new device. Once the registrations have been transferred, another secure protocol is implemented (e.g., HTTPS in one embodiment) between the new client device 3900 and relying parties 3950 to verify the registrations.
determine whether the user information satisfies the predetermined authentication condition by determining whether the user owns the first user terminal. [0202], [0406-0410] In one embodiment, once the secure connection is established between the trusted client device 3902 and new client device 3900, a secure protocol is implemented (described in detail below) to transfer and integrate the registration data from the trusted device to the new device. Once the registrations have been transferred, another secure protocol is implemented (e.g., HTTPS in one embodiment) between the new client device 3900 and relying parties 3950 to verify the registrations…For example, using the techniques described herein, a location may be defined as “with my work colleagues” or “at work” where the presence of a set of peer devices known to be owned by the user's work colleagues may be used as a proxy for the risk that needs to be mitigated by authentication policy. For example, if a user is surrounded by a set of known peer devices or other types of network devices, then the user may be deemed to be less of a risk than if no known devices are detected…Rather, in this case, the user must step through the same enrollment and registration process to register the voice authenticator with the relying party. Similarly, if the user purchases a new device with a new set of authenticators, the user must re-enroll and reregister all of the new authenticators with the server.
As per claims 11 and 12 for the method and non-transitory computer-readable medium embodiments of the invention, claims 11 and 12 recite substantially similar limitations to those found in claim 1. Therefor claims 11 and 12 are rejected under the same art and rationale as claim 1. Furthermore, Lindemann discloses a method and non-transitory computer-readable medium [0073], [0346].
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Lindemann (US Patent Application Publication 20250124438) in view of Wang, et al. (US Patent Application Publication 20250182115).
As per claim 10, Lindemann does not expressly disclose the following, Wang, however discloses:
wherein the predetermined service comprises a payment service in which payment is executed by reading a code for payment, and [0114], [0151] A payment request message is generated by the payment acceptance device based on the scanned payment code. After receiving the payment code feedback message, the SDK may display the payment code when making payment. The payment acceptance device scans the payment code and obtains second code information. The second code information is the code information read from the payment code… In some embodiments, the payment may be a payment initiated by a user using a terminal device to display a payment code and others using a payment acceptance terminal to scan the payment code.
wherein the at least one processor is configured to execute, when it is determined that the user information satisfies the predetermined authentication condition, the authentication in which the code for payment displayed on the first user terminal is read by the second user terminal. [0082], [0114], [0151] The host program server may determine the verification operation information based on the information in the user verification method request message. The verification operation information is used to indicate whether to perform user verification and the method of user verification. The host program server may store determination standards for determining whether to perform user verification and the method of user verification, and may determine whether to perform user verification and the method of user verification based on whether the information in the user verification method request message satisfies the reference standards. The determination standards may be configured according to payment scenarios, needs, etc., which are not limited here. For example, the user verification method request message may include payment information, and the payment information may include the payment amount. The determination standards may include a correspondence between the payment amount range and whether to perform user verification and the user verification method... A payment request message is generated by the payment acceptance device based on the scanned payment code. After receiving the payment code feedback message, the SDK may display the payment code when making payment. The payment acceptance device scans the payment code and obtains second code information. The second code information is the code information read from the payment code… In some embodiments, the payment may be a payment initiated by a user using a terminal device to display a payment code and others using a payment acceptance terminal to scan the payment code.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Lindemann with the ability to send payment by displaying a payment code for the others to scan, doing so allows payments to be made via scanning the payment code [0151].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY S CUNNINGHAM II whose telephone number is (313)446-6564. The examiner can normally be reached Mon-Fri 8:30am-4pm.
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, Bennett Sigmond can be reached at 303-297-4411. 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.
GREGORY S. CUNNINGHAM II
Primary Examiner
Art Unit 3694
/GREGORY S CUNNINGHAM II/ Primary Examiner, Art Unit 3694
Prosecution Insights