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 .
DETAILED ACTION
Claim Objections
Claim 28 is objected because “prevented from entering the routing information” is not supported in the specification. “providing routing number” is found in 0038 of the specification but the term prevented is not found and thus the examiner finds no support and will presume the limitation is directed to routing information.
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, 2, 5-10, 13, 15, 17-18,20, 25-30 are directed to an abstract idea without significantly more.
the claimed invention is directed to claims 1, 8 and 15 are directed to a method system and media for transferring “good funds” using a computer.
While system method and medium are considered statutory classes of invention, the claims are directed to the performance of a real estate transaction which is a fundamental economic practice. Under it’s broadest reasonable interpretation, fundamental economic practice falls within the “certain methods of organizing human activity” grouping of abstract ideas.
The abstract elements of claim 8 for example include;
a … of first financial institutions, each financial institution in the … of first financial institutions including a plurality of individual accounts; a … of second financial institutions, each second financial institution in the … of second financial institutions including a plurality of escrow accounts, each escrow account in the plurality of escrow accounts being opened to facilitate a home buying process; a secure payment financial institution comprising a secure payment account; a … associated with the secure payment account, the … configured to communicate with the …, the … thereon that, in response to execution by the …, cause the … to perform operations comprising: receiving, …, transaction information associated with a real estate transaction from a company, the transaction information including a user- associated escrow account in the plurality of escrow accounts, a user name associated with a user, and a user contact associated with the user, the escrow account configured to receive a good funds payment, and the user is a buyer; generating, by the …, a transaction identifier associated with the transaction information; sending, by the …, the transaction identifier to a secure payment database; transmitting, by the …, a selectable … to the … of [[a]]the user via electronic communication, wherein in response to the user selecting the selectable hyperlink via a secure payment user interface whereby the user accesses the user portal, the one or more processors verifies the user is an intended user; receiving, by the one or more processors, through the user portal, from the user device of the user, and after the user is verified, a good funds transfer request to transfer a good funds payment from a user account in the plurality of individual accounts to [[a]]the user-associated escrow account in the plurality of escrow accounts; associated with the user account; receiving, by …, through …, and from … of the user, a user financial institution in the network of first financial institutions associated with the user account of the user in response to querying the information associated with the user account; facilitating, by the one or more processors and through a financial institution user interface, a good funds transfer from the user account of the user to one of the secure payment account or the escrow account, the facilitating the good funds transfer comprising: generating, …, a request for payment (RFP), wherein the request for payment (RFP) is sent to the financial institution for the user account, wherein in response to the generating the request for payment (RFP), an approval request for payment of the good funds payment is automatically generated by the user financial institution and transmitted through the financial …, wherein the approval request is based on the request for payment (RFP) includes a first option to accept the request for payment (RFP) and a second option to reject the request for payment (RFP);in response to the first option of the approval request for payment (RFP) being selected through the financial institution user interface, irrevocably transferring, via a credit push from the user account, the good funds payment from the user account of the user to one of the secure payment account or the user-associated escrow account, wherein: the good funds payment is settled within one of the secure payment account or the user-associated escrow account within three minutes of the first option of the approval request for payment being selected, and funds from the good funds payment are available for use in response to the good funds payment being settled.
Here the technical elements of claim 8 include network (though it might not be a electronic network), a secure payment system comprising processors, a user portal, a tangible non-transitory memory configured to communicate… one or more processors, a user selectable hyperlink, to the user portal etc.
Here conducting a funds transaction by a computer over a network is a fundamental economic practice. Applicant claim 8 does include hyperlink and portal and interface. However, generally applicant is applying generic technical elements to the recited abstract limitations.
The judicial exception is not integrated into a practical application. In particular the additional elements amount to no more than mere instructions to apply the exception using a generic computing component.
On review of the amended claims, it appears that the end result is a secure funds transfer. There is no arguable technical improvement. However, potentially the interface output could be highlighted in a future amendment.
Claims 1, 15 are similar to claim 8.
The dependent claims 2, 5-7,9-10, 13-14, and 17-20, 24-26 do not add elements that would help to overcome or correct the rejection.
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.
Claims 1, 2, 5-10, 13,15, and 17,18,20, 25-30 are rejected under 35 U.S.C. 103 as being unpatentable over Lewis (US 2002/0029194) in view of Seto (US 2007/0061270) and US patent Publication 2020/0364760 to Sabat
Regarding claim(s) 8, 1, 15,
Lewis discloses; A system for transferring good funds, comprising :a network of first financial institutions, each financial institution in the network of first financial institutions including a plurality of individual accounts; (Lewis: pgh 23, “Participants in the transaction register with the system via an electronic network connection...and enter all transaction, participant, banking and financial information...”) a network of Of second financial institutions, each second financial institution in the network of second financial institutions including a plurality of escrow accounts, each escrow account in the plurality of escrow accounts being opened to facilitate a home buying process;
(Lewis: pgh 4, “The seller’s attorney sets up a unique escrow account with a bank and deposits the down payment check.”; pgh 13), a secure payment financial institution comprising a secure payment accounts; a secure payment system associated with the secure payment account, the secure payment system comprising one or more processors, a user portal, and a tangible, non-transitory memory configured to communicate with the one or more processors, (Lewis: pgh 20, “It is still a further object of the invention...to exchange information and finalize transactions securely over the Internet...”; pgh 58, “Cryptographic co-processor ensures that all payment information and data is encrypted, so that theft of payment information is deterred.; pgh 57, “Because accounts are opened and tracked electronically, the system...reduces the chances of fraud...”; pgh 60, “...computer...can be configured as discussed above and have an operating system...”) Lewis does not explicitly disclose what Seto teaches; the tangible, non-transitory memory having instructions stored thereon that, in response to execution by the one or more processors, cause the one or more processors to perform operations comprising:
Receiving by the one or more processors transaction information associated with a real estate transaction from a company, (clearing bank 0137)
the transaction information including a user associated escrow account in the plurality of escrow accounts, (0137, escrow accounts are known to be used for real-estate transactions)
a user name associated with a user and a user contact associated with a the user
the escrow account configured to receive a good funds payment,
Lewis(0094)
and the user is a buyer; generating by the one or more processors, a transaction identifier associated with the transaction information sending by the one or more processors the transaction identifier to a secure payment database,
(0092-0094 secure data)
transmitting, by the one or more processors, to the user portal to a user device of a user, via electronic communication
wherein in response to the user selecting the, the one or more processors verifies the user is an intended user; (Seto 0092, “a lawyer joining the system may have the option to link his lawyer profile information, they determine if the user is recognized and if not create a new account.. the system can determine an intended user by various means including using the provided back acount) receiving, by
via a secure user interface whereby the user access the user portal Lewis: 0068, “...the participants are first required to enter all of the transaction, banking and participant info )
the one or more processors, through the user portal, from the user device of the user, and after the user is verified, a good funds transfer request to transfer a good funds payment from a user account in the plurality of individual accounts to a user-associated escrow account in the plurality of escrow accounts;
(0091)
querying, by the one or more processors and through the user portal on the user device of the user, information associated with the user account ;
Seto(0100) receiving, by the one or more processors, through the user portal, and from the user device of the user, a user financial institution in the network of first financial institutions associated with the user account Seto(0044)
of the user in response to querying the information associated with the user account; facilitating, by the one or more processors and through a financial institution user interface, a good funds transfer from the user account of the user to one of the secure payment account or the escrow account, the facilitating the good funds transfer comprising:
Seto(0044) transferring, via a credit push from the user account, the good funds payment from the user account of the user to one of the secure payment account or the user-associated escrow account, wherein:the good funds payment is settled within one of the secure payment account or the user-associated escrow account within three minutes of the first option of the approval request for payment being selected approved by the user, and funds from the good funds payment are available for use in response to the good funds payment being settled. (for real time as in “3 minutes” see also Sabat 0009… “real time” Seto (0044 transferring and fig. 1 network of financial institutions)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Lewis to include the teachings of Seto for the motivation of “it is needed to provide a closing fund management system…. Manage a timed and irrevocable transfer of closing funds” Seto(0021)
Here Lewis and Seto do not explicitly disclose “RFP” as argued by the applicant, and selectable hyperlink (0091 this is taught by Sabat) and participant information into the system.
wherein the request for payment (RFP) is sent to the financial institution for the user account, wherein in response to the automatically generating the request for payment(RFP), an approval request for payment of the good funds payment is automatically generated by the user financial institution and transmitted through the financial institution user interface wherein the approval request is based on the request for payment (RFP) includes a first option to accept the request for payment (RFP) and a second option to reject the request for payment (RFP) (007 and 0056, RFP system for money transfers)
payment (RFP) includes a first option to accept the request for payment (RFP) and a second option to reject the request for payment (RFP) on the user device of the user; in response to the first option of the approval request for payment(RFP)of the good funds payment being selected approved by only the user and through the financial institution user interface on the user device of the user, irrevocably
(0007 and 0056, payments are generally irrevocable, 0116-8 for approved and rejected)
It would therefore have been obvious to one of ordinary skill in the art at the time of the invention to combine the payment systems of Lewis and the RFP teachings of Sabat for the motivation facilitating efficient remote shopping. (0003)
Regarding claim(s) 2:
he combination of Lewis/Seto, as shown in the rejection above, discloses the limitations of claim
Lewis further teaches:
wherein the good funds transfer request to transfer the good funds payment is initiated by the user. (Lewis: pgh 25, “The system also preferably arranges for the electronic transfer of funds in accordance with these payments...these payments are not made until approval for the transaction is given...”)
Regarding claim(s) 5:
The combination of Lewis/Seto, as shown in the rejection above, discloses the limitations of claim
1. Lewis further teaches: wherein the good funds transfer request to transfer the good funds payment and selection of the first option of approval the approval request for payment are both performed only by the user. (Lewis: pgh 27, “Upon approval of the transaction, each participant gives his approval accompanied by some verification...”)
Here in regards to request for payment RFP, see Sabat similar to the independent claim.
Regarding claim(s) 6:
The combination of Lewis/Seto, as shown in the rejection above, discloses the limitations of claim
1. Lewis further teaches:
wherein receiving the good funds transfer request to transfer the good funds payment is received through the secure payment user interface (Ul). (Lewis: pgh 28, “...the system presents a customized secure on-line transaction space, or electronic graphical user interface...”)
Regarding claim(s) 7:
The combination of Lewis/Seto, as shown in the rejection above, discloses the limitations of claim
6. Lewis further teaches:
wherein querying the information associated with the user account is performed through the secure payment Ul. (Lewis: pgh 28, “Once the system accesses all of the rules and requirements applicable to a particular transaction, which are identified by recognizing the given conditions and circumstances of the transaction, including the jurisdictions and participants...”)
Regarding claim(s) 9 and 18:
The combination of Lewis/Seto, as shown in the rejection above, discloses the limitations of claims
8 and 15, respectively. Lewis further teaches:
wherein in response to receiving the good funds payment in the secure payment account, the good funds payment is automatically transferred to one of the secure payment account or the user-associated escrow account. (Lewis: pgh 27, “...the transaction is finalized by the transfer of funds to the appropriate accounts...”)
Regarding claim(s) 10:
The combination of Lewis/Seto, as shown in the rejection above, discloses the limitations of claim
8. Lewis further teaches:
wherein: the user financial institution comprises a financial system including a graphical user interface (GUI), and approval of the approval request for payment is received from the user through the GUI of the financial system of the user financial institution. (Lewis: pgh 28, “...the system presents a customized secure on-line transaction space, or electronic graphical user interface...”)
Regarding claim(s) 13:
The combination of Lewis/Seto, as shown in the rejection above, discloses the limitations of claim
8 Lewis further teaches:
wherein
This is done preferably via a secure Web Site.”)
and the one or more processors is configured to generate the user portal user in response to the user name and the user contact being provided for a respective transaction. (Lewis: pgh 51,
“Preferably, the password allows access by the user into the secure electronic interface that has been specifically set up for that transaction...”)
Regarding claim(s) 17: The combination of Lewis/Seto, as shown in the rejection above, discloses the limitations of claim 16. Lewis further teaches:
wherein the operations further comprise generating, by the one or more processors, a user notification to the user that the good funds payment is due, the user notification including one of an email and a text message,
Regarding claim(s) 20:
The combination of Lewis/Seto, as shown in the rejection above, discloses the limitations of claim
15 Lewis further teaches:
wherein the user portal for facilitating the transfer of the good funds payment is generated automatically in response to the user name and the user contact in the transaction information being received by the one or more processors. (Lewis: pgh 28, “...the system presents a customized secure on-line transaction space, or electronic graphical user interface, that is specific for the particular transaction, access-limited to the participants of the transaction...”)
As per claim 25, Lewis discloses;
The method of claim 1, further comprising: receiving, by the secure payment system, through the user portal, and from the user device of the user, the information associated with the real estate transaction; and comparing, by the secure payment system, a portion of the information associated with the real estate transaction with a plurality of account in an account database.
(0028-30, “a portion” of the information… could be a small portion, and what is the outcome of the comparing or is it just a review)
As per claim 26 Lewis discloses; The method of claim 1, further comprising: receiving, by the secure payment system, a predetermined time from the company; storing, by the secure payment system, the predetermined time in a secure payment database; and the selectable hyperlink is transmitted to the user device of the user at the predetermined time.
(0035 of applicant spec- predetermined time is just a time that appears to be agreed, like a payment date, Lewis is time specific 0029, see 0131, “when notification is required….. some notification text is generated…. Containing a link to the website”)
As per claim 27 Lewis discloses; The method of claim 1, wherein the good funds transfer request is executable only when the transaction identifier associated with the real estate transaction matches a transaction identifier stored in the secure payment database. Lewis(secure on line transaction, 0020 and 0023)
As per claim 28 Lewis disclosed The method of claim 1, wherein the user is prevented from entering routing information used to transfer the good funds payment to the escrow account.
Lewis(0139 escrow accounts have to be filled, here it is noted that the term “prevented” is not found in the specification of applicant)
As per claim 29 Lewis discloses; The method of claim 1, wherein the verifying the user is the intended user of the real estate transaction comprises:(a) authenticating the user via the secure payment system upon portal access; and(b) approving the request for payment via the financial institution user interface prior to the irrevocable transfer.
Lewis(0031 authentication)
As per claim 30 Lewis and Seto do not explicitly disclose what Sabat teaches; The method of claim 1, wherein the selectable hyperlink is generated and transmitted automatically at a predetermined time relative to a transaction due date included in the transaction information and stored in the secure payment database.
Sabat (0091 hyperlink) The motivation for the combination is similar to that for claim 8.
Response to Arguments
Applicant filed an amendment on 2/6/26.
claims 1-2, 5-10, 13-15, 17-20, and 24-26 were rejected. Applicant presently amends claims 1, 6, 8, 13, 15, and 20. Claims 27-30 are new. Claims 19 and 24 are canceled Claims 3-4, 11-12, 16, and 21-23 were previously canceled. Claims 1-2, 5-10, 13-15, 17-18, 20, and 25-30 are thus pending. After careful consideration of the applicant arguments and amendments, the examiner finds them to be moot and/or non persuasive. This action is a final rejection.
35 U.S.C § 101
Applicant respectfully traverses. A. Step 2A, Prong One - The Claims Are Not Directed to an Abstract Idea
Respectfully, this characterization oversimplifies the claims and does not reflect what the claims are "directed to" as a whole.
(redacted version of the independent claim)
Here the abstract is based on analysis instructions to consider the idea and the technical elements separately. The idea is abstract if it essentially is more directed to a business transaction with a computer rather than an improvement the computer or technology itself.
Even if the claims are viewed as reciting a judicial exception, the claims are patent eligible because they integrate any alleged abstract idea into a practical application.
Currently practical application would not just apply because the claims are specific or limiting but, rather if the invention is directed to a practical improvement of the technology.
The amended claims apply transaction processing in a specific technical manner by using the secure portal as an access-control and verification mechanism that governs downstream system behavior.
Here downstream behavior is not claimed for example though if claimed might be persuasive.
As described in the specification, the secure payment system generates and manages transaction identifiers associated with transaction information and uses those identifiers to control processing and verification of transactions (see, e.g., Spec. [0034]). In particular:
associated with transaction information (Spec. [0029]-[0033]);
" portal access is programmatically restricted through a selectable hyperlink selected via a
secure payment user interface (Spec. [0030], [0032]);
" verification that the user is an intended participant in the transaction is triggered by portal
access itself, rather than being performed as a detached or manual authentication step (Spec.
1]-[0033]); and
" execution of the transaction is computationally bound to a system-generated transaction
identifier stored in a secure payment database, improving processing integrity and reducing
erroneous transaction execution (Spec. [0034]).
Here the argued elements are not explicitly claimed. However, claiming the argued elements would be helpful to the 35 USC 101 argument if incorporated in the claims.
This architecture improves the security, correctness, and integrity of computer-implemented transaction processing, rather than merely automating a financial transaction. The secure portal is therefore not an ancillary user interface, but a core structural component of the claimed secure payment system.
Thus, the claims impose meaningful limits on any alleged abstract idea and apply it in a concrete, real-world system. As such, the claims are integrated into a practical application and are patent eligible under Step 2A, Prong Two.
Here the elements from the specification could be incorporated more specifically.
C. Step 2B - The Claims Recite Significantly More Than Any Alleged Abstract Idea Independently, the claims recite an inventive concept sufficient to transform any alleged abstract idea into patent-eligible subject matter.
The claims include a non-conventional ordered combination of elements, including:
" a secure payment system that generates and persists a transaction identifier in a secure
database (Spec. [0034]);
" automatic generation of a transaction-specific secure portal (Spec. [0029]-[0033]);
" portal access through a selectable hyperlink selected via a secure payment user interface that
triggers intended-user verification (Spec. [0030]-[0032]); and
portal access and verification (Spec. [0033]-[0036]).
This arrangement is not well-understood, routine, or conventional. While individual components such as portals, hyperlinks, and payment requests may be known in isolation, the claimed architecture and interaction of these components-particularly the use of a transaction-specific secure portal as a gating and verification mechanism tied to a system-generated transaction identifier-reflects a non- generic technical solution.
Under controlling precedent, an inventive concept may arise from a non-conventional arrangement of known components. See BASCOM Global Internet Servs., Inc. v. AT&T Mobility LLC, 827 F.3d 1341 (Fed. Cir. 2016); Amdocs (Israel) Ltd. v. Openet Telecom, Inc., 841 F.3d 1288 (Fed. Cir. 2016).
Accordingly, the claims recite significantly more than any alleged abstract idea and are patent eligible under Step 2B.
For at least the reasons set forth above, Applicant respectfully submits that the pending claims are not directed to an abstract idea, are integrated into a practical application, and recite an inventive concept. Withdrawal of the §101 rejection is respectfully requested.
Here Bascom and Amdoc’s were directed to improving the technology itself. If the applicant can further transfer the technical elements of the specification to the claims, then this may be a persuasive argument.
Claim Rejections - 35 U.S.C 103
Claims 1, 2, 5-10, 13-15, 17-20, and 24-26 are rejected under 35 U.S.C. § 103 as being unpatentable over Lewis (US 2002/0029194) in view of Seto (US 2007/0061270) and further in view of Sabat (US 2020/0364760). Applicant respectfully disagrees with the rejections, but Applicant amends certain claims as set forth above in the interest of furthering prosecution. Claim 1:
Claim 1 is amended to recite, inter alia,"generating, by the secure payment system, a transaction identifier associated with the transaction information,""sending, by the secure payment system, the transaction identifier to a secure payment database," and "transmitting, by the secure payment system, a selectable hyperlink to the user portal to a user device of the user via electronic communication, wherein in response to the user selecting the selectable hyperlink via a secure payment user interface whereby the user accesses the user portal." As amended, the independent
and the proffered rationales do not support the particular combination and ordered interaction now claimed.
A. The amended claims require a system-generated transaction identifier stored to a secure payment database
Independent claims 1, 8, and 15 now each require generating, by the secure payment system, a transaction identifier associated with the transaction information, and sending the transaction identifier to a secure payment database.
The Office Action's prior mapping to Lewis suggests, at most, that Lewis has a "transaction" or "deal id number" (cited by the Office in connection with prior claim 24).
But the amended independent claims do not merely require that an identifier exists somewhere; they require that the secure payment system generates the transaction identifier in association with the company-provided transaction information and then persists that identifier to a secure payment database as part of the portal/verification workflow.
Here “company provided” might be from the bank of Lewis as per the updated rejection.
This anchored identifier/database step reflects how the claimed system binds a specific real estate transaction to a specific portal access and verification process.
Here anchor and binding are not claimed, thus these are not persuasive.
Neither Seto nor Sabat cures this deficiency. The Office Action does not identify any teaching in Seto or Sabat of the claimed secure-payment-system generation and database persistence of a transaction identifier as recited and in the claimed sequence.
B. The amended claims require a specific portal access + verification mechanism tied to a selectable hyperlink selected via a secure payment UI.
Here the amendment is countered by updated art thus applicant arguments may not be persuasive in view of updated grounds of rejection.
Independent claim 1 now expressly recites: transmitting a selectable hyperlink to the user portal to the user device, where in response to the user selecting the selectable hyperlink via a secure payment user interface whereby the user accesses the user portal, the secure payment system verifies the user is an intended user of the real estate transaction.
The corresponding system and storage-medium claims recite the same mechanism.
The Office Action previously relied on Seto for "link/intended user" functionality, but Seto's cited "link" passage pertains to linking profile information (i.e., account/profile association) rather
payment UI, provides portal access and triggers intended-user verification tied to the specific transaction.
While the Office also cited Sabat for "selectable hyperlink," the amended claims are not satisfied by merely having a hyperlink somewhere in a message.
The claims require a specific security-gated portal access flow where hyperlink selection via a secure payment UI both enables portal access and triggers intended-user verification for that transaction.
Here applicant argument may not be persuasive because specific security gated portal access flow for example is not claimed nor is the trigger … However, using those elements would certainly be persuasive if claimed as argued.
The Office Action offers general rationales (closing fund management; efficient remote shopping) for combining Lewis with Seto and Sabat.
Such broad statements do not explain why a skilled artisan would have been motivated to implement the specific ordered architecture now claimed-namely. (i) secure-payment-system generation and database persistence of a transaction identifier, (ii) automatic portal generation associated with company-provided transaction information, (iii) selectable-hyperlink portal access through a secure payment UI that triggers intended-user verification, and (iv) the particular RFP--FI auto-generated approval request--FIUI selection--irrevocable credit-push settlement workflow in the claimed sequence.
At minimum, the Office has not shown that the cited art teaches or suggests the combination as amended, and withdrawal of the §103 rejection is respectfully requested.
In regards to motivations to combine, examiner provided motivations for all combinations.
New claims 27-30 recite (redacted) These arguments are moot in view of updated grounds of rejection.
Conclusion
The following art from IP.com is relevant;
Research On E-Payment Model, IEEE 2010
Comparative study on various methods and types of mobile payment system, IEEE 2012
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRUCE I EBERSMAN whose telephone number is (571)270-3442. The examiner can normally be reached 8:00 am - 5:00 pm Monday-Friday.
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, Michael W Anderson can be reached at 571-270-0508. 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.
/BRUCE I EBERSMAN/Primary Examiner, Art Unit 3693