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 .
Status of the Application
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 12/19/2025 has been entered.
Status of Claims
Claims 1-9 and 11-19 are currently amended.
Claims 1-9 and 11-19 are currently pending following this response.
New matter
No new matter has been added to the amended claims.
Response to Arguments - 35 USC § 101
The arguments have been fully considered, but they are not persuasive.
Regarding applicant’s arguments on pages 13-14
The Examiner respectfully disagrees.
Claims can recite an abstract idea even if they are claimed as being performed on a computer. The Supreme Court recognized this in Benson, determining that a mathematical algorithm for converting binary coded decimal to pure binary within a computer’s shift register was an abstract idea. The Court concluded that the algorithm could be performed purely mentally even though the claimed procedures "can be carried out in existing computers long in use, no new machinery being necessary." 409 U.S at 67, 175 USPQ at 675. See also Mortgage Grader, 811 F.3d at 1324, 117 USPQ2d at 1699 (concluding that concept of "anonymous loan shopping" recited in a computer system claim is an abstract idea because it could be "performed by humans without a computer’).
Collecting data, recognizing certain data within the collected data set, and storing that recognized data in a memory in Content Extraction is according to the court an abstract idea that is similar to other concepts that have been identified as abstract by the courts. Present claim 1 is collecting data over a network and analyzing data using a generic computer processor. Therefore, it is reasonable to conclude based on the similarity of the idea described in this claim to several abstract ideas found by the courts that claim 1 is directed to an abstract idea.
Further, the additional elements in the claims “from a requestor device”, “executing one or more program modules communicably coupled to a server, the one or more program modules configured to communicate over a network with the requestor device and at least one service provider device, the at least one service provider device configured to provide service related to the work service request; configuring the one or more program modules for”, “from the requestor device”, “as provided by the requestor device”, “to one or more service provider devices”, “from the at least one service provider device”, “to the requestor device”, “on a graphical user interface of the requestor device”, “by the requestor device”) do not improve any existing technology (Applicant’s arguments page 17 “improvement to a technical field”) because the present claims are a combination of old elements where a processor is receiving information (over a network), analyzing, and sending results over a network. Any advantages claimed by Applicant such as “improvement in matching labor with local demand” is a business improvement. As a result, the additional elements do not integrate the abstract idea into a practical application, Step 2A Prong Two.
Because the Examiner has determined that the judicial exception is not integrated into a practical application, the Examiner proceeds to Step 2B of the Eligibility Guidelines, which asks whether there is an inventive concept. In making this Step 2B determination, the Examiner must consider whether there are specific limitations or elements recited in the claim “that are not well - understood, routine, conventional activity in the field, which is indicative that an inventive concept may be present” or whether the claim “simply appends well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, indicative that an inventive concept may not be present.” Eligibility Guidance, 84 Fed. Reg. 56 (footnote omitted). The Examiner must also consider whether the combination of steps perform “in an unconventional way and therefore include an ‘inventive step,’ rendering the claim eligible at Step 2B” Id. In this part of the analysis, the Examiner considers “the elements of each claim both individually and ‘as an ordered combination’” to determine “whether the additional elements ‘transform the nature of the claim’ into a patent-eligible application.” Alice, 134 S. Ct. at 2354. As discussed above, there is no evidence in the record that the steps of generating routes, locations, and tracking information in real-time that may be displayed on multiple devices in real-time are accomplished in a non-conventional way. The Examiner therefore concludes that the claims used generic, conventional, technology to implement the abstract idea of generating routes, locations, and tracking information in real-time that may be displayed on multiple devices in real-time and that there is no improvement to an “existing technology.”
In conclusion, the Examiner maintains the rejections of the pending claims under 35 USC § 101 in the present office action.
Response to Arguments - 35 USC § 102/103
The arguments have been fully considered, but they are not persuasive.
Regarding applicant’s arguments on pages 18-32
The Examiner respectfully disagrees.
Applicant’s arguments are directed to the new claim amendments where the Examiner submits that Yamashita still teaches the entire independent claim 1 as explained in the 35 USC § 102 below. Applicant’s arguments in this regard are moot. Although Yamashita specifically teaches type of service request as explained below (see rejection of claim 1 under 35 USC § 102) the emphasized request including “type of work service” as argued by Applicant should not be giving much weight by the Examiner because it is a non-functional descriptive material per MPEP 2111. (5). The present claims are a combination of old computer elements performing old steps of matching a service to a demand and displaying real-time location information wherein a map image of an Uber® Application is sufficient to reject the entire independent claim 1.
In conclusion, the Examiner maintains the rejections of the pending claims under 35 USC § 102/103 in the present office action.
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 and 11-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Specifically, claims 1-9 and 11-19 are directed to an abstract idea without additional elements to integrate the claims into a practical application or to amount to significantly more than the abstract idea.
Claims 1-9 and 11-19 are directed to a process, machine, or manufacture (Step 1), however the claims are directed to the abstract idea of connecting a service requester to a service provider.
With respect to Step 2A Prong One of the frameworks, claim 1 recites an abstract idea. Claim 1 includes limitations for “A method for handling a work service request, the method comprising: receiving the work service request, the work service request including at least a time of service and type of work service, determining the geographical location of the requestor device, broadcasting the work service request, and matching the at least one service provide device, within the geographical location of the requestor device, with the received work service request, receiving matching the work service request an indication of acceptance of the work service request, and sending a notification when the at least one service provider accepts the work service request; wherein matching the at least one service provider device with the work service request comprises iteratively requesting a communication from one or more service provider devices based on proximity to the geographical location of the requestor device, service provider availability, and service provider response time; and wherein iteratively requesting a communication from one or more service provider devices comprises: collecting, for a first duration, a first set of service provider devices responsive to the work service request, within a first distance of the geographical location of the requestor device, and capable of fulfilling the time of service of the work service request, extending collection of service provider devices for at least a second duration and a second distance from the requestor device, and collecting a second set of service providers responsive to the work service request, within a second distance of the geographical location of the requestor device, and capable of fulfilling the time of service of the work service request; wherein the second distance is greater than the first distance; displaying information for the at least one service provider device accepting the work service request including the real-time current location, estimated arrival time, and distance to the requestor device; and receiving a selection of service provider from the at least one service providers accepting the work service request”
The limitations above recite an abstract idea under Step 2A Prong One. More particularly, the limitations above recite certain methods of organizing human activity associated with managing personal behavior or relationships or interactions between people because the claimed elements describe a process for connecting a service requester to a service provider. As a result, claim 1 recites an abstract idea under Step 2A Prong One.
Claims 2-9 and 11-19 recite certain methods of organizing human activity associated with managing personal behavior or relationships or interactions between people because the claimed elements describe a process for connecting a service requester to a service provider. As a result, claims 2-9 and 11-19 recite an abstract idea under Step 2A Prong One.
With respect to Step 2A Prong Two of the framework, claim 1 does not include additional elements that integrate the abstract idea into a practical application. Claim 1 includes additional elements that do not recite an abstract idea. The additional elements of claim 1 include “from a requestor device”, “executing one or more program modules communicably coupled to a server, the one or more program modules configured to communicate over a network with the requestor device and at least one service provider device, the at least one service provider device configured to provide service related to the work service request; configuring the one or more program modules for”, “from the requestor device”, “as provided by the requestor device”, “to one or more service provider devices”, “from the at least one service provider device”, “to the requestor device”, “on a graphical user interface of the requestor device”, “by the requestor device”. When considered in view of the claim as a whole, the steps of “receiving and sending” do not integrate the abstract idea into a practical application because “receiving and sending” is an insignificant extra solution activity to the judicial exception. When considered in view of the claim as a whole, the recited computer elements do not integrate the abstract idea into a practical application because the computer elements are generic computer elements that are merely used as a tool to perform the recited abstract idea. As a result, claim 1 does not include additional elements that integrate the abstract idea into a practical application under Step 2A Prong Two.
Claims 2-9 and 11-19 do not include any additional elements beyond those recited by independent claims 1. As a result, claims 2-9 and 11-19 do not include additional elements that integrate the abstract idea into a practical application under Step 2A Prong Two.
With respect to Step 2B of the framework, claim 1 does not include additional elements amounting to significantly more than the abstract idea. As noted above, claim 1 includes additional elements that do not recite an abstract idea. The additional elements of claim 1 include “from a requestor device”, “executing one or more program modules communicably coupled to a server, the one or more program modules configured to communicate over a network with the requestor device and at least one service provider device, the at least one service provider device configured to provide service related to the work service request; configuring the one or more program modules for”, “from the requestor device”, “as provided by the requestor device”, “to one or more service provider devices”, “from the at least one service provider device”, “to the requestor device”, “on a graphical user interface of the requestor device”, “by the requestor device”. The steps of “receiving and sending” do not amount to significantly more than the abstract idea because “receiving and sending” are well-understood, routine, and conventional computer function in view of MPEP 2106.05(d)(ll). The recited computer elements do not amount to significantly more than the abstract idea because the computer elements are generic computer elements that are merely used as a tool to perform the recited abstract idea. As a result, claim 1 does not include additional elements that amount to significantly more than the abstract idea under Step 2B.
Claims 2-9 and 11-19 do not include any additional elements beyond those recited by independent claims 1. As a result, claims 2-9 and 11-19 do not include additional elements that amount to significantly more than the abstract idea under Step 2B.
Therefore, the claims are directed to an abstract idea without additional elements amounting to significantly more than the abstract idea. Accordingly, claims 1-9 and 11-19 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-7 and 11-19 are rejected under 35 U.S.C. 102 (a) (2) as being anticipated by Yamashita et al. (US 20180089784 A1).
Regarding 1. Yamashita teaches A method for handling a work service request from a requestor device, the method comprising: [Yamashita, abstract, Yamashita teaches “cause the computing device of the requester to determine, without subsequent manual intervention, a service location where a service is to be completed for the requester”. See also para. 006-008] executing one or more program modules communicably coupled to a server, the one or more program modules configured to communicate over a network with the requestor device and at least one service provider device, the at least one service provider device configured to provide service related to the work service request; [Yamashita, para. 004 and figure 1, Yamashita teaches “a block diagram illustrating an example network computer system in communication with user and service provider devices”. See also para. 0023 “methods, techniques, and actions performed by a computing device are performed programmatically, or as a computer-implemented method. Programmatically, as used herein, means through the use of code or computer-executable instructions. These instructions can be stored in one or more memory resources of the computing device” wherein program modules] configuring the one or more program modules for: receiving the work service request from the requestor device, the work service request including at least a time of service and type of work service as provided by the requestor device, [Yamashita, para. 0016, Yamashita teaches “According to examples described herein, selection of a service accelerator by the user can automatically cause the network computer system to receive, from the user device, a service request, and process the service request without any additional input or subsequent manual intervention by the user (e.g., begin selection process to select a proximate service provider to service the ride). In some examples, the service accelerator, or accelerator feature, can greatly reduce the number of sequential screens needed by current transport service applications in order to confirm a service request. In other examples, selection of a service accelerator can cause a confirmation screen to be displayed (e.g., confirming the estimated service cost, service type, pick-up location and/or destination, service time, etc.” Emphasis added, wherein service request with service type and service time] determining the geographical location of the requestor device, [Yamashita, see figure 3A, “determine current rider location 315”] broadcasting the work service request to one or more service provider devices, and matching the at least one service provide device, within the geographical location of the requestor device, with the received work service request, [Yamashita, para. 0061, Yamashita teaches “Additionally or alternatively, the network computer system 100 can automatically identify a service location in proximity to or at the user's current location 173, and select an optimal service provider 189 to facilitate the service request 171”] receiving from the at least one service provider device matching the work service request an indication of acceptance of the work service request, [See Yamashita para. 0085 “for example, accept or reject service invitations 792 in order to fulfill service requests throughout a given region” and figure 7] and sending a notification to the requestor device when the at least one service provider accepts the work service request; [See Yamashita para. 0071 “However, if the service provider accepts, then the network computer system 100 can receive an indication of the acceptance confirmation 181 from the optimal service provider 189 (455), and transmit a rendezvous confirmation to the requesting user 174 (460).”] wherein matching the at least one service provider device with the work service request comprises iteratively requesting a communication from one or more service provider devices based on proximity to the geographical location of the requestor device, service provider availability, and service provider response time; and wherein iteratively requesting a communication from one or more service provider devices comprises: collecting, for a first duration, a first set of service provider devices responsive to the work service request, within a first distance of the geographical location of the requestor device, and capable of fulfilling the time of service of the work service request, extending collection of service provider devices for at least a second duration and a second distance from the requestor device, and collecting a second set of service providers responsive to the work service request, within a second distance of the geographical location of the requestor device, and capable of fulfilling the time of service of the work service request; wherein the second distance is greater than the first distance; [ The claimed language in view of the specification and in view of figures 8-9 are nothing but displaying in real time the service providers in proximity of the service request location and displaying the distance along with ETA. See Yamashita figure 6A and 6B output service provider and requester location in real time, para. 0061 “system 100 can automatically identify a service location in proximity”. See also para. 0077 for ETA “estimated time of arrival information 611 for the servicing driver 615”, and figure 6A proximity drivers 607] displaying, on a graphical user interface of the requestor device, information for the at least one service provider device accepting the work service request including the real-time current location, estimated arrival time, and distance to the requestor device; and receiving a selection of service provider by the requestor device from the at least one service providers accepting the work service request. [Yamashita, figure 6B, Yamashita teaches a display of the accepted driver 615 with ETA 611 a distance from a service requestor]
Regarding 2. wherein the one or more program modules are further configured to provide a route to the service provider device in real-time to reach the geographical location of the requestor device [See Yamashita figures 6A 6B real time route].
Regarding 3. wherein the one or more program modules are further configured to locate a new set of one or more service provider devices within a proximity of the requestor device if the server does not receive indication from the at least one service provider device to accept the request within the predefined time [See Yamashita para. 0071 “If the service provider 189 declines, then the network computer system 100 can identify another optimal service provider 189”].
Regarding 4. wherein the proximity determined based on radial proximity relative to the requestor device [See Yamashita para. 0014 “For example, the network computer system can determine a geo-fence surrounding the service location (or a geo-fence defined by a radius away from the service location)”].
Regarding 5. wherein the proximity determined based on radial proximity relative to the requestor device [See Yamashita para. 0014 “For example, the network computer system can determine a geo-fence surrounding the service location (or a geo-fence defined by a radius away from the service location)”].
Regarding 6. wherein the one or more program modules are further configured to: enable the requestor device to set a first criterion to automatically receive notification respective of the at least one service provider on satisfaction of the set first criterion, where in the first criterion includes preferred month, day, time, and location; and enable the requestor device to set a second criterion to automatically receive notification of the at least one service provider on satisfaction of the set second criterion, wherein the second criterion includes preferred service provider and location of the preferred service provider [See Yamashita para. 0036 “the network computer system 100 can further include a database 140 storing requester profiles 144 including historical information specific to the individual users 174 of the on-demand network-based service. Such information can include user preferences of service types, routine services service locations, pick-up and destination locations, work addresses, home addresses” wherein user service preference and wherein routine services is equivalent to month, day, time, and location].
Regarding 7. Yamashita teaches all of the limitations of claim 1 (as above). Further Yamashita teaches wherein the one or more program modules are further configured to enable the at least one service provider device to automatically send notification to one or more other requestor devices [See Yamashita para. 0045 “In some variations, the accelerator engine 150 can generate and transmit a push notification to the user device 170 indicating that a service accelerator 152 has been triggered and is available for usage” wherein automatic notification]
on entering a particular geographical location [See Yamashita para. 0054 “In some aspects, the user location 213 can act as an accelerator trigger 216 when the user enters a certain geo-fenced area associated with a service accelerator 259, or leaves a location associated with a service accelerator 259 (e.g., the user's home)” wherein automatic notification when entering a geo location]
Regarding 11. Yamashita in view of Mitchell teaches all of the limitations of claim 9 (as above). Further, Yamashita teaches further comprising automatically retrieving geographical location data associated with the requestor device upon access of a website associated with the at least one service provider by the requestor device [See Yamashita para. 0047 “In some aspects, the selection engine 130 can determine a user location 178 corresponding to the requesting user's 174 current location (e.g., via GPS resources of the requester device 170).”].
Regarding 12. Yamashita in view of Mitchell teaches all of the limitations of claim 9 (as above). Further, Yamashita teaches wherein the requestor device utilizes a software application to communicate geographical location data to at least one of the server or the one or more program modules [See Yamashita para. 0014 “the network computer system can further synchronize with a user device to, for example, identify the user's contacts, the user's schedule and appointments, travel plans (e.g., a scheduled trip), and the like.” Wherein the system constructed and arranged to communicate user location data].
Regarding 13. Yamashita in view of Mitchell teaches all of the limitations of claim 9 (as above). Further, Yamashita teaches wherein the matching the at least one service provider device with the work service request further comprises iteratively requesting from each of the one or more service providers at least one of a proximity of the at least one service provider device based on company location to request device geographical location, a service provider experience, and a service provider service type [See Yamashita para. 0071 “The network computer system 100 can then identify a set of service providers 184 within a location proximity or estimated time from the service location (440)” Wherein matching based on proximity. Further, para. 0033 teaches “or can be a proximate service provider that is optimal for other reasons, such as the service provider's experience, the amount of time the service provider has been on the clock, the service provider's current earnings, and the like” wherein matching based on experience and other factors].
Regarding 14. Yamashita in view of Mitchell teaches all of the limitations of claim 9 (as above). Further, Yamashita teaches wherein the proximity is based on radial proximity relative to the requestor device [See Yamashita para. 0014 “For example, the network computer system can determine a geo-fence surrounding the service location (or a geo-fence defined by a radius away from the service location)” wherein radial proximity].
Regarding 15. Yamashita in view of Mitchell teaches all of the limitations of claim 9 (as above). Further, Yamashita teaches wherein the proximity is based on radial proximity relative to the requestor device, and wherein the radial proximity is less than 25 miles [See Yamashita para. 0014 “For example, the network computer system can determine a geo-fence surrounding the service location (or a geo-fence defined by a radius away from the service location)” wherein radial proximity. Wherein less than 25 miles is a design choice].
Regarding 16. Yamashita in view of Mitchell teaches all of the limitations of claim 9 (as above). Further, Yamashita teaches wherein the proximity is based on radial proximity relative to the at least one service provider device [See Yamashita figure 6A and 6B output service provider and requester location in real time” wherein proximity to service provider’s device]
Regarding 17. Yamashita in view of Mitchell teaches all of the limitations of claim 9 (as above). Further, Yamashita teaches further comprising broadcasting to the requestor device and displaying on the graphical user interface of the requestor device, in real time, the location data of the at least one service provider based on at least one of a service provider's website, web portal, or web-based software application and displaying at least one of the number of service providers available for the work service request, an estimated time of arrival of a nearest service provider, and the distance to the at least one service provider nearest the requestor device [See Yamashita figures 6A 6B route, ETA…]
Regarding 18. Yamashita in view of Mitchell teaches all of the limitations of claim 9 (as above). Further, Yamashita teaches further comprising periodically updating retrieved location data of the at least one service provider device and location data of the requestor device and communicating the location data of the requestor device and the at least one service provider device to the server [See Yamashita figures 6A 6B route and service provider location relative to the service requester which is displayed/updated in real time. The Examiner takes an official notice that the location map with is a real time display gets updates in less than 3 seconds]
Regarding 19. Yamashita in view of Mitchell teaches all of the limitations of claim 9 (as above). Further, Yamashita teaches wherein either the first or second set of service provider devices is associated with at least one company [See Yamashita para. 0014“In determining an optimal service provider to fulfill or complete a given service request, the network computer system can identify a plurality of candidate service providers to fulfill the service request based on a service location” plurality of service providers]
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 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 non-obviousness.
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.
Claims 8-9 are rejected under 35 U.S.C. 103 as being un-patentable over Yamashita in view of Mitchell et al. (US 8364513 B2)
Regarding 8. Yamashita teaches all of the limitations of claim 1 (as above). Yamashita does not specifically teach, however; Michell teaches wherein the one or more program modules are further configured to enable at least one of the requestor device and the at least one service provider device to change, in real-time, a scheduled request, cancelled the request, cancelled the accepted request by the service provider, and change a schedule of the accepted request [See Michell col. 8 lines 59-60 “One or more dispatchers 120 may use a dispatch application 140 to convey schedule change information to the field technicians 115” wherein change a service schedule request. Also see Michell col. 19 lines 20-23 “An appointment booking profile may be deleted by selecting it in the list 623 and then selecting a delete button 624c” wherein deleting a request]
Yamashita teaches control the display of user interface features on remote computing devices and Mitchell technicians preference customization. It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify/combine utilizing communications within a network to organize and execute service requests of Yamashita with the real-time scheduling change of Mitchell 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, with the predictable results of optimizing utilizing communications within a network to organize and execute service requests.
Regarding 9. Yamashita teaches all of the limitations of claim 1 (as above). Yamashita does not specifically teach, however; Michell teaches wherein the one or more program modules are further configured to send a notification in real-time to at least one of the requestor device and the at least one service provider device on changes in schedule, cancellation of request, acceptance of request and cancellation of accepted request [See Michell claim 7 “sending, to the particular device used by the particular supervisor, the message to alert the supervisor of the detected issue comprises sending a message that indicates that the particular technician is likely to miss the scheduled start time of the next work order” wherein sending notification in real time
it would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify/combine utilizing communications within a network to organize and execute service requests of Yamashita with sending notification of Mitchell 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, with the predictable results of optimizing utilizing communications within a network to organize and execute service requests.
Conclusion
Any inquiry concerning this communication from the examiner should be directed to Abdallah El-Hagehassan whose contact information is (571) 272-0819 and Abdallah.el-hagehassan@uspto.gov The examiner can normally be reached on Monday- Friday 8 am to 5 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rutao Wu can be reached on (571) 272-6045. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3734.
Information regarding the status of an application may be obtained from the patent application information retrieval (PAIR) system. Status information of published applications may be obtained from either private PAIR or public PAIR. Status information of unpublished applications is available through private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have any questions on access to the private PAIR system, contact the electronic business center (EBC) at (866) 271-9197 (toll-free). If you would like assistance from a USPTO customer service representative or access to the automated information system, call (800) 786-9199 (in US or Canada) or (571) 272-1000.
/ABDALLAH A EL-HAGE HASSAN/
Primary Examiner, Art Unit 3623