DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Notice to Applicant
The following is a second Non-Final Office Action for Application Serial Number: 18/213,994, filed on June 26, 2023. In response to Examiner's Non-Final Office Action dated October 01, 2025, Applicant on December 31, 2025, amended claims 1, 4, 5, 13, 16 and 17 and added new claim 23. Claims 1-20 and 23 are pending in this application and have been rejected below.
Response to Amendment
Applicant's amendments are acknowledged.
The 35 U.S.C. § 103 rejections are maintained in light of Applicant’s amendments.
Response to Arguments
Applicant’s arguments, see p. 8-10, filed December 31, 2025, with respect to the Marco 594’ reference have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Crady et al. (US 20060217885 A1). Please refer to the 35 U.S.C. 103 rejection for further explanation and rationale.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 and 23 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 13 and 23 recites “wherein a time when the notification is sent is based at least partially on a time when the identified at least one vehicle will become available”. The specification discloses the timing of the notification may be based on various data, including how long it will take an available identified vehicle to reach the user, etc. See at least Paragraph [0028]), which states “The timing of the notification may be based on the location of the user, how long it will take to reach the suggested location, any date and/or time of any task metric used to identify the user, how long it will take an available identified vehicle to reach the user, etc. In addition, the server computing devices may even provide the user's client device with instructions to provide and/or display the notification at that or some other particular time” and Paragraph [0083], which states “The timing of the notification may be based on the location of the user, how long it will take to reach the suggested location (for instance due to current or predicted traffic conditions), any date and/or time of any task metric used to identify the user, how long it will take an available identified vehicle to reach the user, etc. If the current location of the user is approximately 30 minutes from the restaurant (via being transported by the vehicle) and an available identified vehicle is only 2 minutes from picking up the user, the server computing devices may send the notification at least 32 minutes before 8 pm on a Friday evening suggesting that the user take a trip to the restaurant”. However there is no actual description given and the specification fails to provide support for the timing of sending a notification being based on when the identified vehicle will become available. The specification does not provide disclosure in sufficient detail to demonstrate to one of ordinary skill in the art that the claimed invention achieves such a function. For the purpose of examination, Examiner interprets the limitation to be “wherein a time when the notification is sent is based at least partially on how long it will take an available identified vehicle to reach the user”.
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-6, 9-18 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Marco et al., U.S. Publication No. 2017/0186126 [hereinafter Marco] and further in view of Crady et al., U.S. Publication No. 2006/0217885 [hereinafter Crady].
Referring to Claim 1, Marco teaches:
A method of reducing downtime for vehicles of a fleet of vehicles between trips, the method comprising:
identifying, by the one or more processors, one or more potential passenger, each of the one or more potential passenger being associated with a respective client computing device (Marco, [0044]), “information obtained by the device assistant logic 230 may be used to predict whether the passenger will submit a transportation request to the transportation service”; (Marco, [0070]), “backend server 302 receives device activity information from various passenger computing devices 104 and determines whether to classify the corresponding passengers as prospective passengers for a duration of time…”; (Marco, [0045]; [0049]; [0058]; [0079]);
sending, by the one or more processors, to each respective client computing device of the one or more potential passengers, a notification including an offer for the identified at least one vehicle to take the one or more users on a trip to a destination, wherein a time when the notification is sent is based at least partially on a time when the identified at least one vehicle will become available (Marco, [0079]), “in response to determining that a passenger is a prospective passenger based on the passenger's activity, a message may be sent by backend server 302 (or other computing system of backend system 116) to the passenger's computing device 104…The message may include any suitable indication to encourage or assist the passenger to submit a transportation request. For example, the message may include an indication of the proximity (e.g., expressed as an amount of time and/or distance from the location of the passenger computing device 104) of the driver that is en route towards the passenger, a discounted fare offer, a query as to whether the passenger desires a ride, or other suitable information… the message may be sent immediately after a determination that the passenger is a prospective passenger, in response to a driver accepting a request to drive towards a location based on the passenger's location, after a driver has already begun driving towards the location based on the passenger's location, while a driver is waiting at the location based on the passenger's location, or at any other suitable time”; (Marco, [0072]-[0073]), “if the activity information indicates that the passenger has a flight scheduled in two hours from an airport 30 minutes away and the stored device activity information indicates the customer has a propensity to arrive at an airport one hour before departure time, the backend server 302 may calculate that the passenger is most likely to generate a transportation request in 30 minutes… the most likely time and/or the duration may be selected based on the estimated travel time to a probable destination location determined based on the device activity information. For example, in the scenario described above, it may be determined that a passenger likes to arrive at the airport one hour prior to takeoff. Accordingly, the most likely time might be calculated by subtracting the estimated travel time from the passenger's location to the airport… from the time at which the passenger is estimated to want to arrive. Additionally, in some embodiments, additional time may be subtracted to account for an expected delay between the generation of the transportation request and the arrival of the driver”; (Marco, [0022]; [0061]); and
receiving, by the one or more processors from at least one of the respective client computing devices, a response to the notification indicating that at least one of the one or more potential passengers accepted the offer (Marco, [0079]), “the message may include reply options that allow the passenger to submit a transportation request”; (Marco, [0083]), “it is determined whether a transportation request has been received from the subscriber… If a transportation request is received from the subscriber, then the driver is navigated to the subscriber's location”; and
sending, by the one or more processors, dispatching instructions to the identified at least one vehicle to cause the identified at least one vehicle, while operating in an autonomous driving mode, to maneuver to one or more pickup locations after becoming available to pick up the at least one of the one or more potential passengers who accepted the offer (Marco, [0079]), “… a message may be sent by backend server 302 (or other computing system of backend system 116) to the passenger's computing device 104… The message may include any suitable indication to encourage or assist the passenger to submit a transportation request… the message may include reply options that allow the passenger to submit a transportation request”; (Marco, [0083]), “it is determined whether a transportation request has been received from the subscriber… If a transportation request is received from the subscriber, then the driver is navigated to the subscriber's location”; (Marco, [0012]), “a driver computing device 108 may be integrated within and/or communicate with a self-driven vehicle (e.g., a vehicle that has the capability of driving without physical steering guidance from a human being) and may influence the movement of the vehicle by providing route information (e.g., passenger pick-up and destination locations driver destination locations, navigational directions, etc.) to the self-driven vehicle. Accordingly, as used herein “driver” may refer to a human being that may physically drive or otherwise control movement of a vehicle or to the vehicle itself (e.g., in the case of a self-driven vehicle) or component thereof (e.g., computing device application 108 or logic thereof)”.
Marco teaches a backend server may access driver availability data to determine one or more drivers that would be suitable to fulfill the request from the passenger (see par. 0066), the driver availability data may include an identification of a driver and any suitable associated information, such as… whether the driver is currently transporting a passenger, a destination location of a current trip of the driver, an estimate of how long it will be before the driver finishes his current trip, whether the driver has opted for automatic acceptance of transportation requests, or other suitable information (see par. 0061), but Marco does not explicitly teach:
identifying, by one or more processors of a server, at least one vehicle of the fleet of vehicles that is currently providing services and will become available within a predetermined period of time.
However Crady teaches:
identifying, by one or more processors of a server, at least one vehicle of the fleet of vehicles that is currently providing services and will become available within a predetermined period of time (Crady, [0016]), “A fleet management system 110 receives real time or otherwise current location information from a number of service vehicles 112 in one or more fleets of vehicles, for example a fleet of vehicles for hire (e.g., taxis 112c, limousines 112b, and the like), a fleet of delivery vehicles 112a, or a fleet of business service vehicles… The location information is usually augmented by information identifying the vehicle (e.g., a vehicle and/or fleet ID), the data source (e.g., a source ID identifying the fleet management system 110), and vehicle status (e.g., availability, job status, time to next availability, time to next delivery, etc.). Each fleet management system 110 can report the vehicle data for one or more vehicles at a time”; (Crady, [0010]; [0059]).
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified the driver availability in Marco to include the vehicle limitation as taught by Crady. The motivation for doing this would have been to improve the method of pairing drivers and passengers in Marco (see par. 0020) to efficiently include the results of tracking and management of service vehicles (see Crady par. 0002).
Referring to Claim 2, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein the dispatching instructions are sent in order to reduce the downtime for the identified at least one vehicle between trips (Marco, [0048]), “Driver application logic 220 may also provide navigational data to the driver to allow the driver to travel to the pickup location of the transportation request received from the passenger so that the driver can fulfill the transportation request”. Examiner notes “… in order to reduce the downtime for the identified at least one vehicle between trips” has not been given patentable weight because it merely recites intended use of the system. In Hoffer v. Microsoft Corp., 405 F.3d 1326, 1329, 74 USPQ2d 1481, 1483 (Fed. Cir. 2005), the court held that when a "‘whereby’ clause states a condition that is material to patentability, it cannot be ignored in order to change the substance of the invention." Id. However, the court noted that a "‘whereby clause in a method claim is not given weight when it simply expresses the intended result of a process step positively recited.’" Id. (quoting Minton v. Nat’l Ass’n of Securities Dealers, Inc., 336 F.3d 1373, 1381, 67 USPQ2d 1614, 1620 (Fed. Cir. 2003)). See MPEP 2111.04(I).
Referring to Claim 3, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein identifying the one or more potential passengers is based on whether the one or more potential passengers are located within a predetermined distance from the identified at least one vehicle (Marco, [0079]), “In response to determining that a passenger is a prospective passenger based on the passenger's activity, a message may be sent by backend server 302 (or other computing system of backend system 116) to the passenger's computing device 104… The message may include any suitable indication to encourage or assist the passenger to submit a transportation request. For example, the message may include an indication of the proximity (e.g., expressed as an amount of time and/or distance from the location of the passenger computing device 104) of the driver that is en route towards the passenger”; (Marco, [0074]-[0075]).
Referring to Claim 4, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein identifying the one or more potential passengers is based on whether any potential passengers are associated with a task metric corresponding to a potential passenger's ride history (Marco, [0063]), “historical request data 326 may include information indicating whether particular requests were received from passengers who had been identified as prospective passengers based on device activity of the passengers”; (Marco, [0058]), “Passenger device activity data 317 may comprise activity information received from passenger computing devices… such as… calendar appointments… and/or information derived therefrom. Such activity information may include… flight reservations, train reservations, or other transportation reservations made or used by the passenger; calendar appointments or other written communications (e.g., emails, text messages, instant messages) specifying travel or meetings requiring travel by the passenger… passenger device activity data 317 may include statistics indicating how likely one or more particular types of activity data are to result in the generation of a transportation request by the passenger. As another example, passenger device activity data 317 may include statistics indicating when the user is most likely to generate a transportation request in connection with one or more particular activities. In some embodiments, passenger device activity data 317 may include a series of likelihoods that the passenger will generate a request as a function of time (e.g., around a time specified by the activity data, such as a flight time or a commute start time)”; (Marco, [0071]).
Referring to Claim 5, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein the notification indicates an estimated time of arrival of the identified at least one vehicle at a current location of a respective client computing device (Marco, [0016]), “the application may notify the user of the selected driver and provide real-time updates of the driver's location (e.g., with respect to the passenger's location) and estimated pick-up time…”; (Marco, [0079]), “the message may include an indication of the proximity (e.g., expressed as an amount of time and/or distance from the location of the passenger computing device 104) of the driver that is en route towards the passenger”.
Referring to Claim 6, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
further comprising:
receiving, by the one or more processors, location information identifying current locations of each of the respective client computing devices (Marco, [0074]-[0075]), “Backend server 302 may direct a driver to drive to a location based on the location of one or more prospective passengers… the location may be based on each of multiple prospective passengers' locations. For example, the location may be equidistant from the locations of the prospective passengers or the location may be weighted towards prospective passengers that have a higher likelihood of generating a transportation request. In various embodiments, backend server 302 may select a group of prospective passengers that are located near each other from a larger set of prospective passengers, and determine a location to which the driver should go based on the locations of the group of prospective passengers”.
Referring to Claim 9, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
further comprising:
prior to sending the notification to the respective client computing devices of the one or more potential passengers, determining, by the one or more processors, whether to dispatch the identified at least one vehicle or allow the identified at least one vehicle to wait (Marco, [0047]-[0049]), “driver application logic 220 may receive a request from the backend system 116 for the driver to drive towards one or more prospective passengers in anticipation of the backend system 116 receiving a transportation request from a passenger of the one or more prospective passengers (wherein the prospective passengers are selected based on activity information received from their respective computing devices)… Driver application logic 220 may also provide navigational data to the driver to allow the driver to travel towards the one or more prospective passengers to a location specified by the backend system 116…While the driver is en route to the location specified by the backend system 116 or after the driver has arrived and is waiting at the location, the backend system 116 may receive a transportation request from one of the prospective passengers or another passenger near the location of the driver and send the request to the driver application logic 220 which may present the request to the driver… Driver application logic 220 may also provide navigational data to the driver to allow the driver to travel to the pickup location of the transportation request received from the passenger so that the driver can fulfill the transportation request…”; (Marco, [0022]; [0066]; [0012]; [0083]).
Referring to Claim 10, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein the notification indicates that the identified at least one vehicle is currently maneuvering to the one or more pickup locations, or when the identified at least one vehicle will arrive at the one or more pickup locations (Marco, [0067]), “the backend server 302 notifies the passenger that a driver has accepted his request and provides any suitable information associated with the driver (e.g., driver's current location, model and color of vehicle, estimated time of arrival, etc.) to the passenger”.
Referring to Claim 11, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein the notification indicates that the identified at least one vehicle is waiting at one of the one or more pickup locations (Marco, [0079]), “… a message may be sent by backend server 302 (or other computing system of backend system 116) to the passenger's computing device 104… the message may include an indication of the proximity (e.g., expressed as an amount of time and/or distance from the location of the passenger computing device 104) of the driver that is en route towards the passenger… the message may be sent… while a driver is waiting at the location based on the passenger's location; (Marco, [0012]).
Referring to Claim 12, Marco in view of Crady teaches the method of claim 1. Marco further teaches:
wherein the notification provides a first option to accept the offer and a second option to decline the offer (Marco, [0079]), “the message may include reply options that allow the passenger to submit a transportation request… or indicate that the passenger does not desire a transportation request”.
Referring to Claim 13, Marco teaches:
A server computing device for reducing downtime for vehicles of a fleet of vehicles between trips, the server computing device comprising:
a memory configured to store data and instructions (Marco, [0024]; [0031]);
one or more processors configured to: access the data and instructions stored in the memory (Marco, [0031]);
Claim 13 disclose substantially the same subject matter as Claim 1, and is rejected using the same rationale as previously set forth.
Claim 14 disclose substantially the same subject matter as Claim 2, and is rejected using the same rationale as previously set forth.
Claim 15 disclose substantially the same subject matter as Claim 3, and is rejected using the same rationale as previously set forth.
Claim 16 disclose substantially the same subject matter as Claim 4, and is rejected using the same rationale as previously set forth.
Claim 17 disclose substantially the same subject matter as Claim 5, and is rejected using the same rationale as previously set forth.
Claim 18 disclose substantially the same subject matter as Claim 6, and is rejected using the same rationale as previously set forth.
Referring to Claim 23, Marco teaches:
A non-transitory computer-readable medium storing instructions, which when executed by one or more processors, cause the one or more processors to (Marco, [0031]);
Claim 23 disclose substantially the same subject matter as Claim 1, and is rejected using the same rationale as previously set forth.
Claims 7, 8, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Marco et al., U.S. Publication No. 2017/0186126 [hereinafter Marco], in view of Crady et al., U.S. Publication No. 2006/0217885 [hereinafter Crady], and further in view of Boskovic, U.S. Publication No. 2012/0290652 [hereinafter Boskovic].
Referring to Claim 7, Marco in view of Crady teaches the method of claim 1. Marco teaches sending messages to prospective passengers that may include suitable indications to encourage or assist the passenger to submit a transportation request (see par. 0079), but Marco does not explicitly teach:
wherein the notification indicates how many seats in the identified at least one vehicle are available for use for the trip to the destination.
However Boskovic teaches:
wherein the notification indicates how many seats in the identified at least one vehicle are available for use for the trip to the destination (Boskovic, [0090]), “offer may remain therein preferably with indication of free passenger slots. In connection with each ride offer, the service may be indeed configured to indicate the available person and optionally pet slots provided that the ride provider has indicated such information in the first place or it could have been deduced based on the available data (e.g. with motorcycle, typically only one slot for passengers is available and with a small van, there could only be two passenger seats). Otherwise, it may be presumed by the service that at least one free slot is available per each ride offer input”; (Boskovic, [0092]-[0093]), “preferably at least of departure and/or destination locations, may be provided to the concerned users. Each user may preferably obtain useful information such as schedule and/or map data about his/her personal overall journey to his/her terminal device such as a portable computer, a smartphone or a in-vehicle navigation, computing and/or communications system… the service may be configured to determine feasible transport sharing scenarios for the journeys of the users and output indications thereof to the terminals 704, 706. Real-time monitoring may be applied and up-to-date information relevant to the journeys be transmitted even after the departure time of the journeys”; (Boskovic, [0024]), “inform the associated user(s) and/or update or at least suggest update to the ride scenario or ride plan. E-mail, text or multimedia messages may be applied for sending the information among other options. Monitoring may include data retrieval via the data input entity and optionally processing thereof for determining the status of the tracked conditions”; (Boskovic, [0088]), “ride planning by the service with both public transportation and transport sharing aspects in accordance with an embodiment of the present invention. A journey of a service user includes the location of departure 602 and destination 614”; (Boskovic, [0097]).
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified messages in Marco to include the sending limitation as taught by Boskovic. The motivation for doing this would have been to improve the method of pairing of passengers and drivers in Marco (see par. 0002) to efficiently include the results of managing transport sharing (see Boskovic par. 0009).
Referring to Claim 8, Marco in view of Crady teaches the method of claim 7. Marco teaches sending messages to prospective passengers that include reply options that allow the passenger to submit a transportation request or indicate that the passenger does not desire a transportation request (see par. 0079), but Marco does not explicitly teach:
wherein the response to the notification indicates for which seats the offer is accepted.
However Boskovic teaches:
wherein the response to the notification indicates for which seats the offer is accepted (Boskovic, [0120]), “the concerned user(s) may be provided with an opportunity, such as a confirmation request, to accept the scenario 1314 or reject it”.
At the time the invention was filed, it would have been obvious to a person of ordinary skill in the art to have modified the reply options in Marco to include the receiving limitation as taught by Boskovic. The motivation for doing this would have been to improve the method of pairing of passengers and drivers in Marco (see par. 0002) to efficiently include the results of managing transport sharing (see Boskovic par. 0009).
Claim 19 disclose substantially the same subject matter as Claim 7, and is rejected using the same rationale as previously set forth.
Claim 20 disclose substantially the same subject matter as Claim 8, and is rejected using the same rationale as previously set forth.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Inciong et al. (US 9820108 B1) – A connected services manager may access and evaluate the driver's calendar to determine a soonest time at which the driver is available after the driver's estimated time of arrival. The connected services manager may then send a notification to a person that the driver was supposed to speak with at the scheduled meeting, in which the notification includes a proposal to reschedule the scheduled meeting for the soonest time. For example, the scheduled meeting may be at 9 AM on a Thursday, and based on the driver's estimated time of arrival, the driver will be more than an hour late. The connected services manager may determine that the driver will be free in the afternoon (e.g., 1 pm) of the same day (e.g., Thursday) or determine that the driver will not be available until Monday morning (e.g., 9 AM) of next week. Thus, the connected services manager may send a notification to the person with whom the driver was supposed to meet, in which the notification may include a proposal to reschedule the meeting for Thursday afternoon or Monday morning.
Wang et al. (US 20170178070 A1) – A capacity verifier accesses an inventory database and a vehicle database, based on at least one of a plurality of perishable good orders to be delivered by a plurality of delivery vehicles to a plurality of delivery sites. A dispatch schedule generator generates an initial dispatch schedule in which each of the plurality of delivery vehicles is individually scheduled for delivery to at least one of the plurality of delivery sites to define a delivery assignment, each delivery assignment being subject to an associated expiration time window for the perishable good being delivered. A dispatch schedule optimizer executes an iterative updating of an initial dispatch schedule wherein, in each iteration, at least one delivery assignment is altered and a resulting dispatch schedule is evaluated relative to associated expiration time windows, until an optimized dispatch schedule is obtained.
Smith et al. (US 5835376 A) – If, after evaluating all of the vehicles identified by the AVL, no available vehicles are located, the dispatching process is unable to automatically dispatch the current job and must request human intervention. In this case, the dispatching process writes the an exception record to the exception file, indicating the transport ID number of the current dispatch record and a reason code indicating that the automated dispatching failed because of the absence of an available vehicle. Subsequently, a human dispatcher will evaluate the dispatch record and take the appropriate action, for example, calling individual vehicles to ensure that they have in fact not completed their current assignments, or, calling the customer who requested the job to inform them that a vehicle will be dispatched late for the pickup. After writing a record to an exception file, dispatching process moves on to the next record in the dispatch file by proceeding to step.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Crystol Stewart whose telephone number is (571)272-1691. The examiner can normally be reached 9:00am-5:00pm.
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, Patty Munson can be reached on (571)270-5396. 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.
/CRYSTOL STEWART/Primary Examiner, Art Unit 3624
Prosecution Insights