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 .
Notice Regarding Non-Statutory Double Patenting
Examiner notes that there is presently a non-statutory double patenting rejection potential (as to claims 1 – 20 herein) based upon the allowed claims of the parent patent (US12380414B2) to this application. Presently, at least the allowed parent claims 1, 15, and 16 read on the initial child’s independent claims herein (claims 1, 11, and 18), save the child’s non-disclosure of bank account info respecting the remittance parties, which is obvious in light of the parent’s claims. Examiner will reserve final judgment on any such rejection however until the final claims herein are clearly established, noting that the present claims herein (07/22/2025) are still subject to being amended by Applicant.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 07/07/2025 and 01/27/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner.
Status of Claims
This Office action is in reply to filing by applicant on 07/07/2025.
As to the claims of 07/22/2025:
Claim 1 is amended.
Claims 2 – 20 are new.
Claims 1 – 20 are pending and have been examined.
This action is made non-final.
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 pursuant to 35 USC 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1 – 10 are directed to a method (process), claims 11 – 17 are directed to a method (process), and claims 18 – 20 are directed to a method (process). The claims therefore constitute eligible statutory categories of an invention. (Step 1: YES).
Independent process claim 1 is here analyzed (it reads on independent process claims 11 / 18):
Claim 1 recites the limitations of:
displaying a remittance interface interpolated with the messaging service, wherein the remittance interface is configured to enable remittances based on a temporary profile between users of the messaging service; displaying, through the remittance interface, information on a temporary profile of a remittee without displaying account information of the remittee; receiving, via the remittance interface, a remittance request that comprises a request to transmit an amount to the remittee via the displayed temporary profile; transmitting, to a server, the remittance request; and displaying result information of the remittance request.
Claim 1 recites the abstract idea of:
enabl(ing) remittances based on a temporary profile between users of the messaging service …without displaying account information of the remittee.
The above abstract idea recites a fundamental economic practice and/or commercial interaction, i.e, private remittance transfers between users withholding banking details.
The above limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a fundamental economic practice and/or commercial interaction, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, independent claims 1, 11, and 18 all recite an abstract idea.
The above bolded terms of the mirrored independent claims 1, 11, and 18 recite:
displaying, interface … configured to enable remittances, remittance interface, displayed temporary profile; and a server. Said bolded independent claim terms are just applying generic computer components / computer driven systems to perform the above noted abstract idea limitations. The recitation of generic computer components in a claim does not necessarily preclude that claim from reciting an abstract idea. Any other potential computer related generic components claimed only serve to generally link the above noted abstract idea to said generic computer components, without more. (Step 2A-Prong 1: YES. The claims recite an abstract idea).
As to the dependent claims 2 – 10, 12 – 17, and 19 – 20, they further refine the above noted abstract idea set forth by the independent claims:
Examiner further notes that there are no additional (to the computer related hardware as noted above) computer / computer driven terms set forth in the dependent claims: These dependent claims are also being applied as tools to the abstract idea, without more. Only through dependency do the dependent claims generally link the abstract idea articulated herein as above to generic computer technology.
The computer hardware/software above bolded are recited at a high-level of generality (i.e., generic processors, computer systems, and memories all performing generic computer functions), and the same amounts to no more than mere instructions to apply the exception using a generic computer component(s). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. That said, the claims are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additionally claimed elements in the claims do not integrate the abstract idea into a practical application).
All claims above reviewed also do not include additional elements that are sufficient to amount to significantly more than the judicial exception. When considered separately and as an ordered combination, the claims do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a computer hardware amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to perform a judicial exception by applying generic computer components and thereby automating the process cannot provide an inventive concept.
This Application's lack of providing significantly more than the judicial exception is also referred to as its claims lacking an “inventive concept. See MPEP 2106.05(f) where applying a computer as a tool to the abstract idea is not indicative of significantly more. The above detailed non-computer related elements do not change the outcome of the analysis, as they simply further limit ways which the abstract idea may be performed. (Step 2B: NO. The claims do not provide significantly more than the judicial exception).
In summary, the claim set reviewed as above does not include any additional elements that integrate its abstract idea into a practical application, or that are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
Claims 1 – 20 are not patent-eligible pursuant to 35 USC 101.
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 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 paragraph of 35 U.S.C. 102 that forms the basis for the rejections under this section made in this Office Action:
(a) NOVELTY; PRIOR ART.— A person shall be entitled to a patent unless—
(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;
Claims 1 – 9 and 11 – 20 are rejected under 35 USC 102 (a)(1) as being anticipated by Grassadonia (US20160125371A1).
Regarding claims 1, 11, and 18:
Grassadonia teaches:
Examiner first notes that the Specification in this matter states:
As described above, although the examples have been described with reference to the limited drawings, a person skilled in the art may apply various technical modifications and variations based thereon. For example, suitable results may be achieved if the described techniques are performed in a different order and/or if components in a described system, architecture, device, or circuit are combined in a different manner and/or replaced or supplemented by other components or their equivalents. Accordingly, other implementations are within the scope of the following claims.
Specification, [p. 064]).
Examiner reads the above disclosed statement to at least include the meaning that different embodiments in the art may comprise the examined claims herein. That said:
operating a terminal using a messaging service, the method comprising: displaying a remittance interface interpolated with the messaging service, Examiner broadly interprets this limitation consistent with the Disclosure to include any “interface” associated with a messaging service and also notes that a “remittance” is synonymous with a “money transfer”; (“FIG. 3 illustrates a data flow diagram of an overview of a money transfer process by use of a payment proxy within a messaging application context;”, [005]) and (“Described is a technology for executing financial transactions, e.g., payment transfers, by enabling a sender to trigger a money transfer by specifying a payment proxy having a particular syntax, …”, [Abstract, published 5/5/2016]), and see Grassadonia at Fig’s 2 – 6; an interface is associated with a money transfer;
wherein the remittance interface is configured to enable remittances based on a temporary profile between users of the messaging service; (“Note, the identity of the sender in the message received by the recipient may be displayed as anonymous in some embodiments. In some embodiments, the identity of the sender is displayed using a predefined identifier. The predefined identifier can be the “real” identity of the sender, e.g., the sender's actual payment proxy, actual name, actual user account name, actual email address, and/or any other actual avatar of the sender. Alternatively, the predefined identifier can be any identity preselected by the sender, e.g., a temporary made-up username, a “junk” email address usually used by the sender, etc. Concealment of the sender's identity can be implemented using encryption to map the sender's real identity (e.g., payment proxy of the sender or any other avatar) to a “concealed” address before passing it on to the recipient at the recipient's device.”, [0100]);
displaying, through the remittance interface, information on a temporary profile of a remittee without displaying account information of the remittee; (“In some embodiments, the sender can indicate an intent to transfer money by including a second input in the TO field of the message; more particularly, the sender can specify a payment proxy in the TO field. For example, the user enters into the TO field “$redcross.” In another example, the user enters into the TO field “$aaron.” The second input operates as a unique identifier (ID) or an avatar that identifies the recipient without disclosing recipient's information, such as bank information, email address, etc.”, [037]) and (“the sender can simply enter a payment amount, e.g., in a web entry field, and send the money, e.g., by selecting a “Pay” action button displayed on the web page.”, [043]);
receiving, via the remittance interface, a remittance request that comprises a request to transmit an amount to the remittee via the displayed temporary profile; (“Note, the identity of the sender in the message received by the recipient may be displayed as anonymous in some embodiments. In some embodiments, the identity of the sender is displayed using a predefined identifier. The predefined identifier can be the “real” identity of the sender, e.g., the sender's actual payment proxy, actual name, actual user account name, actual email address, and/or any other actual avatar of the sender. Alternatively, the predefined identifier can be any identity preselected by the sender, e.g., a temporary made-up username, a “junk” email address usually used by the sender, etc. Concealment of the sender's identity can be implemented using encryption to map the sender's real identity (e.g., payment proxy of the sender or any other avatar) to a “concealed” address before passing it on to the recipient at the recipient's device.”, [0100]) and (“A computer system, upon receiving indication of the sender's desire for money transfer (i.e., as indicated by the input(s) having the syntax), initiates the money transfer on behalf of the sender (i.e., executes, or causes to be executed, one or more operations to transfer funds between the appropriate accounts). The transfer can be initiated irrespective of the financial institution with which the sender or the recipient is associated.”, [022]);
transmitting, to a server, the remittance request; (“Consider an example scenario where a user sender can indicate an intent to transfer money by specifying, in a forum message that the user “posts” on a microblog of The Red Cross®, “Here is my support of $10.” In such an example, the microblog can discover the user's intent to send money, e.g., by parsing the message, based on an identification of the syntax in the input “$10.” Note that the parsing can be performed, for example, by a browser client. Alternatively, the parsing can be performed by a server in communication with the browser client.”, [025]);
and displaying result information of the remittance request. (“instructions for causing the web page to be displayed at the sender device, the webpage displaying the monetary value and identity information associated with the recipient account;”, [claim 18]) and (“The recipient 142 can similarly use another given client device 102 to receive the money, for example, by interacting with a confirmation link sent to the client device of the recipient 142 as a result of the money transfer triggered by the sender 140.”, [061]), a remittance result may be displayed.
.
Regarding claims 2 and 12 (claim 12, here mapped, reads on claim 2):
Grassadonia teaches all limitations of claims 1 and 12, respectively:
Grassadonia further teaches:
wherein a remittance corresponding to the remittance request is processed by a remittance server configured to interoperate with the messaging service. (“Consider an example scenario where a user sender can indicate an intent to transfer money by specifying, in a forum message that the user “posts” on a microblog of The Red Cross®, “Here is my support of $10.” In such an example, the microblog can discover the user's intent to send money, e.g., by parsing the message, based on an identification of the syntax in the input “$10.” Note that the parsing can be performed, for example, by a browser client. Alternatively, the parsing can be performed by a server in communication with the browser client.”, [025]).
Regarding claims 3, 14, and 19:
Grassadonia teaches all limitations of claims 1, 11, and 18, respectively:
Grassadonia further teaches:
wherein the displaying the information on the temporary profile of the remittee comprises: receiving, via a chatroom provided via the messaging service, a selection of the temporary profile. (“The messaging application can be employed by a messaging service provider that delivers a communication service to users, e.g., chat or messaging capability. The messaging application can include, for example, a text messaging application for communication between phones (e.g., conventional mobile telephones or smartphones), or a cross-platform instant messaging application for smartphones and phones that use the Internet for communication. The messaging application can be executed on a user's computing device (e.g., mobile device or conventional personal computer (PC)) based on instructions transmitted to and from a messaging computer server system (“messaging server”).”, [030]) and (“Alternatively, the predefined identifier can be any identity preselected by the sender, e.g., a temporary made-up username, a “junk” email address usually used by the sender, etc. Concealment of the sender's identity can be implemented using encryption to map the sender's real identity (e.g., payment proxy of the sender or any other avatar) to a “concealed” address before passing it on to the recipient at the recipient's device.”, [0100]).
Regarding claim 4:
Grassadonia teaches all limitations of claim 1:
Grassadonia further teaches:
displaying a view of a temporary profile of another user account; and displaying the remittance interface through the view of the temporary profile of the other user account, wherein the remittee is determined to be the temporary profile of the other user account. Examiner broadly interprets this claim to include that a remittee’s displayed account may have a transfer made to it (“Alternatively, the predefined identifier can be any identity preselected by the sender, e.g., a temporary made-up username, a “junk” email address usually used by the sender, etc. Concealment of the sender's identity can be implemented using encryption to map the sender's real identity (e.g., payment proxy of the sender or any other avatar) to a “concealed” address before passing it on to the recipient at the recipient's device.”, [0100]) and (“Described is a technology for executing financial transactions, e.g., payment transfers, by enabling a sender to trigger a money transfer by specifying a payment proxy having a particular syntax, the syntax including a monetary indicator preceding one or more alphanumeric characters. The payment proxy having the syntax indicates an intent of the sender to transfer money to a recipient associated with that payment proxy.”, [Abstract, published 5/5/2016]), and see Grassadonia at Fig’s 2 – 6;
Regarding claim 5:
Grassadonia teaches all limitations of claim 1:
Grassadonia further teaches:
wherein the displaying the remittance interface is based on verifying a receipt qualification of a user account associated with the remittee. (“FIGS. 10A-10B illustrate various examples of graphical user interfaces for emails received by recipients of money transfers;”, [012]). see Grassadonia, Fig’s 2 – 6.
Regarding claim 6:
Grassadonia teaches all limitations of claim 1:
Grassadonia further teaches:
wherein, through the remittance interface, information on a first type of temporary profile corresponding to an account whose receipt qualification is verified, and information on a second type of temporary profile corresponding to an account whose receipt qualification is not verified, are displayed in a distinguishable manner. Examiner broadly interprets this claims to include the meaning that both verified and non-verified (no ID verification yet) recipient’s accounts may be displayed, see Grassadonia at Fig’s 2 – 6.
Regarding claim 7:
Grassadonia teaches all limitations of claim 1:
Grassadonia further teaches:
wherein the displaying the remittance interface comprises: receiving, via the remittance interface, an input for selecting one or more temporary profiles, wherein each of the one or more temporary profiles is associated with an account with a verified receipt qualification. (“If the sender 140 does not confirm and/or sends a confirmation (e.g., selects “No” or “Cancel” to cancel the money transfer request), the process 1500 proceeds to block 1520. At block 1520, the communication application 1550 can deliver the message onward to the recipient as an ordinary message (i.e., no money transfer is involved). In some embodiments, when the sender does not confirm, the message does not get delivered. That is, upon determination that there is no intent from then sender to transfer money and/or a determination that the sender would like to cancel the money transfer, the message does not get sent”, [0178]) and (“The predefined identifier can be the “real” identity of the sender, e.g., the sender's actual payment proxy, actual name, actual user account name, actual email address, and/or any other actual avatar of the sender. Alternatively, the predefined identifier can be any identity preselected by the sender, e.g., a temporary made-up username, a “junk” email address usually used by the sender, etc.”, [0100]) and (“The payment proxy having the syntax indicates an intent of the sender to transfer money to a recipient associated with that payment proxy. The payment proxy can be used to transfer money within the context of a landing page. For example, a landing page in the form of a webpage can be generated to enable a recipient (e.g., “Alex”) to receive money.”, [Abstract]), and see Fig’s 2 – 6.
Regarding claim 8:
Grassadonia teaches all limitations of claim 1:
Grassadonia further teaches:
transmitting, to the server, authentication information; and receiving, from the server and in response to the authentication information, a remittance qualification of an account associated with the terminal. (“The message can be a confirmation message that includes a secure link to enter the financial account information, such as a debit card number or a credit card number and associated authentication information (e.g., expire date, ZIP Code, PIN number, or security code).”, [077]) and (“FIG. 6 is a flowchart illustrating an example process of linking a card account for a transfer of money by use of a payment proxy;”, [009]) and (“Consider an example scenario where a user sender can indicate an intent to transfer money by specifying, in a forum message that the user “posts” on a microblog of The Red Cross®, “Here is my support of $10.” In such an example, the microblog can discover the user's intent to send money, e.g., by parsing the message, based on an identification of the syntax in the input “$10.” Note that the parsing can be performed, for example, by a browser client. Alternatively, the parsing can be performed by a server in communication with the browser client.”, [025]).
Regarding claim 9:
Grassadonia teaches all limitations of claim 1:
wherein the result information of the remittance request comprises at least one of: information on a temporary profile of a remitter who transmits the remittance request, or information on the temporary profile of the remittee. (“Alternatively, the predefined identifier can be any identity preselected by the sender, e.g., a temporary made-up username, a “junk” email address usually used by the sender, etc.”, [0100]).
Regarding claim 12:
Grassadonia teaches all limitations of claim 11:
Grassadonia further teaches:
wherein a remittance corresponding to the remittance request is processed by a remittance server configured to interoperate with the messaging service. (“Consider an example scenario where a user sender can indicate an intent to transfer money by specifying, in a forum message that the user “posts” on a microblog of The Red Cross®, “Here is my support of $10.” In such an example, the microblog can discover the user's intent to send money, e.g., by parsing the message, based on an identification of the syntax in the input “$10.” Note that the parsing can be performed, for example, by a browser client. Alternatively, the parsing can be performed by a server in communication with the browser client.”, [025]).
Regarding claim 13:
Grassadonia teaches all limitations of claim 12:
Grassadonia further teaches:
wherein the account information of the remittee mapped to the temporary profile is transmitted to the remittance server from a messaging server configured to provide the messaging service. (“Consider an example scenario where a user sender can indicate an intent to transfer money by specifying, in a forum message that the user “posts” on a microblog of The Red Cross®, “Here is my support of $10.” In such an example, the microblog can discover the user's intent to send money, e.g., by parsing the message, based on an identification of the syntax in the input “$10.” Note that the parsing can be performed, for example, by a browser client. Alternatively, the parsing can be performed by a server in communication with the browser client.”, [025]).
Regarding claim 15:
Grassadonia teaches all limitations of claim 14:
Grassadonia further teaches:
wherein the outputting the result information of the remittance request comprises: displaying, in the anonymous chatroom, a message including the result information of the remittance request. (“At block 1514, the PSS 560 causes a message to be sent to the sender 140 to prompt for a confirmation that the sender 140 wishes to transfer the money. For example, the PSS 560 sends a message to the communication application 1550 to cause it to display a message to prompt the sender for the confirmation, as indicated in block 1516.”, [0177]).
Regarding claim 16:
Grassadonia teaches all limitations of claim 11:
Grassadonia further teaches:
wherein the receiving the user input comprises: receiving, via a view of the temporary profile, the user input for the remittance request. See Fig’s 2 – 6.
Regarding claim 17:
Grassadonia teaches all limitations of claim 11:
Grassadonia further teaches:
wherein the result information of the remittance request further comprises: information on a second temporary profile of a remitter who transmitted the remittance request. Examiner broadly interprets this claim to include that there can be a second sender, i.e., money can be sent by a multiplicity of users that use the program, all possessing a temporary profile. (“Note that while the process 500 is described for a particular sender sending money to the recipient 502, in other embodiments, the process 500 can be executed for multiple senders (e.g., sender 501 1-N, where N is an integer greater than N), where each sender can send money to the recipient 502 via the set of operations involved in the process 500. In such embodiments, the individual payment amounts from the multiple senders can be aggregated into an accumulated payment amount that gets transferred, by the PSS 110, to the recipient 502.”, [0115]).
Regarding claim 20:
Grassadonia teaches all limitations of claim 19:
Grassadonia further teaches:
wherein the remitter participates in the anonymous chatroom using a first temporary profile, and the remittee participates in the anonymous chatroom using a second temporary profile. Examiner interprets this claim to include that both remitter and remittee may use the chatroom. (“The communication messages can be, for example, text messages, user-to-user chat messages, or group chat(room) messages. In particular, the messaging application 404 monitors these communication messages to detect an indication of an intent to transfer money from a particular user (e.g., the sender 401) to a particular recipient (e.g., the recipient 402).”, [096]).
Claim Rejections – 35 USC 103
In the event the determination of the status of the application as subject to AIA 35 USC 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 USC 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 USC 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 pursuant to 35 USC 103 as being unpatentable over Grassadonia (US20160125371A1) in view of Chauhan (US20060287953A1).
Regarding claim 10:
Pilot discloses the limitations of claim 1:
Pilot does not expressly disclose, but Chauhan teaches:
wherein the displaying the result information of the remittance request comprises: based on determining that a receipt qualification of an account of the remittee is not verified, displaying a remittance failure notification. (“Of course, if the transaction is not flagged as suspicious, processing is continued until the transaction is completed by a Sending Agent 24, the system is updated, and the payer/User is notified accordingly. Notification may be in the form of an assumed successful completion, with actual notification occurring only on an exception basis where there is a failure or delay of the transaction for any reason, such as insufficient funds being available from the payor's designated source of funds, an unavailable or unresponsive beneficiary, or a regulatory issue with the requested transaction.”, [060]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application to have modified Grassadonia to incorporate the teachings of Chauhan because Grassadonia would be more prudent, efficient and versatile should it expressly notify user of a remittance failure thereby potentially weeding out suspect attempts at theft of funds, as done in Chauhan (“On failure, the system asks the candidate Master Controller to re-enter his credentials. Successive failures would indicate a suspect attempt, and would cause cancellation and reporting of the attempted access.”, [063])
CONCLUSION
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please see attached form 892
Mina (US20110119190A1) - Disclosed are methods, apparatus, systems, and non-transitory, tangible computer-readable media associated with use of transaction authorization codes to each of the parties involved in a buying and selling transaction. In various embodiments, the transaction authorization code(s) may be exchanged between parties, and once confirmed or validated, the transaction may be consummated. In one embodiment, the transaction authorization code may conceal personal and/or financial information about a party with whom the code is associated. In various embodiments, transaction authorization codes may be used on shared or separate devices. In various embodiments transaction authorization codes may be entered through web-based interfaces or using mobile devices.
Tota (US7308413B1) - In a process for creating media content, media submissions are requested and electronically received from end users and stored in a computer database. The submissions are searched for material to be included in the media content, and cross-checked against the other submissions for originality and timeliness. After the material is selected from one or more submissions, the content is developed and released to an audience for review. The end users whose submission material was included in the released content are rewarded. In one embodiment, third parties are permitted to access and search the submissions on an open exchange. The third parties can bid for rights in submissions on the open exchange. After receiving these bids, they are forwarded to the particular submission's end user for acceptance or rejection. Appropriate billing and payment processes are used to bill and pay the parties involved.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW COBB whose telephone number is (571) 272-3850. The examiner can normally be reached 9 - 5, M - F.
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 call examiner Cobb as above, or 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, Peter Nolan, can be reached at (571) 270-7016. 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.
/MATTHEW COBB/Examiner, Art Unit 3661
.
.
.
/PETER D NOLAN/Supervisory Patent Examiner, Art Unit 3661
Prosecution Insights