DETAILED ACTION
Notice of 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 .
Status of the Application
Claims 1-2 and 4-6 were pending and were rejected in the previous office action. Claims 1, 5, and 6 were amended. Claims 1-2 and 4-6 remain pending and are examined in this office action.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/15/2026 and the RCE filed 1/27/2026 has been entered.
Response to Arguments
35 USC § 103:
Applicant’s arguments regarding the previous § 103 rejections of claims 1-2 and 4-6 (pgs. 6-10, remarks filed 1/15/2026) have been considered but are moot as they do not apply to the current grounds of rejection applied in the § 103 rejections of claims 1-2 and 4-6 below, in response to applicant’s amendments. Please see the current § 103 rejection(s) of claims 1-2 and 4-6 below.
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 and 4-6 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without significantly more.
Step 1:
Claims 1-4 recite “A control device…” (i.e. a machine); claim 5 recites “A control method…” (i.e. a process); and claim 6 recites “A non-transitory computer-readable storage medium having a control program stored therein…” (i.e. an article of manufacture). These claims fall under one of the four categories of statutory subject matter and as a result, pass Step 1 of the subject matter eligibility test. However, “Determining that a claim falls within one of the four enumerated categories of patentable subject matter recited in 35 U.S.C. 101 (i.e., process, machine, manufacture, or composition of matter) in Step 1 does not end the eligibility analysis, because claims directed to nothing more than abstract ideas (such as a mathematical formula or equation), natural phenomena, and laws of nature are not eligible for patent protection.” See MPEP 2106.04. Accordingly, the examiner continues the subject matter eligibility analysis below.
Step 2A Prong One:
Independent claims 1, 5, and 6 recite limitations for:
determining an arrival time at which a vehicle will arrive at a destination requested by a user,
determining a period of delivery time for a drone to delivery, to the vehicle, a product ordered by the user who is traveling in the vehicle,
determining, on a basis of (i) the arrival time when a vehicle will arrive at a destination desired by a user and (ii) the period of delivery time it takes for a drone to deliver, to the vehicle, a product ordered by the user who is traveling in the vehicle, whether or not it is possible for the drone to deliver the product to the vehicle before the vehicle arrives at the destination,
wherein in a state in which it is determined that the drone can delivery the product ordered by the user before the vehicle arrives at the destination…instructing the drone to travel to the vehicle, and
in a state in which it is determined that the drone cannot deliver the product ordered by the user before the vehicle arrives at the destination, based on an analysis of a plurality of different flight routes for the drone…notifying the user that it is impossible to deliver the product before the vehicle arrives at the destination, and,
upon receipt of the notification, the user designates an updated reception place and an updated reception time, such that, after a further determination is made as to the viability of the updated reception place and the updated reception time…instructing the drone to travel to the updated reception place at the updated reception time to deliver the product ordered by the user
These limitations of independent claims 1, 5, and 6 above are determined to recite an abstract idea (i.e. determine whether or not a delivery can be made by a drone, and either instruct the delivery to be made as specific, or update the delivery location and time and instruct the delivery to be made to the updated delivery location and time) for the reasons discussed in the following continued Step 2A Prong One analysis.
As per MPEP 2106.04(a)(2)(II), claim limitations which recite commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations) or managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) fall into the “certain methods of organizing human activity” category of judicial exceptions. Therefore, since the processes described by the limitations above amount to a commercial interaction (i.e. determine whether or not a delivery can be made by a drone, and either instruct the delivery to be made as specific, or update the delivery location and time and instruct the delivery to be made to the updated delivery location and time), the claims fall into the “certain methods of organizing human activity” grouping of abstract ideas.
The limitations for above, under the broadest reasonable interpretation and but for the use of generic computer components in the claims, also cover concepts that can reasonably be performed in the human mind (e.g. observation, evaluation, judgment, and opinion) or by the human mind with the aid of simple tools such as pen and paper. As described in MPEP 2106.04(a)(2)(III), “[T]he "mental processes" abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes include observations, evaluations, judgments, and opinions” and “If a claim recites a limitation that can practically be performed in the human mind, with or without the use of a physical aid such as pen and paper, the limitation falls within the mental processes grouping, and the claim recites an abstract idea.” For example, the three “determining,” steps above describe evaluations, judgements, or opinions. Additionally, the “instructing,” “notifying,” and “instructing” could otherwise be performed by humans via basic communications or by written instruction/notification. Therefore, the claims fall under the “mental processes” category of judicial exceptions (i.e. abstract ideas).
While claims 1, 5, and 6 are identified by the examiner as reciting concepts that fall under more than one abstract idea grouping (i.e. “certain methods of organizing human activity” and “mental processes”), the limitations are treated as a single abstract idea for the Step 2A Prong Two and Step 2B analysis in accordance with MPEP 2106.04(II)(B).
Step 2A Prong Two:
The judicial exception (i.e. abstract idea) recited in claims 1, 5, and 6 is not integrated into a practical application because the claims recite mere instructions to apply the abstract idea (i.e. determine whether or not a delivery can be made by a drone, and either instruct the delivery to be made as specific, or update the delivery location and time and instruct the delivery to be made to the updated delivery location and time) using generic computers/computer components (i.e. “A control device comprising: a controller, including at least a processor and a memory, and provided in a vehicle, the controller configured to…” of claim 1; “for use in a control device that includes a controller” of claim 5; and “A non-transitory computer-readable storage medium having a control program stored therein, the control program causing a computer to execute a process” of claim 6). See MPEP 2106.05(f), showing “[C]laims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp.” That the delivery in the claims pertains to a drone, and the delivery is made to a vehicle, at best only generally link the performance of the abstract idea to a particular field of use (e.g. drone-based delivery to vehicles). Furthermore, under the broadest reasonable interpretation, the steps where for instructing the drone to travel of claims 1, 5, and 6 only requires, at most, sending or transmitting data to the drone, but does not positively recite and require controlling a drone itself. Telling a drone to carry out a delivery is different from a direct computer control of the drone. Instead, sending or transmitting information using computers falls under generic computer functions capable of being performed by computers operating in their ordinary capacity (e.g. receiving or transmitting data), in order to apply the abstract idea. These limitations do not recite an inventive concept or other meaningful limitations that integrate the abstract idea into a practical application.
Therefore, because the claims, considered as a whole, do not recite anything that integrates the abstract idea into a practical application, the claims are directed to an abstract idea.
Step 2B:
Claims 1, 5, and 6 do not include additional elements that are sufficient to amount to significantly more than the judicial exception (i.e. abstract idea) because as mentioned above, the claims recite mere instructions to apply the abstract idea (i.e. determine whether or not a delivery can be made by a drone, and either instruct the delivery to be made as specific, or update the delivery location and time and instruct the delivery to be made to the updated delivery location and time) using generic computers/computer components (i.e. “A control device comprising: a controller, including at least a processor and a memory, and provided in a vehicle, the controller configured to…” of claim 1; “for use in a control device that includes a controller” of claim 5; and “A non-transitory computer-readable storage medium having a control program stored therein, the control program causing a computer to execute a process” of claim 6). As above, the delivery pertaining to drone delivery, and the delivery being made to a vehicle, at best only generally link the performance of the abstract idea to a particular field of use or technological environment (e.g. drone-based delivery to vehicles). Further, under the broadest reasonable interpretation, the steps where for instructing the drone to travel of claims 1, 5, and 6 only requires, at most, sending or transmitting data to the drone. Sending or transmitting information using computers falls under generic computer functions capable of being performed by computers operating in their ordinary capacity (e.g. receiving or transmitting data), in order to apply the abstract idea. Therefore, these limitations do not recite any inventive concept or other meaningful limitations that add significantly more than the abstract idea. Considering the additional elements as an ordered combination does not alter the analysis above.
Dependent claims 2 and 4:
Dependent claims 2 and 4 are directed to the same abstract idea as independent claim 1 above as they do not recite anything that integrates the abstract idea into a practical application or amounts to significantly more than the abstract idea.
Dependent claims 2 and 4 further recite the following limitations: “wherein: in a state in which it is determined that it is possible for the drone to deliver the product to the vehicle before the vehicle arrives at the destination, the controller is configured to further determine, on a basis of at least one of a traveling state of the vehicle and a traveling environment of the vehicle, whether or not it is possible to receive the product from the drone” (claim 2), “wherein: in a state in which it is determined that it is possible for the drone to deliver the product to the vehicle before the vehicle arrives at the destination, the controller is further configured to calculate, in accordance with a request of the user, a timing to receive the product from the drone” (claim 4). These limitations in claims 2 and 4 further describe the abstract idea above, apply the additional steps using generic computer components (i.e. “the controller”), and do not recite any new additional elements beyond those already addressed above.
Therefore, claims 1-2 and 4-6 are ineligible under § 101.
Note: While the examiner acknowledges that the § 101 rejection was previously withdrawn based upon instructing the drone to perform delivery, upon further discussion with a supervisory patent examiner and quality assurance specialist, it was brought to the examiner’s attention that the broadest reasonable interpretation of “the controller instructs the drone” does not require direct control of the drone, but instead can include simply sending a message to a drone (without any direct control). If the limitation is interpreted as simply sending a message (data) to a drone, it does not describe anything more than generic computer functions to apply the abstract idea. In order to overcome the added § 101 rejection above, the claims should include direct drone control operations that go beyond merely transmitting a message to the drone, and further require positively recited steps describing direct control of the drone by another device or a device in the drone itself (in response to receiving the instruction).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2 and 4-6 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190043370 A1 to Mulhall et al. (Mulhall) in view of US 20160253908 A1 to Chambers et al. (Chambers), and further in view of US 20200265383 A1 to Zhang.
Claim 1: Mulhall teaches:
A control device (Mulhall: Fig. 1 and ¶ 0032-0033 showing client computing device 104, also see ¶ 0098-0099 showing as a computer hardware implementation wherein “the computer architecture 800 illustrated in FIG. 8 illustrates an architecture for a server computer, or network of server computers, or any other types of computing devices suitable for implementing the functionality described herein. The computer architecture 800 may be utilized to execute any aspects of the software components presented herein”) comprising:
a controller, including at least a processor and a memory (Mulhall: ¶ 0041 showing computing device 104 may include a mobile device or smart phone; ¶ 0099 showing computer hardware implementation including a CPU 802 and memory 804), and provided in a vehicle (Mulhall: ¶ 0041 showing mobile computing device/smart phone within the interior of the receiving vehicle and running the product acquisition application)
the controller configured to: determine an arrival time at which the vehicle will arrive at a destination requested by a user (Mulhall: ¶ 0068 showing “preliminary order data 156(P) is generated via the client computing device 104…the preliminary order data 156(P) may also indicate a latest arrival time that the user can arrive at the destination-location 112. For example, the user may have a meeting scheduled at 11:45 AM at the destination-location 112 such that the preliminary order data 156(P) indicates a latest arrival time of 11:45 AM”; also see ¶ 0009, ¶ 0070, ¶ 0072),
determine a period of delivery time for a drone to deliver, to the vehicle, a product ordered by the user who is traveling in the vehicle (Mulhall: ¶ 0078 “travel-schedule that defines time-based expectations of when the receiving vehicle will reach various points along the first route”; ¶ 0061 showing determined time that vehicle is within rendezvous area for receiving the delivery and ¶ 0064 showing “At time T3, the receiving vehicle 106 and the UAV 108 reach the rendezvous area 114 at substantially the same time when the UAV 108 searches for and ultimately identifies the receiving vehicle. It can be appreciated that designing and timing the flightpath so that the vehicles reach the rendezvous area at substantially the same time conserves energy resources for at least the reasons that the UAV 108 does not have to waste energy by hovering and waiting for the receiving vehicle 106, nor does the UAV have to waste energy by chasing down the receiving vehicle 106 if it has already reached and passed the third-location P3, UAV”),
determine, on a basis of (i) the arrival time when the vehicle will arrive at the destination (Mulhall: ¶ 0006, ¶ 0038, ¶ 0068, ¶ 0070, ¶ 0072 showing use of expected arrival time that a receiving vehicle is expected to arrive at its desired destination, for use in determining when and where UAV may be able to rendezvous to deliver the product; also generally see ¶ 0062 showing estimating time the receiving vehicle arrives at rendezvous location prior to arrival at the final destination) and (ii) the period of delivery time for the drone to deliver, to the vehicle, the product ordered by the user who is traveling in the vehicle (Mulhall: ¶ 0062 showing considering travel time of the UAV for the UAV to go from an originating location, to the rendezvous location for meeting with the vehicle; “the navigation engine 116 may determine that the third-location P.sub.3, UAV is the closest location with which the UAV 108 may rendezvous with the receiving vehicle along the predetermined route while still avoiding one or more volumes of restricted airspace. The navigation engine 116 may further determine an amount of time that the UAV 108 will take to travel from the first fulfillment center 404(1) to the third location”; also see ¶ 0080 showing “flight plan data which indicates when the UAV will be at various points along the flight path”; also see ¶ 0061, ¶ 0064 as per above), whether or not it is possible for the drone to deliver the product to the vehicle before the vehicle arrives at the destination (Mulhall: ¶ 0062 showing determining to dispatch the UAV at the correct time such that it would reach the rendezvous location for delivery at the same time as the en route receiving vehicle; also see ¶ 0080-0083, and ¶ 0070, ¶ 0072, Fig. 5 showing determining whether the en-route rendezvous delivery can be made from the UAV to the vehicle while still allowing the vehicle to arrive at its destination by a predetermined arrival time, considering the factors above, and providing various possible options for rendezvous and delivery from the UAV to the receiving vehicle prior to arrival at the destination),
wherein in a state in which it is determined that the drone can deliver the product ordered by the user before the vehicle arrives at the destination (Mulhall: ¶ 0083, ¶ 0061-0064, Fig. 4 showing determining drone and receiving vehicle can rendezvous for delivery prior to arrival at the destination; also see ¶ 0006 “determine when and where the UAV may be able to efficiently rendezvous with the receiving vehicle to deliver the product”; also see ¶ 0007, ¶ 0036 showing determine when and where to rendezvous between the UAV and the receiving vehicle), the controller is further configured to instruct the drone to travel to the vehicle (Mulhall: ¶ 0007-0009 showing order requesting UAV delivery of the product, which causes flight path and flight schedule designed to control the drone to travel to the vehicle, e.g. when and where the UAV will rendezvous), and
With respect to the limitation(s):
in a state in which it is determined that the drone cannot deliver the product ordered by the user before the vehicle arrives at the destination, based on an analysis of a plurality of different flight routes for the drone, the controller is further configured to notify the user that it is impossible to deliver the product before the vehicle arrives at the destination,
Mulhall teaches delivery of a product ordered by the user wherein the product is delivered to the vehicle of the user while it is in transit to, i.e. prior to, its final destination (Mulhall: ¶ 0083, ¶ 0061-0064, ¶ 0006-0007, ¶ 0036), but does not explicitly discuss a situation in which the product is unable to be delivered as originally entered or requested based on analysis of different flight routes.
However, Chambers teaches determining, in a drone package delivery system, based at least in part on analysis of data including a plurality of flight corridors and paths (Chambers: ¶ 0056; ¶ 0049-0058 generally) that a user requested refinement to a delivery route cannot be performed, i.e. impossible to deliver the product, and sending a notification to the user of this determination (Chambers: ¶ 0119-0122 showing based on service request, service request handler may also play an active part in determining the route a UAV 102 takes on a mission to complete a service request; where as per ¶ 0124-0127 a requesting user is presented with a user interface for route refinement and the system received user input of route refinement, which is then validated in a validation process; showing ¶ 0128 “If the route refinement selection is not valid…the system interface manager 406 will send information to the client device that will cause a “selection invalid” indicator to be presented 456 on the client device, so the service requestor 104 realizes that the route refinement selection previously made cannot be used”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the determination that a route to a current delivery selection is infeasible based on current user input of Chambers in the UAV delivery system of Mulhall with a reasonable expectation of success of arriving at the claimed invention, with the motivation to “to confirm that the route refinement selection will not cause the UAV 102 to crash or cause the mission to otherwise fail. Validation is done to ensure that the service requestor 104 has not introduced human error into the routing process. For example, a service requestor 104 could specify a delivery location that is in a body of water, or a trajectory that intersects a building” (Chambers: ¶ 0126).
With respect to the limitation(s):
and, upon receipt of the notification, the user designates an updated reception place and an updated reception time, such that, after a further determination is made as to the viability of the updated reception place and the updated reception time, the controller then instructs the drone to travel to the updated reception place at the updated reception time to deliver the product ordered by the user
Mulhall teaches that a drone transports the delivery order to a user’s dynamic location, e.g. a user moving in a vehicle (Mulhall: ¶ 0004; and ¶ 0083, ¶ 0061-0064, ¶ 0006-0007, ¶ 0036), and teaches instructing the drone to travel to a reception place (or an updated reception place based on changes to delivery) (Mulhall: ¶ 0080-0083, ¶ 0004, ¶ 0009), but does not explicitly teach that upon receipt of a notification indicating an originally scheduled delivery cannot be made, the user provides an updated delivery location and an updated delivery time for instructing delivery of the order to the user.
However, Chambers teaches upon receipt of the notification (Chambers: ¶ 0128 as per above), the user designated an updated reception place, and a route for the drone is validated against the updated reception place (Chambers: ¶ 0128-0129 showing client device used to input new route refinement selection) before then instructing the drone to perform the delivery to the delivery destination (Chambers: ¶ 0129; see ¶ 0040-0041 showing mission data generated and transmitting to the UAV, and the UAV is launched to perform the delivery). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the validate of a new input route refinement from the requesting user to generate UAV delivery instructions of Chambers in the UAV delivery system of Mulhall/Chambers with a reasonable expectation of success of arriving at the claimed invention, for the same reasons described in the limitation above.
Still, while Chambers receives an updated delivery area selection in response to the notification/prompt, validating the flight path/route to the new delivery destination, and instructing the drone to perform the delivery to the delivery destination (as per above) – Chambers does not explicitly teach that the user responds by also providing an updated delivery time.
However, Zhang teaches that the user selection to modify a delivery request including selection of a new delivery time window and new delivery area or fixed address (Zhang: ¶ 0102-0104). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the user selection of a delivery window when modifying a delivery request of Zhang in the UAV delivery system of Mulhall/Chambers with a reasonable expectation of success of arriving at the claimed invention, with the motivation to allow the user to “select a convenient delivery time window” (Zhang: ¶ 0104). In addition, it would have also been obvious to one of ordinary skill in the art before the effective filing date of the invention to do so, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 2: Mulhall/Chambers/Zhang teach claim 1. Mulhall, as modified above, further teaches:
wherein: in a state in which it is determined that it is possible for the drone to deliver the product to the vehicle before the vehicle arrives at the destination, the controller is configures to further determine, on a basis of at least one of a traveling state of the vehicle and a traveling environment of the vehicle, whether or not it is possible to receive the product from the drone (Mulhall: ¶ 0088-0093 showing determining method of delivery/transfer protocol for delivering the order from the UAV to the receiving vehicle, based on environmental conditions in the rendezvous area (i.e. traveling environment of the vehicle), and the operational state of the vehicle (e.g. velocity, whether the vehicle is under autopilot, etc.))
Claim 4: Mulhall/Chambers/Zhang teach claim 1. Mulhall, as modified above, further teaches:
wherein: in a state in which it is determined that it is possible for the drone to deliver the product to the vehicle before the vehicle arrives at the destination, the controller is further configured to calculate, in accordance with a request of the user, a timing to receive the product from the drone (Mulhall: ¶ 0083, ¶ 0062-0064 showing determining timing for the drone and receiving vehicle to rendezvous for delivery; also see ¶ 0006 “determine when and where the UAV may be able to efficiently rendezvous with the receiving vehicle to deliver the product”; also see ¶ 0007, ¶ 0036 showing determine when and where to rendezvous between the UAV and the receiving vehicle)
Claim 5: See the rejection of claim 1 teaching analogous limitations. Mulhall further teaches:
A control method for use in a control device that includes a controller (Mulhall: ¶ 0032-0033, ¶ 0098-0099 showing computer implementing the en route delivery flight planner system; Fig. 6, ¶ 0075 showing “a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations”).
Claim 6: See the rejection of claim 1 teaching analogous limitations. Mulhall further teaching: A computer-readable storage medium having a control program stored therein, the control program causing a computer to execute a process (Mulhall: ¶ 0098-0102 showing memory/storage device storing program executed by CPU, with ¶ 0102 specifying the memory/storage device as a “computer-readable storage medium”; and ¶ 0075 showing “a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hunter Molnar whose telephone number is (571)272-8271. The examiner can normally be reached Monday - Friday, 7:30 - 4:00 EST.
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, Jeffrey Zimmerman can be reached on (571)272-4602. 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.
/HUNTER MOLNAR/Examiner, Art Unit 3628