DETAILED ACTION
Acknowledgements
The amendment filed on 8/19/2025 is acknowledged.
Claims 1-9, 16-17, 19, and 21-30 are pending.
Claims 1-9, 16-17, 19, and 21-30 have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment/Arguments
Regarding the rejection of the claims under 35 USC 101, applicant states that the rejection overgeneralizes the claims and ignores the features of receiving one or more sensor readings and requesting payment information at a predetermined point within the drive-through. Applicant states that nowhere in the Office action does the Office specify how a human is supposed to receive one or more sensor readings. Due to this, applicant states that the claims do not fall within one of the abstract idea groupings. Applicant also states that this limitation is an additional limitation that falls outside the bounds of the alleged abstract idea. Applicant additionally states that the claims also integrate the judicial exception into a practical application because, similar to the claims in McRo and Thales Visionix, the claims are directed to a specific improvement in another technology or technical field, specifically drive through technologies and contain limitations similar to those in Thales Visionix that involved a particular configuration of sensor readings used to improve the technical field. Applicant further states that the claims recite three elements of a machine or manufacture, such as “a start of a drive-through, a speaker in the drive-through, and a window of the drive-through,” and therefore implement a judicial exception with a particular machine or manufacture.
Examiner notes, however, that the feature of receiving one or more sensor readings relative to a start of a drive-through, a speaker in the drive-through, and a window of the drive-through only involves receiving information regarding a drive-through. The claims do not provide any technical detail regarding any technical functionality that is caused to be carried out based on receiving the sensor readings. The claims also do not provide any technical details regarding communicating with the sensors. In fact, the claims do not necessarily require that the sensor readings be obtained from the sensors directly. They only involve receiving sensor readings, which are only data. A human could receive sensor readings by reading the data from a display or output device of the sensor or by communicating with another person who has read the sensor readings. Thus, this limitation is part of the abstract idea. The fact that the data represents a “sensor” reading also does not provide a practical application or significantly more than the abstract idea because even if it implies that the reading is a digital reading, it at most only involves using a computer as a tool to automate and/or implement the abstract idea. Further, the feature of “at a predetermined point within the drive-through, request payment information,” only involves requesting payment information, which is part of the commercial interaction, and is thus also part of the abstract idea. Therefore, these limitations are part of the abstract idea and do not provide a practical application or significantly more than the abstract idea. The fact that the sensor readings are relative to “a start of a drive-through, a speaker in the drive-through, and a window of the drive-through” does not require the use of a particular machine or manufacture, as this only describes what the data represents. It does not necessarily require the use of any of these devices.
Further, applicant states that the claims recite an inventive concept because the steps of receiving one or more sensor readings and requesting payment information at a predetermined point within the drive-through recite matter that cannot be considered well-understood, routine, or conventional, and the examiner has not provided evidence to show that the newly added limitations are well-understood, routine, and conventional.
Examiner first notes the features of receiving one or more sensor readings and requesting payment information at a predetermined point within the drive-through are part of the abstract idea, rather than additional elements beyond the abstract idea. Thus, they cannot provide an inventive concept. Further, regarding the elements that are identified in the rejection as additional elements beyond the abstract idea, examiner notes that the rejection does not rely on the additional elements being well-understood, routine, or conventional. Rather, the additional elements do not provide an inventive concept or provide significantly more than the abstract idea because the additional elements only involve using a computer as a tool to automate and/or implement the abstract idea.
Applicant’s remaining remarks have been considered, but are moot in view of the new grounds of rejection.
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-9, 16-17, 19, and 21-30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-9, 16-17, and 19 are directed to a system comprising a merchant server, merchant payment account server, merchant account, and a merchant device, and claims 21-30 are directed to a method. Therefore, these claims fall within the four statutory categories of invention.
The claims recite receiving an order, providing instructions to an agent to fulfill the order, receiving information regarding a drive-through, requesting payment, and receiving a ticket or receipt indicating that a user has rendered payment for the order, which is an abstract idea. Specifically, the claims recite “(a) a merchant . . . configured to communicate with a user . . . and to receive instructions sent from the user . . . ;” “(b) a merchant [bank] in communication with the merchant . . .;” “(c) a merchant account in communication with the merchant [bank];” and “(d) a merchant [checkout] in communication with the user . . . and configured to (i) receive at least some instructions sent by the user . . . to the merchant . . . and sent by the merchant . . . to the merchant [checkout], and (ii) communicate at least a portion of the at least some of the instructions sent by the user . . . to a merchant agent in order to fulfill a user request;” “wherein the merchant [bank] is configured to: receive one or more . . . readings relative to a start of a drive-through, a speaker in the drive-through, and a window of the drive-through,” “at a predetermined point within the drive-through, request payment information,” and “receive a token from the user . . . that indicates payment for the user request was made to the merchant account, wherein the token does not include an account number of a user,” which is grouped within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (MPEP 2106.04 & 2106.04(a)) because it describes a process in which a merchant receives an order from a customer, instructs an agent to fulfill the order, obtains information about various positions in a drive-through, requests payment information, and the merchant’s bank receives a ticket or receipt from the customer indicating that they rendered payment to the merchant’s account, which is a commercial interaction. Accordingly, the claims recite an abstract idea (See MPEP 2106.04(a)).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106.04(d)), the additional elements of the claims such as a merchant server configured to communicate with a user device, a merchant payment server in communication with the merchant server, a merchant device in communication with the merchant device, and sensor readings, merely use a computer as a tool to perform an abstract idea. Specifically, these additional elements perform the steps or functions of “(a) a merchant . . . configured to communicate with a user . . . and to receive instructions sent from the user . . . ;” “(b) a merchant [bank] in communication with the merchant . . .;” “(c) a merchant account in communication with the merchant [bank];” and “(d) a merchant [checkout] in communication with the user . . . and configured to (i) receive at least some instructions sent by the user . . . to the merchant . . . and sent by the merchant . . . to the merchant [checkout], and (ii) communicate at least a portion of the at least some of the instructions sent by the user . . . to a merchant agent in order to fulfill a user request;” “wherein the merchant [bank] is configured to: receive one or more . . . readings relative to a start of a drive-through, a speaker in the drive-through, and a window of the drive-through,” “at a predetermined point within the drive-through, request payment information,” and “receive a token from the user . . . that indicates payment for the user request was made to the merchant account, wherein the token does not include an account number of a user.” Viewed as a whole, the use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106.05), the additional elements of using a merchant server configured to communicate with a user device, a merchant payment server in communication with the merchant server, a merchant device in communication with the merchant device, and sensor readings to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of receiving an order, providing instructions to an agent to fulfill the order, receiving information regarding a drive-through, requesting payment, and receiving a ticket or receipt indicating that a user has rendered payment for the order. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions of “(a) a merchant . . . configured to communicate with a user . . . and to receive instructions sent from the user . . . ;” “(b) a merchant [bank] in communication with the merchant . . .;” “(c) a merchant account in communication with the merchant [bank];” and “(d) a merchant [checkout] in communication with the user . . . and configured to (i) receive at least some instructions sent by the user . . . to the merchant . . . and sent by the merchant . . . to the merchant [checkout], and (ii) communicate at least a portion of the at least some of the instructions sent by the user . . . to a merchant agent in order to fulfill a user request;” “wherein the merchant [bank] is configured to: receive one or more . . . readings relative to a start of a drive-through, a speaker in the drive-through, and a window of the drive-through,” “at a predetermined point within the drive-through, request payment information,” and “receive a token from the user . . . that indicates payment for the user request was made to the merchant account, wherein the token does not include an account number of a user.” These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of receiving an order, providing instructions to an agent to fulfill the order, receiving information regarding a drive-through, requesting payment, and receiving a ticket or receipt indicating that a user has rendered payment for the order. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05 (f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 2-9, 16-17, 19, and 22-30 further describe the abstract idea of receiving an order, providing instructions to an agent to fulfill the order, receiving information regarding a drive-through, requesting payment, and receiving a ticket or receipt indicating that a user has rendered payment for the order. Specifically, claims 2-5 and 22-25 further describe the aspect of the abstract idea that involves placing the order and making payment, because these claims describe the use of a user device to receive information necessary to transfer funds to the merchant account, and to pay for the order by receiving a cost for a user request and communicating it to the financial institution of the user to instruct it to transfer payment to the merchant. The use of a user device having a first user device processor, a server of a financial institution of the user, and a server of the merchant’s financial institution to perform these functions does not provide a practical application or significantly more than the abstract idea because they only involve using a computer to automate and/or implement the abstract idea. Claims 6 and 26 describe characteristics of the merchant server and merchant payment server, but do not require any steps or functions to be performed. Claims 7 and 27 describe characteristics of the instructions, but do not require any steps or functions to be performed. Claims 8-9 and 28-29 further describe the abstract idea because they describe a process of estimating the completion time of the customer’s order and communicating it to the user. The use of a GPS of the user device and the merchant server to perform these functions does not provide a practical application or significantly more than the abstract idea, because it only involves using a computer as a tool to automate and/or implement the abstract idea. Claim 16 describes using a wireless or wired connection to transmit data. This only describes the manner in which the computer transmits data, and does not serve to provide a practical application or significantly more than the abstract idea. Claims 17 and 30 describe authenticating the merchant payment server before processing a payment, which further describes the abstract idea because it describes the processing of the payment. Claim 19 describes the thickness of the user device. This feature only describes a characteristic of the device, but does not require any steps or functions to be performed. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
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 (i.e., changing from AIA to pre-AIA ) 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.
Claims 1-4, 21-24, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Kravitz (US 6,029,150) in view of L’Heureux, et al. (US 2014/0257877) (“L’Heureux”) and Theobald (US 2015/0379650).
Regarding claims 1 and 21, Kravitz discloses a method and computer system for facilitating financial transactions and reducing the possibility for fraud, wherein the method and computer system comprises:
(a) a merchant server configured to communicate with a user device and to receive instructions sent from the user device (Kravitz Figure 1, Merchant Network Server 110 in communication with Customer Network Software 104; 11:64-12:2; 17:64-67; 24:33-38; 25:32-39);
(b) a merchant payment server in communication with the merchant server (Kravitz Figure 1, Merchant Clearing Corporation 114 in communication with Merchant Network Server 110; 12:3-14, 22-28);
(c) a merchant account in communication with the merchant payment server (Kravitz 12:6-10);
and
(d) a merchant configured to (i) receive at least some of the instructions sent by the user device to the merchant server, and (ii) communicate at least a portion of the at least some of the instructions sent by the user device in order to fulfill a user request (Kravitz 12:45-54; 17:64-67; 24:33-38; 25:32-39; 35:54-59);
wherein the merchant payment server is configured to:
receive a token from the user device that indicates payment for the user request was made to the merchant account, wherein the token does not include an account number of the user (Kravitz 7:26-29, 39-43; 13:2-19, 26-36; 15:14-28; 32:59-64; 34:51-35:40).
Kravitz does not specifically disclose that the merchant comprises a merchant device in communication with the user device, or that the merchant device receives the instructions sent by the user device and sent by the merchant server to the merchant device. Kravitz also does not specifically disclose communicating the instructions to fulfill the user request to a merchant agent. Kravitz further does not specifically disclose the merchant payment server receiving one or more sensor readings relative to a start of a drive-through, a speaker in the drive-through, and a window of the drive-through, and at a predetermined point within the drive-through, requesting payment information.
L’Heureux discloses that the merchant comprises a merchant device in communication with the user device, and that the merchant device receives the instructions sent by the user device and sent by the merchant server to the merchant device (L’Heureux ¶¶ 13-15, 19, 27-28, 34-36). L’Heureux also discloses communicating the instructions to fulfill the user request to a merchant agent (L’Heureux ¶¶ 13, 19, 35, 60).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Kravitz to include a merchant comprising a merchant device in communication with the merchant device, the merchant device receiving the instructions sent by the user device and sent by the merchant server to the merchant device, and communicating the instructions to fulfill the user request to a merchant agent, as disclosed in L’Heureux, in order to speed up the ordering and fulfillment of a purchase by allowing users to place orders which are then processed based on their proximity to a merchant (L’Heureux ¶¶ 1-2).
Kravitz in view of L’Heureux does not specifically disclose the merchant payment server receiving one or more sensor readings relative to a start of a drive-through, a speaker in the drive-through, and a window of the drive-through, and at a predetermined point within the drive-through, requesting payment information.
Theobald discloses the merchant payment server receiving one or more sensor readings relative to a start of a drive-through, a speaker in the drive-through, and a window of the drive-through, and at a predetermined point within the drive-through, requesting payment information (Theobald ¶¶ 10-16, 19, 26, 31, 33-35, 41-42, 45-46, 50, 52-53, 82).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Kravitz in view of L’Heureux to include a merchant payment server receiving one or more sensor readings relative to a start of a drive-through, a speaker in the drive-through, and a window of the drive-through, and at a predetermined point within the drive-through, requesting payment information, as disclosed in Theobald, in order to allow user preferences or history to be used to provide an improved experience for a customer at a drive through (Theobald ¶ 2).
Regarding claims 2 and 22, Kravitz discloses the computer system of claim 1 that further includes the first user device, wherein the first user device has a first user device processor in communication with one or both of the merchant server and the merchant payment server, and the user device processor is configured to receive a cost for the user request and transmit the cost to a server of a financial institution of the user (Kravitz 11:56-60; 12:49-13:14; 13:57-64; 14:48-66; 15:29-45: 24:33-65; 25:32-49; 27:25-30).
Regarding claims 3 and 23, Kravitz discloses that the merchant payment server communicates to the first user device processor information sufficient to transfer funds to the merchant account (Kravitz 11:51-60; 12:3-28; 12:51-64; 14:48-66; 18:10-26; 24:35-65; 25:36-60).
Regarding claims 4 and 24, Kravitz discloses the user device processor commands the server of the financial institution of the user to transfer the payment to a merchant (Kravitz 12:56-13:14; 15:29-45; 25:32-49; 27:25-30; 31:45-55).
Regarding claim 16, Kravitz discloses the computer system of claim 1 that is configured to transmit or receive data using a wireless connection, a wired connection, or both (Kravitz 11:51-60; 12:45-49; 13:57-64; 17:64-67).
Claims 5 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Kravitz in view of L’Heureux as applied to claims 4 and 24 above, and further in view of Keogh, et al. (US 2003/0212632) (“Keogh”).
Regarding claims 5 and 25, Kravitz in view of L’Heureux does not specifically disclose that a server of a financial institution of the merchant transmits a communication to either the merchant server or the merchant payment server that the payment has been received.
Keogh discloses that a server of a financial institution of the merchant transmits a communication to either the merchant server or the merchant payment server that the payment has been received (Keogh ¶¶ 49, 56, 58).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Kravitz in view of L’Heureux to include a server of the financial institution of the merchant transmitting a communication to either the merchant server or the merchant payment server that the payment has been received, as disclosed in Keogh, in order to allow for processing payments online while ensuring that the identities of the trading parties are verified and providing certainty of payment for the seller (Keogh ¶¶ 9-10).
Claims 6 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Kravitz in view of L’Heureux as applied to claims 1 and 21 above, and further in view of Castell, et al. (US 2009/0233579) (“Castell”).
Regarding claims 6 and 26, Kravitz in view of L’Heureux does not specifically disclose that the merchant server and the merchant payment server are the same device.
Castell discloses that the merchant server and the merchant payment server are the same device (Castell ¶¶ 30, 44).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Kravitz in view of L’Heureux to include the merchant server and the merchant payment server being the same device, as disclosed in Castell, in order to allow for improved wireless mobile payments at online merchants (Castell ¶¶ 3, 11).
Claims 7-9 and 27-29 are rejected under 35 U.S.C. 103 as being unpatentable over Kravitz in view of L’Heureux as applied to claims 1, 2, 21, and 22 above, and further in view of Havas (US 2013/0317921).
Regarding claims 7 and 27, Kravitz in view of L’Heureux does not specifically disclose that the instructions sent from the user device include a requested completion time.
Havas discloses that the instructions sent from the user device include a requested completion time (Havas ¶ 87).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Kravitz in view of L’Heureux to include instructions sent from the user device including a requested completion time, as disclosed in Havas, in order to reduce wait times for customers when picking up their order (Havas ¶¶ 3, 15, 62).
Regarding claims 8 and 28, Kravitz in view of L’Heureux does not specifically disclose that the user device has a global positioning system (GPS) configured to communicate with the merchant server and the merchant server calculates a requested completion time for the user request based in part on a location of the user device.
Havas discloses that the user device has a global positioning system (GPS) configured to communicate with the merchant server and the merchant server calculates a requested completion time for the user request based in part on a location of the user device (Havas ¶¶ 67, 84, 86, 89).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Kravitz in view of L’Heureux to include a user device having a global positioning system (GPS) configured to communicate with the merchant server and the merchant server calculating a requested completion time for the user request based in part on a location of the user device, as disclosed in Havas, in order to reduce wait times for customers when picking up their order (Havas ¶¶ 3, 15, 62).
Regarding claims 9 and 29, Kravitz in view of L’Heureux does not specifically disclose that the merchant server communicates the estimated completion time to the first user device.
Havas discloses that the merchant server communicates the estimated completion time to the first user device (Havas ¶ 90).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Kravitz in view of L’Heureux to include the merchant server communicating the estimated completion time to the first user device, as disclosed in Havas, in order to reduce wait times for customers when picking up their order (Havas ¶¶ 3, 15, 62).
Claims 17 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Kravitz in view of L’Heureux as applied to claims 1 and 21 above, and further in view of Choi, et al. (US 2009/0081992) (“Choi”).
Regarding claims 17 and 30, Kravitz in view of L’Heureux does not specifically disclose that the merchant payment server is configured to be authenticated before processing a payment.
Choi discloses that the merchant payment server is configured to be authenticated before processing a payment (Choi ¶¶ 43-47).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Kravitz in view of L’Heureux to include the merchant payment server being configured to be authenticated before processing a payment, as disclosed in Choi, in order to increase the security and trust between the parties in the transaction (Choi ¶¶ 8-12, 45).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Kravitz in view of L’Heureux as applied to claim 2 above, and further in view of Pentz, et al. (US 6,471,127) (“Pentz”).
Regarding claim 19, Kravitz in view of L’Heureux does not specifically disclose that the user device has a thickness of ¼” or less.
Pentz discloses that the user device has a thickness of ¼" or less (Pentz 4:51-5:30; 7:47-63; 8:2-8).
Therefore, it would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify the method of Kravitz in view of L’Heureux to include the use of a user device with a thickness of ¼” or less, as disclosed in Pentz, in order to make the device easier to carry (Pentz 1:38-61; 2:4-20).
Conclusion
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 Mohammad A. Nilforoush whose telephone number is (571)270-5298. The examiner can normally be reached Monday-Friday 12pm-7pm.
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, John W. Hayes can be reached at 571-272-6708. 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.
/Mohammad A. Nilforoush/Primary Examiner, Art Unit 3697