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 Claims
A preliminary amendment was filed on 06/06/2024. Claims 1-159 were canceled. Claims 160-189 are current pending in the instant patent application.
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.
Regarding Claims 160-189, they are directed to a system, however the claims are directed to a judicial exception without significantly more. Claims 160-189 are directed to the abstract idea of emergency medical service dispatching.
Performing the Step 2A Prong 1 analysis while referring specifically to independent Claim 160, claim 160 recites receive real-time EMS vehicle location tracking information associated with the EMS agency vehicle; receive a request for EMS services for a patient; generate a pending EMS trip assignment in response to the request for EMS services; automatically capture at least one item of EMS trip information in at least one data entry field of the plurality of data entry fields based on a user selection of a position or icon from the interactive graphical map; populate the pending EMS trip assignment based at least on part on the automatically captured at least one item of EMS trip information, the real-time EMS vehicle location tracking information, and the request for the EMS services for the patient, wherein the pending EMS trip assignment comprises an identification of at least one EMS agency vehicle; send the pending EMS trip assignment associated with the EMS agency vehicle; receive a trip acceptance associated with the EMS agency vehicle; and generate an EMS agency vehicle assignment of the EMS agency vehicle to the request for EMS services in response to the trip acceptance.
These claim limitations fall within the Certain Methods of Organizing Human Activity grouping of abstract ideas due to the managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). Furthermore, the claim limitations falls within the Mental Processes grouping of abstract ideas for these are concepts that can be performed in the human mind (including an observation, evaluation, judgment, opinion) and/or with pen/paper. Furthermore, the courts have found claims requiring a generic computer or nominally reciting a generic computer may still recite a mental process even though the claim limitations are not performed entirely in the human mind (see MPEP 2106.04(a)(2)(III)(C)).
Accordingly, the claim recites an abstract idea and dependent claims 161-189 further recite the abstract idea.
Regarding Step 2A Prong 2 analysis, the judicial exception is not integrated into a practical application. In particular the claim recites the elements of a cloud-based computer aided dispatch system, a mobile computing device, at least one processor, communicatively couple with a mobile computing device associated with an EMS agency vehicle, communicatively couple to a computing system associated with an EMS agency via a long-range communications network, host a dispatch graphical user interface (GUI) at the computing system associated with the EMS agency, wherein the dispatch GUI comprises: an interactive graphical map, and a data entry window comprising a plurality of data entry fields, wherein the cloud-based CAD system is configured for execution on a cloud-based distributed processing architecture. The cloud-based computer aided dispatch system, a mobile computing device, at least one processor, communicatively couple with a mobile computing device associated with an EMS agency vehicle, communicatively couple to a computing system associated with an EMS agency via a long-range communications network, host a dispatch graphical user interface (GUI) at the computing system associated with the EMS agency, wherein the dispatch GUI comprises: an interactive graphical map, and a data entry window comprising a plurality of data entry fields, wherein the cloud-based CAD system is configured for execution on a cloud-based distributed processing architecture are merely generic computing devices and do not integrate the judicial exception into a practical application.
With respect to 2B, the claims do not include additional elements amounting to significantly more than the abstract idea. Claim 160 includes various elements that are not directed to the abstract idea under 2A. These elements include cloud-based computer aided dispatch system, a mobile computing device, at least one processor, communicatively couple with a mobile computing device associated with an EMS agency vehicle, communicatively couple to a computing system associated with an EMS agency via a long-range communications network, host a dispatch graphical user interface (GUI) at the computing system associated with the EMS agency, wherein the dispatch GUI comprises: an interactive graphical map, and a data entry window comprising a plurality of data entry fields, wherein the cloud-based CAD system is configured for execution on a cloud-based distributed processing architecture and the generic computing elements described in the Applicant's specification in at least Para 0292-0301. These elements do not amount to more than the abstract idea because it is a generic computer performing generic functions. In addition, Claim 160 recites computer functions that the courts have recognized as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) (See MPEP 2106.05(d)(ii)…at least, Receiving or transmitting data over a network, e.g., using the Internet to gather data, buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network))).
Therefore, Claim 160-189 is not drawn to eligible subject matter as it is directed to abstract ideas without significantly more.
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.
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.
Claim(s) 160-163, 165-166, 168-173 and 189 is/are rejected under 35 U.S.C. 103 as being unpatentable over Moore et al. (US 2016/0342740 A1) in view of Roberts, SR et al. (US 2013/0184035 A1).
Regarding Claim 160, Moore teaches the limitations of Claim 160 which state
communicatively couple with a mobile computing device associated with an EMS agency vehicle (Moore: Para 0030, 0033-0034, 0055 via FIG. 1 illustrates an example of an EMS system 100 that can include a variety of modules, such as a dispatch module 110, a claims module 120 and an income forecasting module 130. For example, the dispatch module 110 can assist with dispatching medical services, the claims module 120 can compile claims including information related to medical services provided to a patient, and the income forecasting module 130 can assist with forecasting the collection of payments associated with medical services provided, as will be described in greater detail below. The medical services described herein can include either emergency medical services (e.g., ambulance transport from scene of accident to hospital) or non-emergency medical services (e.g., patient transfer between facilities). In addition, even when referred to as emergency medical services or EMS, non-emergency medical services can be included, and vice-versa…FIG. 2 illustrates a diagram showing a dispatch flow diagram 200 associated with the dispatch module 110. For example, at 210, the dispatch module 110 can provide a login interface for a user to login and request medical transport, such as emergency or non-emergency transport services. At 220, a dispatch unit can receive the request and assign a service unit to fulfill the request. The dispatch unit can send a message (e.g., via SMS) to the assigned service unit, which can be received by the service unit, at 240, and allow the service unit to fulfill the request. Alternatively or in addition, the dispatch unit can input information regarding the assigned service unit into the EMS system 100, such as the dispatch module 110, which can be viewed by the assigned service unit in order to allow the service unit to fulfill the request. At 250, the service unit can provide information to the dispatch module 110 to indicate that the request has been received and/or completed, such as a time stamp. The information entered into and created by the dispatch module 110 can be stored and made available for use with other modules, such as the claims module 120 and/or the forecasting module 130. In addition, at 260, information can be provided to the dispatch module 110 from a variety of sources (e.g., GPS devices, mobile applications, etc.), and this information can also be available to users of the EMS system 100 and/or other modules. The dispatch module 110 can be accessible through the internet and can provide EMS departments and private transport services a cost-effective way to manage their dispatch and tracking of dispatch services, including in at least near real-time);
receive real-time EMS vehicle location tracking information from the mobile computing device associated with the EMS agency vehicle (Moore: Para 0006, 0010, 0034 via The EMS computing platform includes a dispatch module connected with the EMS database and a geolocation service providing geolocation data for one or more EMS provider assets that are selectively dispatched to provide EMS to a selected patient. The dispatch module receives user input for the selected patient, and calculates a shortest time of an EMS provider asset to provide the EMS to the patient based on the at least one address. The EMS computing platform further includes a claims module associated with the dispatch module. The claims module generates a claim for the EMS provided to the patient, the claim being based at least in part on the EMS provided to the patient, the one or more medical conditions treated by the EMS, the at least one address, and the at least one insurer associated with the patient. The EMS computing system further includes an income forecasting module that generates a forecast for payment of the claim based on a forecasting model executed by the income forecasting module…generating, by at least one data processor, an EMS dispatch for the selected patient, the EMS dispatch comprising providing geolocation data for one or more EMS provider assets that are selectively dispatched to provide the EMS to the selected patient…At 250, the service unit can provide information to the dispatch module 110 to indicate that the request has been received and/or completed, such as a time stamp. The information entered into and created by the dispatch module 110 can be stored and made available for use with other modules, such as the claims module 120 and/or the forecasting module 130. In addition, at 260, information can be provided to the dispatch module 110 from a variety of sources (e.g., GPS devices, mobile applications, etc.), and this information can also be available to users of the EMS system 100 and/or other modules. The dispatch module 110 can be accessible through the internet and can provide EMS departments and private transport services a cost-effective way to manage their dispatch and tracking of dispatch services, including in at least near real-time);
receive a request for EMS services for a patient (Moore: Para 0033-0034 via FIG. 2 illustrates a diagram showing a dispatch flow diagram 200 associated with the dispatch module 110. For example, at 210, the dispatch module 110 can provide a login interface for a user to login and request medical transport, such as emergency or non-emergency transport services. At 220, a dispatch unit can receive the request and assign a service unit to fulfill the request. The dispatch unit can send a message (e.g., via SMS) to the assigned service unit, which can be received by the service unit, at 240, and allow the service unit to fulfill the request. Alternatively or in addition, the dispatch unit can input information regarding the assigned service unit into the EMS system 100, such as the dispatch module 110, which can be viewed by the assigned service unit in order to allow the service unit to fulfill the request. At 250, the service unit can provide information to the dispatch module 110 to indicate that the request has been received and/or completed, such as a time stamp. The information entered into and created by the dispatch module 110 can be stored and made available for use with other modules, such as the claims module 120 and/or the forecasting module 130. In addition, at 260, information can be provided to the dispatch module 110 from a variety of sources (e.g., GPS devices, mobile applications, etc.), and this information can also be available to users of the EMS system 100 and/or other modules. The dispatch module 110 can be accessible through the internet and can provide EMS departments and private transport services a cost-effective way to manage their dispatch and tracking of dispatch services, including in at least near real-time);
generate a pending EMS trip assignment in response to the request for EMS services (Moore: Para 0033-0034 via FIG. 2 illustrates a diagram showing a dispatch flow diagram 200 associated with the dispatch module 110. For example, at 210, the dispatch module 110 can provide a login interface for a user to login and request medical transport, such as emergency or non-emergency transport services. At 220, a dispatch unit can receive the request and assign a service unit to fulfill the request. The dispatch unit can send a message (e.g., via SMS) to the assigned service unit, which can be received by the service unit, at 240, and allow the service unit to fulfill the request. Alternatively or in addition, the dispatch unit can input information regarding the assigned service unit into the EMS system 100, such as the dispatch module 110, which can be viewed by the assigned service unit in order to allow the service unit to fulfill the request. At 250, the service unit can provide information to the dispatch module 110 to indicate that the request has been received and/or completed, such as a time stamp. The information entered into and created by the dispatch module 110 can be stored and made available for use with other modules, such as the claims module 120 and/or the forecasting module 130. In addition, at 260, information can be provided to the dispatch module 110 from a variety of sources (e.g., GPS devices, mobile applications, etc.), and this information can also be available to users of the EMS system 100 and/or other modules. The dispatch module 110 can be accessible through the internet and can provide EMS departments and private transport services a cost-effective way to manage their dispatch and tracking of dispatch services, including in at least near real-time);
communicatively couple to a computing system associated with an EMS agency via a long-range communications network (Moore: Para 0054 via One or more aspects or features of the subject matter described herein can be realized in digital electronic circuitry, integrated circuitry, specially designed application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) computer hardware, firmware, software, and/or combinations thereof. These various aspects or features can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. The programmable system or computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other);
host a dispatch graphical user interface (GUI) at the computing system associated with the EMS agency, wherein the dispatch GUI comprises: an interactive graphical map, and a data entry window comprising a plurality of data entry fields (Moore: Para 0031, 0035 via FIG. 6 shows an exemplary user interface for receiving, by the EMS system 100, patient information, such as demographic information and other information, such as insurance information, medical history, patient-specific notes, etc. FIG. 7 shows an exemplary user interface for providing an indication of eligibility verification for a specific patient, based at least in part on the patient information, and which could also be based on any EMS being requested for the patient…FIG. 8 shows an exemplary user interface of the dispatch module 110 for showing a representation of scheduled, completed, active and unpublished dispatches of EMS. The user interface of the dispatch module 110 can also provide a representation of the type of EMS dispatched, as well as a representation of current EMS activity. FIG. 9 shows another exemplary user interface of the dispatch module 110 that provides a graphical representation of the current EMS activity in real-time. In the example shown in FIG. 9, a map is generated, and icons of each active EMS activity is represented on the map, with an ability to provide a user further detail for each EMS activity represented on the user interface).
However, Moore does not explicitly teach the limitation of Claim 160 which states automatically capture at least one item of EMS trip information in at least one data entry field of the plurality of data entry fields based on a user selection of a position or icon from the interactive graphical map.
Roberts though, with the teachings of Moore, teaches of
automatically capture at least one item of EMS trip information in at least one data entry field of the plurality of data entry fields based on a user selection of a position or icon from the interactive graphical map (Roberts: Para 0040, 0046 via Referring now to FIGS. 5A-5D, a dispatcher may view a detailed driver status screen 150 particular to a selected driver. The dispatcher may cause the detailed driver status screen 150 to appear on the graphical display by using a navigational menu or tab system. To view more detailed status information related to a selected driver, the dispatcher may click on the driver's name in a driver list 152 and a detailed itinerary in the form of a driver assignment list 120 may be displayed along with a map 153 showing the driver's current location 155, planned route 156, and all stops 158, among other information. Other information may also be displayed and be available to the dispatcher, such as previous stop information, planned stop information (i.e., stops in which a driver is scheduled), unplanned stop information (i.e., stops that a driver made that were not scheduled or dispatched), actual route information (i.e., the order in which a driver actually completed his or her stops), planned route information (i.e., the order of planned stops) unassigned stop information (i.e., pickup requests that have not yet been assigned), and a display of the location of the terminal…To ensure that the dispatcher is viewing current information, the system automatically refreshes the status information. In one embodiment, all of the information provided to the dispatcher is automatically refreshed in real time. In another embodiment, the information provided to the dispatcher is refreshed in different intervals to minimize server load and data transmission overhead. For example, in one embodiment, the driver stack 110 updates every sixty seconds. This ensures that the dispatcher has the necessary information to manage in accordance with the exceptions. The exception information contained in the hover messages is retrieved and updated in real-time. In the event that the driver icon has not updated, the real-time hover message ensures that the dispatcher is working with current information).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Moore with the teachings of Roberts in order to have automatically capture at least one item of EMS trip information in at least one data entry field of the plurality of data entry fields based on a user selection of a position or icon from the interactive graphical map. The motivations behind this being to incorporate the teachings of intelligent wireless dispatch systems capable of wirelessly and dynamically performing dispatching operations. Furthermore, in addition to being in the same CPC class, the teachings, suggestions, and motivations in this prior art would have led one of ordinary skill to modify the prior art reference or combine prior art reference teachings to arrive at the claimed invention and simple substitution would yield predictable results.
The combination of Moore/Roberts further teaches the limitations of Claim 160 which state
populate the pending EMS trip assignment based at least on part on the automatically captured at least one item of EMS trip information, the real-time EMS vehicle location tracking information, and the request for the EMS services for the patient, wherein the pending EMS trip assignment comprises an identification of at least one EMS agency vehicle (Moore: Para 0006, 0033 via The EMS computing platform includes a dispatch module connected with the EMS database and a geolocation service providing geolocation data for one or more EMS provider assets that are selectively dispatched to provide EMS to a selected patient. The dispatch module receives user input for the selected patient, and calculates a shortest time of an EMS provider asset to provide the EMS to the patient based on the at least one address. The EMS computing platform further includes a claims module associated with the dispatch module. The claims module generates a claim for the EMS provided to the patient, the claim being based at least in part on the EMS provided to the patient, the one or more medical conditions treated by the EMS, the at least one address, and the at least one insurer associated with the patient. The EMS computing system further includes an income forecasting module that generates a forecast for payment of the claim based on a forecasting model executed by the income forecasting module…FIG. 2 illustrates a diagram showing a dispatch flow diagram 200 associated with the dispatch module 110. For example, at 210, the dispatch module 110 can provide a login interface for a user to login and request medical transport, such as emergency or non-emergency transport services. At 220, a dispatch unit can receive the request and assign a service unit to fulfill the request. The dispatch unit can send a message (e.g., via SMS) to the assigned service unit, which can be received by the service unit, at 240, and allow the service unit to fulfill the request. Alternatively or in addition, the dispatch unit can input information regarding the assigned service unit into the EMS system 100, such as the dispatch module 110, which can be viewed by the assigned service unit in order to allow the service unit to fulfill the request).
send the pending EMS trip assignment to the mobile computing device associated with the EMS agency vehicle (Roberts: Para 0150-0151 via When the dispatcher transmits a new assignment to a driver, the intelligent wireless dispatch system 10 updates the display of the MDT with a new assignment screen 208 that contains information regarding a pickup or a delivery for driver review. For example, the new assignment screen may display whether the assignment is a pickup or a delivery, the name and address of the customer, the time of the assignment, and other information (e.g., whether the assignment is a cash on delivery ("COD") assignment, the number of handling units and the total weight of the freight to be picked up). Also provided on the new assignment screen 208 are large-sized driver input selections. In the illustrated embodiment, the driver input selections include Accept button 201, Decline:Time button 203 and Decline:Load button 205. The buttons are configured as a large size so that a driver may easily make a selection, even if he or she is wearing gloves. To accept a new assignment, the driver may press or otherwise select the Accept button 201, to wirelessly transmit a structured acceptance message from the MDT to the dispatch computer. In this manner, the driver does not need to type a message or verbally accept the new assignment to the dispatcher. Once the structured acceptance message is received at the dispatch computer, the intelligent wireless dispatch system 10 will update the driver stack 110 on the dispatcher's display and also update the driver task screen 206, which will be visible after the driver presses the Accept button 201 (see FIG. 6A)).
receive a trip acceptance from the mobile computing device associated with the EMS agency vehicle (Roberts: Para 0151 via To accept a new assignment, the driver may press or otherwise select the Accept button 201, to wirelessly transmit a structured acceptance message from the MDT to the dispatch computer. In this manner, the driver does not need to type a message or verbally accept the new assignment to the dispatcher. Once the structured acceptance message is received at the dispatch computer, the intelligent wireless dispatch system 10 will update the driver stack 110 on the dispatcher's display and also update the driver task screen 206, which will be visible after the driver presses the Accept button 201 (see FIG. 6A)).
generate an EMS agency vehicle assignment of the EMS agency vehicle to the request for EMS services in response to the trip acceptance (Roberts: Para 0151 via To accept a new assignment, the driver may press or otherwise select the Accept button 201, to wirelessly transmit a structured acceptance message from the MDT to the dispatch computer. In this manner, the driver does not need to type a message or verbally accept the new assignment to the dispatcher. Once the structured acceptance message is received at the dispatch computer, the intelligent wireless dispatch system 10 will update the driver stack 110 on the dispatcher's display and also update the driver task screen 206, which will be visible after the driver presses the Accept button 201 (see FIG. 6A)).
wherein the cloud-based CAD system is configured for execution on a cloud-based distributed processing architecture (Moore: Para 0028 via Providing emergency medical services (EMS) and managing information and billing related to the services provided can be complex. As such, there is a need to provide a system that can simplify and improve the collection and distribution of information and services related to EMS. The present disclosure describes an EMS system that can provide one or more modules that can assist with at least the collection and distribution of either information or services in an improved and user-friendly way. For example, the EMS system, including any one of the modules, can be web-based, including cloud-based, and can be accessible using a variety of platforms (e.g., mobile devices, tablet computers, PC/laptops, etc.). The modules can be in communication with each other, which can allow the transfer and sharing of data from one module to another and can save time and improve the quality of data and services provided by the EMS system).
Regarding Claim 161, Moore/Roberts teaches the limitations of Claim 161 which state
identify a location corresponding to the position on the interactive graphical map; and display the identified location in the at least one data entry field configured to automatically capture the item of EMS trip information based on the user selected position on the interactive graphical map (Roberts: Para 0025, 0040 via Furthermore, the MDT 14 may include a global positioning satellite ("GPS") module 22 interfaced to the processor 20 for gathering and relaying location information via one or more satellites 26. Moreover, vehicle information associated with the MDT 14 may be stored within the memory 21. Vehicle information can include any of a variety of performance, diagnostic, and status information and is useful in creating real time communication. The GPS module 22 provides location information of the vehicle (and the items and packages) and directions to the driver of the transportation vehicle as well as position, direction of travel and safety information to the dispatcher…Referring now to FIGS. 5A-5D, a dispatcher may view a detailed driver status screen 150 particular to a selected driver. The dispatcher may cause the detailed driver status screen 150 to appear on the graphical display by using a navigational menu or tab system. To view more detailed status information related to a selected driver, the dispatcher may click on the driver's name in a driver list 152 and a detailed itinerary in the form of a driver assignment list 120 may be displayed along with a map 153 showing the driver's current location 155, planned route 156, and all stops 158, among other information. Other information may also be displayed and be available to the dispatcher, such as previous stop information, planned stop information (i.e., stops in which a driver is scheduled), unplanned stop information (i.e., stops that a driver made that were not scheduled or dispatched), actual route information (i.e., the order in which a driver actually completed his or her stops), planned route information (i.e., the order of planned stops) unassigned stop information (i.e., pickup requests that have not yet been assigned), and a display of the location of the terminal).
Regarding Claim 162, Moore/Roberts teaches the limitations of Claim 162 which state
the at least one data entry field is a patient transport location comprising a patient drop-off location for the EMS trip or a patient pick-up location for the EMS trip; and the processor-readable instructions are configured to cause the at least one processor to provide a transport location icon on the interactive graphical map at a map location corresponding to a geographic location of the patient transport location, and automatically populate the at least one data entry field with the patient transport location based on a user selection of the transport location icon (Roberts: Para 0043-0044, 0161, 0040 via The list of assignments comprises a plurality of individual assignments 125 displaying assignment information associated therewith. An assignment may be a pickup assignment, a delivery assignment, or other types of assignments or tasks. The type of assignment may be designated by assignment type icon 129 to indicate whether the assignment is a pickup ("P") or a delivery ("D"), for example. For each pickup assignment, the dispatcher may view the customer (i.e., shipper) name, shipper address, the geographic area the shipper is assigned to (e.g., a driver's area that he or she services), the earliest pickup time, the latest pickup time, the expected number of handling units, the expected total weight, any shipping notes regarding the shipper or pickup, any special instructions, the assignment status, and the dispatch status. It should be understood that more or less of the above-information may be displayed regarding pickup assignments. In one embodiment, the special instructions may be viewed by clicking a special instructions icon 134 that causes a pop-up message 121 (see FIG. 3) to appear that lists the special instructions associated with the pickup assignment 125. Special instructions may include, but are not limited to, inside pickup service, residential pickup service, guaranteed service, lift gate required, cash on delivery, and rollup required… FIG. 8 illustrates a map view 320 having a pickup request icon 330 and closest drivers icons 322a-i indicating drivers that could service the request. The driver icons 322 indicate a direction of the driver's travel. Stops/assignments that have been dispatched to the driver may be shown as a stop icon having a first color (e.g., icons 324a and 324b). Any stops that are assigned to the driver but not yet dispatched may be shown as a stop icon having a second color (e.g., icon 324c). Stop icons may also be color or format coded to indicate stops that have not been assigned. The direction of travel may also be displayed as red directional line segments (e.g., line segment and arrow 321). Hover messages 326a and 326b may also be provided when the dispatcher moves a mouse pointer over a stop/assignment. The hover messages 326a and 326b may display additional information regarding the details of the particular stop/assignment. The displayed information may allow the dispatcher to quickly assess the impact of adding an additional assignment/stop to the driver's current route. FIGS. 9 and 10 illustrate a terminal view map 340 that enables the dispatcher to easily view all of the drivers 322 associated with a specific terminal 332 or within a specific dispatch area… Referring now to FIGS. 5A-5D, a dispatcher may view a detailed driver status screen 150 particular to a selected driver. The dispatcher may cause the detailed driver status screen 150 to appear on the graphical display by using a navigational menu or tab system. To view more detailed status information related to a selected driver, the dispatcher may click on the driver's name in a driver list 152 and a detailed itinerary in the form of a driver assignment list 120 may be displayed along with a map 153 showing the driver's current location 155, planned route 156, and all stops 158, among other information. Other information may also be displayed and be available to the dispatcher, such as previous stop information, planned stop information (i.e., stops in which a driver is scheduled), unplanned stop information (i.e., stops that a driver made that were not scheduled or dispatched), actual route information (i.e., the order in which a driver actually completed his or her stops), planned route information (i.e., the order of planned stops) unassigned stop information (i.e., pickup requests that have not yet been assigned), and a display of the location of the terminal).
Regarding Claim 163, Moore/Roberts teaches the limitations of Claim 163 which state
accept a repositioning of the transport location icon at the interactive graphical map; and update the at least one data entry field to correspond with the repositioning (Roberts: Para 0027, 0046, 0161 via The driver visibility module 31 is a program residing in the dispatch computer 18 or otherwise accessible to a dispatcher of a fleet of vehicles. The module 31 enables the intelligent wireless dispatch system 10 to provide a real-time view of the entire fleet that enables the dispatcher to quickly make dispatching decisions. The intelligent wireless dispatch system 10 enables a dispatcher to wirelessly dispatch assignments to drivers of the fleet with a click of a mouse as well as revise existing assignments dynamically, among other functionalities, as described herein… To ensure that the dispatcher is viewing current information, the system automatically refreshes the status information. In one embodiment, all of the information provided to the dispatcher is automatically refreshed in real time. In another embodiment, the information provided to the dispatcher is refreshed in different intervals to minimize server load and data transmission overhead. For example, in one embodiment, the driver stack 110 updates every sixty seconds. This ensures that the dispatcher has the necessary information to manage in accordance with the exceptions. The exception information contained in the hover messages is retrieved and updated in real-time. In the event that the driver icon has not updated, the real-time hover message ensures that the dispatcher is working with current information. In this exemplary embodiment, the detailed driver status screen 150 and integrated map 153 update every there minutes. Given that the dispatcher is likely going to be switching between drivers to resolve exceptions and dispatch tasks on a frequent basis, the three minute interval provides a good tradeoff while increasing system performance… FIG. 8 illustrates a map view 320 having a pickup request icon 330 and closest drivers icons 322a-i indicating drivers that could service the request. The driver icons 322 indicate a direction of the driver's travel. Stops/assignments that have been dispatched to the driver may be shown as a stop icon having a first color (e.g., icons 324a and 324b). Any stops that are assigned to the driver but not yet dispatched may be shown as a stop icon having a second color (e.g., icon 324c). Stop icons may also be color or format coded to indicate stops that have not been assigned. The direction of travel may also be displayed as red directional line segments (e.g., line segment and arrow 321). Hover messages 326a and 326b may also be provided when the dispatcher moves a mouse pointer over a stop/assignment. The hover messages 326a and 326b may display additional information regarding the details of the particular stop/assignment. The displayed information may allow the dispatcher to quickly assess the impact of adding an additional assignment/stop to the driver's current route).
Regarding Claim 165, Moore/Roberts teaches the limitations of Claim 165 which state
provide a plurality of icons representing agency resource locations on the interactive graphical map; and display agency resource information at the dispatch GUI for a particular location in response to a user selection of a respective icon of the plurality of icons, wherein the respective icon is provided at the particular location (Moore: Para 0035 via FIG. 8 shows an exemplary user interface of the dispatch module 110 for showing a representation of scheduled, completed, active and unpublished dispatches of EMS. The user interface of the dispatch module 110 can also provide a representation of the type of EMS dispatched, as well as a representation of current EMS activity. FIG. 9 shows another exemplary user interface of the dispatch module 110 that provides a graphical representation of the current EMS activity in real-time. In the example shown in FIG. 9, a map is generated, and icons of each active EMS activity is represented on the map, with an ability to provide a user further detail for each EMS activity represented on the user interface).
Regarding Claim 166, Moore/Roberts teaches the limitations of Claim 166 which state
access at least one post location for the EMS agency; and provide at least one post location icon on the interactive graphical map at the at least one post location (Roberts: Para 0040-0041 via Referring now to FIGS. 5A-5D, a dispatcher may view a detailed driver status screen 150 particular to a selected driver. The dispatcher may cause the detailed driver status screen 150 to appear on the graphical display by using a navigational menu or tab system. To view more detailed status information related to a selected driver, the dispatcher may click on the driver's name in a driver list 152 and a detailed itinerary in the form of a driver assignment list 120 may be displayed along with a map 153 showing the driver's current location 155, planned route 156, and all stops 158, among other information. Other information may also be displayed and be available to the dispatcher, such as previous stop information, planned stop information (i.e., stops in which a driver is scheduled), unplanned stop information (i.e., stops that a driver made that were not scheduled or dispatched), actual route information (i.e., the order in which a driver actually completed his or her stops), planned route information (i.e., the order of planned stops) unassigned stop information (i.e., pickup requests that have not yet been assigned), and a display of the location of the terminal. The integrated map 153 may be displayed as a street view, an aerial view, or a combination of both. FIG. 5A illustrates a combination street and aerial view map while FIG. 5B illustrates a street view map. Upon display, the map 153 may be automatically sized to fit all stops 158 on the screen. This may minimize the need for the dispatcher to perform map manipulations to obtain a usable view. Stops, which may comprise assignments dispatched by the dispatcher, are indicated as a stop icon 158 on the map 153 and may be coded (e.g., color, format or shape coded) to indicate if the stop was scheduled or unscheduled).
Regarding Claim 168, Moore/Roberts teaches the limitations of Claim 168 which state
wherein the processor-readable instructions are configured to cause the at least one processor to automatically capture the item of EMS trip information based on a user selection of at least one post location icon (Roberts: Para 0040-0041 via Referring now to FIGS. 5A-5D, a dispatcher may view a detailed driver status screen 150 particular to a selected driver. The dispatcher may cause the detailed driver status screen 150 to appear on the graphical display by using a navigational menu or tab system. To view more detailed status information related to a selected driver, the dispatcher may click on the driver's name in a driver list 152 and a detailed itinerary in the form of a driver assignment list 120 may be displayed along with a map 153 showing the driver's current location 155, planned route 156, and all stops 158, among other information. Other information may also be displayed and be available to the dispatcher, such as previous stop information, planned stop information (i.e., stops in which a driver is scheduled), unplanned stop information (i.e., stops that a driver made that were not scheduled or dispatched), actual route information (i.e., the order in which a driver actually completed his or her stops), planned route information (i.e., the order of planned stops) unassigned stop information (i.e., pickup requests that have not yet been assigned), and a display of the location of the terminal. The integrated map 153 may be displayed as a street view, an aerial view, or a combination of both. FIG. 5A illustrates a combination street and aerial view map while FIG. 5B illustrates a street view map. Upon display, the map 153 may be automatically sized to fit all stops 158 on the screen. This may minimize the need for the dispatcher to perform map manipulations to obtain a usable view. Stops, which may comprise assignments dispatched by the dispatcher, are indicated as a stop icon 158 on the map 153 and may be coded (e.g., color, format or shape coded) to indicate if the stop was scheduled or unscheduled).
Regarding Claim 169, Moore/Roberts teaches the limitations of Claim 169 which state
provide a set of individual EMS vehicle icons at the interactive graphical map based on the real-time EMS vehicle location tracking information, each EMS vehicle icon representing a respective EMS vehicle for the EMS agency; and automatically capture the item of EMS trip information based on a user selection of at least EMS vehicle icon (Roberts: Para 0161, 0040-0041 via FIG. 8 illustrates a map view 320 having a pickup request icon 330 and closest drivers icons 322a-i indicating drivers that could service the request. The driver icons 322 indicate a direction of the driver's travel. Stops/assignments that have been dispatched to the driver may be shown as a stop icon having a first color (e.g., icons 324a and 324b). Any stops that are assigned to the driver but not yet dispatched may be shown as a stop icon having a second color (e.g., icon 324c). Stop icons may also be color or format coded to indicate stops that have not been assigned. The direction of travel may also be displayed as red directional line segments (e.g., line segment and arrow 321). Hover messages 326a and 326b may also be provided when the dispatcher moves a mouse pointer over a stop/assignment. The hover messages 326a and 326b may display additional information regarding the details of the particular stop/assignment. The displayed information may allow the dispatcher to quickly assess the impact of adding an additional assignment/stop to the driver's current route. FIGS. 9 and 10 illustrate a terminal view map 340 that enables the dispatcher to easily view all of the drivers 322 associated with a specific terminal 332 or within a specific dispatch area… Referring now to FIGS. 5A-5D, a dispatcher may view a detailed driver status screen 150 particular to a selected driver. The dispatcher may cause the detailed driver status screen 150 to appear on the graphical display by using a navigational menu or tab system. To view more detailed status information related to a selected driver, the dispatcher may click on the driver's name in a driver list 152 and a detailed itinerary in the form of a driver assignment list 120 may be displayed along with a map 153 showing the driver's current location 155, planned route 156, and all stops 158, among other information. Other information may also be displayed and be available to the dispatcher, such as previous stop information, planned stop information (i.e., stops in which a driver is scheduled), unplanned stop information (i.e., stops that a driver made that were not scheduled or dispatched), actual route information (i.e., the order in which a driver actually completed his or her stops), planned route information (i.e., the order of planned stops) unassigned stop information (i.e., pickup requests that have not yet been assigned), and a display of the location of the terminal. The integrated map 153 may be displayed as a street view, an aerial view, or a combination of both. FIG. 5A illustrates a combination street and aerial view map while FIG. 5B illustrates a street view map. Upon display, the map 153 may be automatically sized to fit all stops 158 on the screen. This may minimize the need for the dispatcher to perform map manipulations to obtain a usable view. Stops, which may comprise assignments dispatched by the dispatcher, are indicated as a stop icon 158 on the map 153 and may be coded (e.g., color, format or shape coded) to indicate if the stop was scheduled or unscheduled).
Regarding Claim 170, Moore/Roberts teaches the limitations of Claim 170 which state
the plurality of icons comprises at least one post location icon and at least one individual EMS vehicle location icon; and the processor-readable instructions are configured to cause the at least one processor to: provide the at least one post location icon with a first shape and a first color; and provide the at least one individual EMS vehicle location icon with a second shape and a second color, wherein the second shape is different from the first shape or the second color is different from the first color or a combination thereof (Roberts: Para 0034, 0041 via Driver icons having a first color (i.e., a first format) such as green, for example, and may appear third in the driver stack 110 (e.g., green driver icon 113). Driver icons corresponding to a driver status having exceptions that may impact driver productivity and/or dispatcher visibility (e.g., the ability of the dispatcher to monitor a driver's progress) may be coded a third color (i.e., a third format), such as yellow, for example, and appear second in the driver stack 110 (e.g., yellow driver icon 114). Driver icons corresponding to a driver status having exceptions that may potentially impact customer service levels (e.g., the dispatch exceptions described above) may be coded a second color such as red (i.e., a second color), for example, and appear first in the driver stack 110 (e.g., red driver icon 112). Finally, driver icons corresponding to a driver status indicating an inactive driver (e.g., a driver that has not logged into or has not attempted to log into the system) may be coded a fourth format (e.g., gray icon 115), for example, and may appear at the bottom of the driver stack 110 so as to not distract the dispatcher… The integrated map 153 may be displayed as a street view, an aerial view, or a combination of both. FIG. 5A illustrates a combination street and aerial view map while FIG. 5B illustrates a street view map. Upon display, the map 153 may be automatically sized to fit all stops 158 on the screen. This may minimize the need for the dispatcher to perform map manipulations to obtain a usable view. Stops, which may comprise assignments dispatched by the dispatcher, are indicated as a stop icon 158 on the map 153 and may be coded (e.g., color, format or shape coded) to indicate if the stop was scheduled or unscheduled).
Regarding Claim 171, Moore/Roberts teaches the limitations of Claim 171 which state
wherein the processor-readable instructions are configured to cause the at least one processor to display one or more of crew information or vehicle information in response to a user selection of a particular icon of the plurality of icons (Roberts: Para 0040 via Referring now to FIGS. 5A-5D, a dispatcher may view a detailed driver status screen 150 particular to a selected driver. The dispatcher may cause the detailed driver status screen 150 to appear on the graphical display by using a navigational menu or tab system. To view more detailed status information related to a selected driver, the dispatcher may click on the driver's name in a driver list 152 and a detailed itinerary in the form of a driver assignment list 120 may be displayed along with a map 153 showing the driver's current location 155, planned route 156, and all stops 158, among other information. Other information may also be displayed and be available to the dispatcher, such as previous stop information, planned stop information (i.e., stops in which a driver is scheduled), unplanned stop information (i.e., stops that a driver made that were not scheduled or dispatched), actual route information (i.e., the order in which a driver actually completed his or her stops), planned route information (i.e., the order of planned stops) unassigned stop information (i.e., pickup requests that have not yet been assigned), and a display of the location of the terminal).
Regarding Claim 172, Moore/Roberts teaches the limitations of Claim 172 which state
wherein the vehicle information comprises a connectivity status representing one of availability of communications with the mobile computing device associated with the EMS agency vehicle or unavailability of communications with the mobile computing device associated with the EMS agency vehicle, wherein the EMS agency vehicle corresponds to the particular icon (Roberts: Para 0030, 0035-0036 via Dispatch exceptions may include the situation where a dispatcher has sent an assignment transmission to the MDT of a particular driver and a transmission error occurs where the assignment cannot be transmitted to the MDT within a prescribed period of time, such as ten minutes for example. A dispatch exception may also be generated when a driver declines an assignment for a particular reason, such as when the driver believes that he or she does not have enough time to complete the assignment, or the driver believes that his or her current trailer load prevents him or her from handling the assignment. Another situation in which a dispatch exception may be generated includes where the driver does not acknowledge a successfully transmitted assignment within a prescribed period of time. Dispatch exceptions are typically severe enough to affect customer service and are displayed prominently so that the dispatcher is aware of the various dispatch exceptions for each driver in the driver stack 110, as described in more detail below… The intelligent wireless dispatch system is updated in real-time or close to real-time such that when a driver status changes for a particular driver, the associated driver icon 111 quickly changes color and the driver's name is rearranged within the driver stack 110. For example, if a driver's current driver icon indicates a green status and the driver declines an assignment that was wirelessly transmitted to the driver's MDT, the driver icon will change to red and the driver's name will move up within the driver stack 110 such that the driver's name is the last driver listed within the list of drivers having red driver icons. More detailed color coding rules for the driver icons are illustrated in the chart of FIG. 4. As an example, a green driver icon may be provided next to a driver who is not stopped, does not have a dispatch exception and whose GPS signal is being successfully received. A green driver icon may also be present if the mobile data terminal of an associated driver does not have GPS capability. A yellow driver icon may be provided when a driver has either stopped for longer than a prescribed time (e.g., thirty minutes), or a GPS signal has not been received by the dispatch computer in more than a prescribed time (e.g., thirty minutes). A red driver icon may be provided when a dispatch exception occurs).
Regarding Claim 173, Moore/Roberts teaches the limitations of Claim 173 which state
wherein the processor-readable instructions are configured to cause the at least one processor to provide filter options for the interactive graphical map that enable a user to filter display of the plurality of icons to a particular type of EMS vehicle (Roberts: Para 0042, 0051 via Referring specifically to FIG. 5C, the driver assignment list 120 provides information that a dispatcher may need in performing his or her dispatching duties. The driver assignment list 120 provides a list of assignments 125 as well as additional information in area 122 such as driver name, tractor number, trailer number, and current available trailer capacity. Other information that may be displayed in the driver status screen 150 includes, but is not limited to, a tractor (vehicle) number, MDT ID number, trailer number(s), current available trailer capacity, driver schedule, logged in status and time 123, driver type (e.g., pick-up and delivery drivers, team drivers, driver license type, etc.), a time that the driver left the terminal and a start/stop time of the driver's shift. The detailed driver status screen 150 also enables a dispatcher to quickly view the occurrence of events such as when a driver clocks or logs in, when a driver clocks or logs out, when a vehicle has been powered off, when a trailer is hooked to a vehicle, when a driver departs from a terminal, when a driver arrives at a terminal, a planned stop and associated start and stop time, an unplanned stop and associated start and stop time, when a shipment has been delivered to a customer, when a shipment has been picked up from a customer, when a document has been scanned (e.g., a bill of lading), when a state boarder has been crossed, a slip point (i.e., a driver meeting location in a long route) arrival, a slip point departure, when a driver has been cleared by the dispatcher (e.g., when a dispatcher has verified that a driver has completed his or her assigned pick-up and deliveries), when fuel disbursement has occurred, and when a trailer has been unhooked, among others… Exemplary filtering rules for filtering the information contained in the transmission status message may include, but are not limited to: [0052] Show all Dispatch Actions (e.g., DISPATCH, UPDATED, CANCELLED); [0053] Show all Driver Declines with a reason (e.g., DECLINED: LOAD, DECLINED: TIME); [0054] Show the most recent transmission received by the MDT (XMIT); [0055] Show any previous transmission received by the MDT (XMIT) where a driver response was not received; [0056] Show NO DRIVER RESPONSE for any transmission received by an MDT (XMIT) where a driver response was not received; [0057] Show PENDING DRIVER for any transmissions that have been received by the MDT and are pending a driver response; and [0058] Show PENDING XMIT for any tasks where a dispatch/update/cancellation is pending transmission to the MDT).
Regarding Claim 189, Moore/Roberts teaches the limitations of Claim 189 which state
wherein: the at least one processor is configured to interoperate with an in-vehicle dispatch system provided in the cloud-based distributed processing architecture and configured to provide a navigation and dispatch application at the mobile computing device associated with the EMS agency vehicle; and Preliminary Amendment the dispatch GUI is configured to receive the trip acceptance from a user entry to the navigation and dispatch application and provide the EMS agency vehicle assignment to the navigation and dispatch application (Roberts: Para 0150-0151 via When the dispatcher transmits a new assignment to a driver, the intelligent wireless dispatch system 10 updates the display of the MDT with a new assignment screen 208 that contains information regarding a pickup or a delivery for driver review. For example, the new assignment screen may display whether the assignment is a pickup or a delivery, the name and address of the customer, the time of the assignment, and other information (e.g., whether the assignment is a cash on delivery ("COD") assignment, the number of handling units and the total weight of the freight to be picked up). Also provided on the new assignment screen 208 are large-sized driver input selections. In the illustrated embodiment, the driver input selections include Accept button 201, Decline:Time button 203 and Decline:Load button 205. The buttons are configured as a large size so that a driver may easily make a selection, even if he or she is wearing gloves. To accept a new assignment, the driver may press or otherwise select the Accept button 201, to wirelessly transmit a structured acceptance message from the MDT to the dispatch computer. In this manner, the driver does not need to type a message or verbally accept the new assignment to the dispatcher. Once the structured acceptance message is received at the dispatch computer, the intelligent wireless dispatch system 10 will update the driver stack 110 on the dispatcher's display and also update the driver task screen 206, which will be visible after the driver presses the Accept button 201 (see FIG. 6A)).
Claim(s) 164, 174-179 and 181 is/are rejected under 35 U.S.C. 103 as being unpatentable over Moore et al. (US 2016/0342740 A1) in view of Roberts, SR et al. (US 2013/0184035 A1) further in view of Brandt et al. (US 2017/0345114 A1).
Regarding Claim 164, while Moore/Roberts teaches the limitations of Claim 160, they do not teach the limitations of Claim 164 which state wherein the user selection of the position on the interactive graphical map causes the at least one processor to automatically capture the item of EMS trip information as global positioning satellite (GPS) coordinates for the position.
Brandt though, with the teachings of Moore/Roberts, teaches of
wherein the user selection of the position on the interactive graphical map causes the at least one processor to automatically capture the item of EMS trip information as global positioning satellite (GPS) coordinates for the position (Brandt: Para 0091, Fig 13 via For example by clicking on a vehicle, the user may view the medical transport being provided by that vehicle…Coordinate locations shown on map).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Moore/Roberts with the teachings of Brandt in order to have wherein the user selection of the position on the interactive graphical map causes the at least one processor to automatically capture the item of EMS trip information as global positioning satellite (GPS) coordinates for the position. The motivations behind this being to incorporate the teachings of coordinating vehicular transport of patients as taught by Brandt. Furthermore, in addition to being in the same CPC class, the teachings, suggestions, and motivations in this prior art would have led one of ordinary skill to modify the prior art reference or combine prior art reference teachings to arrive at the claimed invention.
Regarding Claim 174, while Moore/Roberts teaches the limitations of Claim 160, they do not teach the limitations of Claim 174 which state wherein the processor-readable instructions are configured to cause the at least one processor to display a log of the EMS trip, the log comprising a current status of an EMS agency vehicle corresponding to the EMS agency vehicle assignment, a time of the generation of the EMS agency vehicle assignment, and a time interval from the generation of the EMS agency vehicle assignment to a wheels rolling status.
Brandt though, with the teachings of Moore/Roberts, teaches of
wherein the processor-readable instructions are configured to cause the at least one processor to display a log of the EMS trip, the log comprising a current status of an EMS agency vehicle corresponding to the EMS agency vehicle assignment, a time of the generation of the EMS agency vehicle assignment, and a time interval from the generation of the EMS agency vehicle assignment to a wheels rolling status (Brandt: Para 0039 via Fleet control server 110 further comprises memory 230, which may store a variety of types of data for use by controller 220. These types of data may be stored for entire fleets of vehicles as desired. In this embodiment, memory 230 stores vehicle tracking data 232, such as a history of GPS coordinates, or route information (e.g., a route previously taken or yet to be taken). Vehicle tracking data 232 may further include Estimated Time of Arrival (ETA) information (e.g., a specific time of arrival) or an amount of time left before arrival is expected for various vehicles in the fleet that are performing medical transport. Vehicle tracking data 232 may be updated in real-time by crew device in each vehicle in order to provide continuous updates of position and/or status. For example, vehicle tracking data 232 may be updated at each stage of medical transport, such as when vehicle 170 is assigned/dispatched to provide medical transport, when vehicle 170 is en route to the pick up location, when vehicle 170 is at the pick up location, when vehicle 170 is transporting the patient, when vehicle 170 has arrived at the drop off location, and when vehicle 170 is available/clear to provide medical transport for other patients. In further embodiments, crew device 160 provides treatment information to fleet control server 110, indicating medical procedures performed on the patient during medical transport. This treatment information may be transmitted by reporting server 150 to an interested party via mobile device 120, or to provider network 180).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Moore/Roberts with the teachings of Brandt in order to have wherein the processor-readable instructions are configured to cause the at least one processor to display a log of the EMS trip, the log comprising a current status of an EMS agency vehicle corresponding to the EMS agency vehicle assignment, a time of the generation of the EMS agency vehicle assignment, and a time interval from the generation of the EMS agency vehicle assignment to a wheels rolling status. The motivations behind this being to incorporate the teachings of coordinating vehicular transport of patients as taught by Brandt. Furthermore, in addition to being in the same CPC class, the teachings, suggestions, and motivations in this prior art would have led one of ordinary skill to modify the prior art reference or combine prior art reference teachings to arrive at the claimed invention.
Regarding Claim 175, Moore/Roberts/Brandt teaches the limitations of Claim 175 which state
wherein the log comprises one or more of a time or time interval from the generation of the EMS agency vehicle assignment for an en route status, an at-scene status, a transporting status, or an at-destination status (Brandt: Para 0039 via Fleet control server 110 further comprises memory 230, which may store a variety of types of data for use by controller 220. These types of data may be stored for entire fleets of vehicles as desired. In this embodiment, memory 230 stores vehicle tracking data 232, such as a history of GPS coordinates, or route information (e.g., a route previously taken or yet to be taken). Vehicle tracking data 232 may further include Estimated Time of Arrival (ETA) information (e.g., a specific time of arrival) or an amount of time left before arrival is expected for various vehicles in the fleet that are performing medical transport. Vehicle tracking data 232 may be updated in real-time by crew device in each vehicle in order to provide continuous updates of position and/or status. For example, vehicle tracking data 232 may be updated at each stage of medical transport, such as when vehicle 170 is assigned/dispatched to provide medical transport, when vehicle 170 is en route to the pick up location, when vehicle 170 is at the pick up location, when vehicle 170 is transporting the patient, when vehicle 170 has arrived at the drop off location, and when vehicle 170 is available/clear to provide medical transport for other patients. In further embodiments, crew device 160 provides treatment information to fleet control server 110, indicating medical procedures performed on the patient during medical transport. This treatment information may be transmitted by reporting server 150 to an interested party via mobile device 120, or to provider network 180).
Regarding Claim 176, Moore/Roberts/Brandt teaches the limitations of Claim 176 which state
wherein the log of the EMS trip comprises a time for a pre-scheduled patient transport (Brandt: Para 0039-0040 via Fleet control server 110 further comprises memory 230, which may store a variety of types of data for use by controller 220. These types of data may be stored for entire fleets of vehicles as desired. In this embodiment, memory 230 stores vehicle tracking data 232, such as a history of GPS coordinates, or route information (e.g., a route previously taken or yet to be taken). Vehicle tracking data 232 may further include Estimated Time of Arrival (ETA) information (e.g., a specific time of arrival) or an amount of time left before arrival is expected for various vehicles in the fleet that are performing medical transport. Vehicle tracking data 232 may be updated in real-time by crew device in each vehicle in order to provide continuous updates of position and/or status. For example, vehicle tracking data 232 may be updated at each stage of medical transport, such as when vehicle 170 is assigned/dispatched to provide medical transport, when vehicle 170 is en route to the pick up location, when vehicle 170 is at the pick up location, when vehicle 170 is transporting the patient, when vehicle 170 has arrived at the drop off location, and when vehicle 170 is available/clear to provide medical transport for other patients. In further embodiments, crew device 160 provides treatment information to fleet control server 110, indicating medical procedures performed on the patient during medical transport. This treatment information may be transmitted by reporting server 150 to an interested party via mobile device 120, or to provider network 180. Memory 230 further stores request tracking data 234. Request tracking data 234 may indicate which vehicles have been assigned to perform medical transport based on different requests, the nature of each request, whether a request has been completed (e.g., by the delivery of a patient to a drop off location indicated in the request), a time at which each stage of medical transport was completed for the request, whether a request is presently queued and awaiting assignment of a vehicle, etc.).
Regarding Claim 177, Moore/Roberts/Brandt teaches the limitations of Claim 177 which state
wherein the log of the EMS trip comprises one or more of a vehicle identification number, a vehicle service level, crew member identification, contact information for a requester of the EMS services, or a connectivity status representing communications availability or unavailability between the mobile computing device and the cloud-based CAD system (Brandt: Para 0041 via Still further, memory 230 includes crew data 236. Crew data 236 indicates the efficacy of the crew of the vehicles in the fleet. For example crew data 236 may include survey results for each crew member within a vehicle, such as whether a given crew member is consistently late or on time, whether individual crew members interact positively with each other or staff at medical facilities, which medical qualifications and/or certifications each crew member has, etc.).
Regarding Claim 178, Moore/Roberts/Brandt teaches the limitations of Claim 178 which state
the at least one processor is configured to interoperate with an in-vehicle dispatch system provided in the cloud-based distributed processing architecture and configured to provide a navigation and dispatch application at the mobile computing device associated with the EMS agency vehicle; and the connectivity status registers unavailability between the mobile computing device and the cloud-based CAD system prior to a crew member of the EMS agency vehicle logging into the navigation and dispatch application (Roberts: Para 0146-0148 via When a driver logs onto the MDT using her or her employee identification number, the intelligent wireless dispatch system retrieves the driver information associated with the transmitted employee identification number (e.g., first and last name). If the driver enters an incorrect employee identification number, the MDT may display an invalid employee number screen message box 229 that prompts the driver to press an OK button 213 to try to login again. If the driver enters a valid employee identification number, an identification verification screen or message box 228 for the driver to confirm his or her identity. If the name displayed in the identification verification message box 228 matches the name of the driver, the driver may press the OK button 213 to advance to a driver task screen 206 described below. In one embodiment, enhanced login functionality is provided. When a valid employee number is entered and transmitted, the system then retrieves the vehicle number of the vehicle that the MDT is physically installed (MDT vehicle number) and the vehicle number of the vehicle that the driver was previously dispatched (dispatched vehicle number). If the two vehicle numbers match (i.e., the driver is logging into the system with an MDT that is in the same vehicle that he or she was dispatched in), the driver's login is approved and the driver may receive his or her assignments in the driver task screen 206. If the two vehicle numbers do not match, the login attempt is flagged as a Pending Login Request for the dispatcher to either approve or disapprove. FIG. 6B illustrates a Driver Status screen 150 in which a driver has a Login Exception because the number of the tractor (vehicle) associated with the MDT that he logged into does not match the number of the tractor that he was previously dispatched with. When the dispatcher hovers the mouse over the driver icon 114 indicating the login exception, a pop-up message 116e may appear that provides information regarding the time of the login exception. Pending Login message box 132 may also appear. The Pending Login message box 132 includes the number of the dispatched tractor 133 (the vehicle number of the vehicle that the driver was dispatched) and the actual tractor number 131 (the number of the vehicle having the MDT that the driver login with). The dispatcher may indicate that the login information is correct by selecting the OK button 137. If the login information is incorrect, the dispatcher may deny the login request by selecting the deny button 136…).
Regarding Claim 179, Moore/Roberts/Brandt teaches the limitations of Claim 179 which state
wherein the log of the EMS trip comprises a time stamp control, a cancel trip control, an unassign trip control, an add trip control, a return trip control, and an add leg control (Roberts: Para 0042, 0143, 0161 via Referring specifically to FIG. 5C, the driver assignment list 120 provides information that a dispatcher may need in performing his or her dispatching duties. The driver assignment list 120 provides a list of assignments 125 as well as additional information in area 122 such as driver name, tractor number, trailer number, and current available trailer capacity. Other information that may be displayed in the driver status screen 150 includes, but is not limited to, a tractor (vehicle) number, MDT ID number, trailer number(s), current available trailer capacity, driver schedule, logged in status and time 123, driver type (e.g., pick-up and delivery drivers, team drivers, driver license type, etc.), a time that the driver left the terminal and a start/stop time of the driver's shift. The detailed driver status screen 150 also enables a dispatcher to quickly view the occurrence of events such as when a driver clocks or logs in, when a driver clocks or logs out… To make dispatchers as efficient as possible, the intelligent wireless dispatch system 10 employs context sensitive right click menus. Referring to FIG. 5D, common tasks for a dispatcher may include reassigning a previously dispatched task as well as re-transmitting tasks. Both of these options may be available as right click menu options 116d within the intelligent wireless dispatch system 10. Referring to FIG. 5C, the dispatcher may right click on a task to generate a right click menu 116d that may provide one or more menu options. As an example, if a dispatcher desires to reassign a task from a first driver to a second driver, he or she may select the "Assign to Another driver" menu option after right clicking on the assigned task. A dialog box 160 appears allowing the dispatcher to enter/select the driver in a textbox 162. The system may provide driver selection suggestions based on the letters that the dispatcher types into the textbox 162 to increase efficiency. In some cases, such as when the task is several hours in the future, the dispatcher may not want to yet dispatch the assignment to the driver but rather show as planned. The dialog gives the dispatcher the option of just assigning or assigning and dispatching the pickup assignment. For example, the dispatcher may assign and dispatch the pickup by pressing the assign and dispatch button 164 or just assign the task by pressing the assignment button 166 to show the task as planned… FIG. 8 illustrates a map view 320 having a pickup request icon 330 and closest drivers icons 322a-i indicating drivers that could service the request. The driver icons 322 indicate a direction of the driver's travel. Stops/assignments that have been dispatched to the driver may be shown as a stop icon having a first color (e.g., icons 324a and 324b). Any stops that are assigned to the driver but not yet dispatched may be shown as a stop icon having a second color (e.g., icon 324c). Stop icons may also be color or format coded to indicate stops that have not been assigned. The direction of travel may also be displayed as red directional line segments (e.g., line segment and arrow 321). Hover messages 326a and 326b may also be provided when the dispatcher moves a mouse pointer over a stop/assignment. The hover messages 326a and 326b may display additional information regarding the details of the particular stop/assignment. The displayed information may allow the dispatcher to quickly assess the impact of adding an additional assignment/stop to the driver's current route).
Regarding Claim 181, Moore/Roberts/Brandt teaches the limitations of Claim 181 which state
wherein the processor-readable instructions are configured to cause the at least one processor to display the log of the EMS trip in a scrollable window (Roberts: Para 0040 via Referring now to FIGS. 5A-5D, a dispatcher may view a detailed driver status screen 150 particular to a selected driver. The dispatcher may cause the detailed driver status screen 150 to appear on the graphical display by using a navigational menu or tab system. To view more detailed status information related to a selected driver, the dispatcher may click on the driver's name in a driver list 152 and a detailed itinerary in the form of a driver assignment list 120 may be displayed along with a map 153 showing the driver's current location 155, planned route 156, and all stops 158, among other information. Other information may also be displayed and be available to the dispatcher, such as previous stop information, planned stop information (i.e., stops in which a driver is scheduled), unplanned stop information (i.e., stops that a driver made that were not scheduled or dispatched), actual route information (i.e., the order in which a driver actually completed his or her stops), planned route information (i.e., the order of planned stops) unassigned stop information (i.e., pickup requests that have not yet been assigned), and a display of the location of the terminal).
Claim(s) 167 is/are rejected under 35 U.S.C. 103 as being unpatentable over Moore et al. (US 2016/0342740 A1) in view of Roberts, SR et al. (US 2013/0184035 A1) further in view of Zhu et al. (US 2012/0290148 A1).
Regarding Claim 167, while Moore/Roberts teaches the limitations of Claim 166, it does not explicitly disclose the limitations of Claim 167 which state wherein the at least one post location icon indicates a quantity of vehicles currently located at the at least one post location.
Zhu though, with the teachings of Moore/Roberts, teaches of
wherein the at least one post location icon indicates a quantity of vehicles currently located at the at least one post location (Zhu: Para 0037, 0039 via FIG. 2 shows a schematic view for an embodiment of a virtual line schedule map according to an embodiment of the present invention. The virtual line schedule map in such embodiment comprises a line table, a temporary mission box, a parking box and a maintenance box. The line table is composed of multiple independent lines, each of which comprises an initial point box, a terminal point box, an up-line, a down-line, line description, initial point and terminal point descriptions and vehicle icons. Wherein, each vehicle icon corresponds to a specific encoded vehicle. The initial point box and the terminal point box are in the shape of rectangle or rounded rectangle. The up-line is connected to the terminal point box on the top right corner and to the initial point box on the top left corner respectively, and its direction is from the initial point box to the terminal point box. The down-line is connected to the terminal point box on the lower right corner and to the initial point box on the lower left corner respectively, and its direction is from the terminal point box to the initial point box. The line description located at the middle of the line between the up-line and the down-line comprises a line name, the number of vehicles in respective vehicle states and the total number of vehicles…As shown in FIG. 2, the number of the vehicles in respective vehicle states in each line and the total number of vehicles are both shown between the up-line and the down-line of such line).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Moore/Roberts with the teachings of Zhu in order to have wherein the at least one post location icon indicates a quantity of vehicles currently located at the at least one post location. The motivations behind this being to incorporate the teachings of dispatching vehicles and realizing the visual vehicle dispatching by utilizing a virtual line schedule map. Furthermore, in addition to being in the same CPC class, the teachings, suggestions, and motivations in this prior art would have led one of ordinary skill to modify the prior art reference or combine prior art reference teachings to arrive at the claimed invention.
Claim(s) 180 is/are rejected under 35 U.S.C. 103 as being unpatentable over Moore et al. (US 2016/0342740 A1) in view of Roberts, SR et al. (US 2013/0184035 A1) in view of Brandt et al. (US 2017/0345114 A1) further in view of Gotschall et al. (US 10,598,508 B2).
Regarding Claim 180, while Moore/Roberts/Brandt teaches the limitations of Claim 179, it does not explicitly disclose the limitations of Claim 180 which state wherein the time stamp control, upon selection, is configured to enable a user to enter a custom time stamp comprising a clock time and a text label, wherein the text label represents an action, status, or activity corresponding to the clock time.
Gotschall though, with the teachings of Moore/Roberts/Brandt, teaches of
wherein the time stamp control, upon selection, is configured to enable a user to enter a custom time stamp comprising a clock time and a text label, wherein the text label represents an action, status, or activity corresponding to the clock time (Gotschall: Col 8 lines 23-53 via From the home menu 406, selecting the Response button takes the user to easy response screen 418, which is illustrated at FIG. 12. Screen 418 displays a map with a route to the target destination, including address and directions. This screen 418 allows for setting time stamps for the incident, viewing alerts, viewing notes, and/or toggling the map view (for example between zooming to the destination location, viewing the entire route, and following the vehicle on the map), according to embodiments of the present invention. According to some embodiments of the present invention, the toggle button used to toggle between views is in the same location with respect to the display screen device in each of the two or three or more views, to facilitate easy and rapid toggling and/or cycling between the various kinds of views, without having to locate and select a different button for each view. Selecting the Next button from screen 418 takes the user to a second easy response screen 420, as illustrated in FIG. 13, which displays a second set of commands available on the easy response screen. These additional commands include switching to the dispatch screen 408 to view the incident details (Incident Details button), closing a road on the map, viewing a list of road closures, and/or routing to a custom address, according to embodiments of the present invention. Selecting the Next button from screen 420 takes the user to a third easy response screen 422, illustrated at FIG. 14, which displays a third set of commands including specifying which map layers to display on the map (Map Layers button), toggling traffic overlay on the map (Show Traffic button), and toggling weather overlay on the map (Show Weather button), according to embodiments of the present invention).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Moore/Roberts/Brandt, with the teachings of Gotschall in order to have wherein the time stamp control, upon selection, is configured to enable a user to enter a custom time stamp comprising a clock time and a text label, wherein the text label represents an action, status, or activity corresponding to the clock time. The motivation behind this being to incorporate the teachings of a user interface system for EMS navigation systems as taught by Gotschall. Furthermore, in addition to being in the same CPC class, the teachings, suggestions, and motivations in this prior art would have led one of ordinary skill to modify the prior art reference or combine prior art reference teachings to arrive at the claimed invention.
Claim(s) 182-187 is/are rejected under 35 U.S.C. 103 as being unpatentable over Moore et al. (US 2016/0342740 A1) in view of Roberts, SR et al. (US 2013/0184035 A1) in view of Subramanyam et al. (US 10,027,801 B1).
Regarding Claim 182, while Moore/Roberts teaches the limitations of Claim 160, it does not explicitly disclose the limitations of Claim 182 which state the EMS agency is a first EMS agency at a first geographic location; the dispatch GUI is a first dispatch GUI; the system comprises a database of EMS vehicles associated at least with the first EMS agency and a second EMS agency at a second geographic location; and the processor-readable instructions are configured to cause the at least one processor to identify an EMS vehicle associated with the second EMS agency that is available for the EMS trip based on at least one dispatch code, receive a patient location associated with the EMS trip, determine that the second geographic location is closer to the patient location than the first geographic location, transfer the pending EMS trip assignment from the first EMS agency to the second EMS agency, and provide a transfer notification for the EMS trip at a second dispatch GUI at a computing system located at the second EMS agency.
Subramanyam though, with the teachings of Moore/Roberts, teaches of
the EMS agency is a first EMS agency at a first geographic location; the dispatch GUI is a first dispatch GUI; the system comprises a database of EMS vehicles associated at least with the first EMS agency and a second EMS agency at a second geographic location; and the processor-readable instructions are configured to cause the at least one processor to identify an EMS vehicle associated with the second EMS agency that is available for the EMS trip based on at least one dispatch code, receive a patient location associated with the EMS trip, determine that the second geographic location is closer to the patient location than the first geographic location, transfer the pending EMS trip assignment from the first EMS agency to the second EMS agency, and provide a transfer notification for the EMS trip at a second dispatch GUI at a computing system located at the second EMS agency (Subramanyam: Col 8 line 50 – Col 12 line 20 via teaching inter-agency incident scene communications with a first dispatch service storing subscription information from a second agency and transferring incident information between agencies based on proximity and availability).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Moore/Roberts with the teachings of Subramanyam in order to have the EMS agency is a first EMS agency at a first geographic location; the dispatch GUI is a first dispatch GUI; the system comprises a database of EMS vehicles associated at least with the first EMS agency and a second EMS agency at a second geographic location; and the processor-readable instructions are configured to cause the at least one processor to identify an EMS vehicle associated with the second EMS agency that is available for the EMS trip based on at least one dispatch code, receive a patient location associated with the EMS trip, determine that the second geographic location is closer to the patient location than the first geographic location, transfer the pending EMS trip assignment from the first EMS agency to the second EMS agency, and provide a transfer notification for the EMS trip at a second dispatch GUI at a computing system located at the second EMS agency. The motivations behind this being to incorporate the teachings of controlling inter-agency, incident scene communications as taught by Subramanyam. Furthermore, in addition to being in the same CPC class, the teachings, suggestions, and motivations in this prior art would have led one of ordinary skill to modify the prior art reference or combine prior art reference teachings to arrive at the claimed invention.
Regarding Claim 183, Moore/Roberts/Subramanyam teaches the limitations of Claim 183 which state
wherein the transfer notification comprises an assignment of an EMS agency vehicle associated with the second EMS agency to the EMS trip (Subramanyam: Col 10 lines 22-42 via At block 515, the second electronic processor 305 identifies the second agency 130 based on the geo-fence surrounding the incident. In some embodiments, the second electronic processor 305 identifies the second agency 130 by recognizing communication devices 105 from the second agency 130 within or near the geo-fence. In some embodiments, the second electronic processor 305 identifies the second agency 130 based on known geographic areas patrolled by public safety personnel of the second agency 130. For example, the second electronic processor 305 may recognize that the geo-fence overlaps or is located near a neighboring city, county, or other geographic area patrolled by the public safety personnel of the second agency 130. At block 520, the first dispatch device 115 transmits, from the second network interface 315, a request to the second dispatch device 125 of the second agency 130 based on incident information relating to the incident and the subscription information of the second agency 130. In some embodiments, the request includes role information based on the incident information as described in greater detail below).
Regarding Claim 184, the combination of Moore/Roberts/Subramanyam teaches the limitations of Claim 184 which states
wherein the transfer notification comprises a request for the second EMS agency to allocate resources to the pending EMS trip assignment without an assignment of the EMS agency vehicle associated with the second EMS agency (Subramanyam: Col 10 line 5 – Col 11 line 26 via teaching of sending notifications to a second agency based on incident location without necessarily assigning specific resources).
Regarding Claim 185, the combination of Moore/Roberts/Subramanyam teaches the limitations of Claim 185 which states
wherein the database of EMS vehicles comprises stored permission information that enables the at least one processor to transfer the EMS trip from the first EMS agency to the second EMS agency (Subramanyam: Col 8 line 59 – Col 9 line 3 via At block 505, the second electronic processor 305 stores, in the second memory 310 of the first dispatch device 115, subscription information from the second agency 130. In some embodiments, the subscription information from the second agency 130 may be received from the second dispatch device 125 via the second network interface 315. In other embodiments, the subscription information may be manually entered into the first dispatch device 115. In some embodiments, the subscription information from the second agency 130 indicates an incident type and a severity level of an incident for which the second agency 130 is willing and able to provide additional assistance to the first agency 110).
Regarding Claim 186, the combination of Moore/Roberts/Subramanyam teaches the limitations of Claim 186 which states
wherein the stored permission information comprises data access guidelines that identify one or more types of EMS trip data that are exchangeable between the first EMS agency and the second EMS agency (Subramanyam: Col 7 lines 1-67 via teaching subscription information including information types that can be exchanged such as location information, experience information, and skill information between agencies. Data access guidelines for inter-agency information sharing are evident in multi-jurisdiction dispatch systems).
Regarding Claim 187, the combination of Moore/Roberts/Subramanyam teaches the limitations of Claim 187 which states
wherein a computing system located at the second EMS agency and the computing system located at the first EMS agency are separate uncoupled computing systems such that a data exchange between the first EMS agency and the second EMS agency only occurs via the cloud-based distributed processing architecture of the cloud-based CAD system (Subramanyam: Col 3 lines 10-36 via As indicated by FIG. 1, in some embodiments, the communication devices 105A and 105B are operated by members of a first agency 110 (for example, a public safety agency such as a police department, a fire department, and the like). The communication devices 105A and 105B may communicate with a first dispatch device 115 of the first agency 110 over a network 120. The communication devices 105A and 105B may also communicate with each other and with other devices (for example, devices outside the first agency 110) over the network 120. The network 120 may be a wired or a wireless communication network. All or parts of the network 120 may be implemented using various existing networks, for example, a cellular network, the Internet, a land mobile radio (LMR) network, a Bluetooth™ network, a wireless local area network (for example, Wi-Fi), a wireless accessory Personal Area Networks (PAN), a Machine-to-machine (M2M) autonomous network, and a public switched telephone network. The network 120 may also include future developed networks. In some embodiments, the network 120 may also include a combination of the networks mentioned. In some embodiments, the communication devices 105A and 105B may communicate directly with each other using a communication channel or connection that is outside of the network 120. For example, the plurality of communication devices 105A and 105B may communicate directly with each other when they are within a predetermined distance from each other).
Claim(s) 188 is/are rejected under 35 U.S.C. 103 as being unpatentable over Moore et al. (US 2016/0342740 A1) in view of Roberts, SR et al. (US 2013/0184035 A1) in view of Subramanyam et al. (US 10,027,801 B1) further in view of Liu (2019/0014195 A1).
Regarding Claim 188, while Moore/Roberts/Subramanyam teaches the limitations of Claim 182, it does not explicitly disclose the limitations of Claim 188 which state to convert EMS trip data from a first format or dispatch workflow associated with the first EMS agency to a second format or dispatch workflow associated with the second EMS agency.
Liu though, with the teachings of Moore/Roberts/Subramanyam, teaches of
to convert EMS trip data from a first format or dispatch workflow associated with the first EMS agency to a second format or dispatch workflow associated with the second EMS agency (Liu: Para 0040, 0048 via FIG. 1 is a schematic diagram of an application environment of a protocol format conversion method according to an embodiment. Referring to FIG. 1, the application environment comprises a dispatching console 110, an interface platform 120, a wireless communication system 130 and any access point 131 therein, a wireless communication system 140 and any access point 141 therein. It should be noted that it is not limited to one dispatching console and one access point in the embodiment, and it is merely for convenience of illustration herein. Multiple dispatching consoles and multiple access points are also applicable in other embodiments… Since the access point 131 of the wireless communication system 130 and the access point 141 of the wireless communication system 140 belong to different wireless communication systems, protocol format conversion will be performed by the interface platform 120 on the service data respectively sent by the two according to the preset protocol formats so as to obtain the service data in conformity with the protocol format of the corresponding wireless communication system respectively, and then the service data is sent to the dispatching console or the remaining access points. The mutual call between the access points will learn according to the access point configuration information that whether the dispatching console 120 allows the mutual call between the wireless communication system 130 and the wireless communication system 140; if the mutual call between the wireless communication system 130 and the wireless communication system 140 is allowed, then the mutual call between the access points can be implemented).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Moore/Roberts/Subramanyam with the teachings of Liu in order to convert EMS trip data from a first format or dispatch workflow associated with the first EMS agency to a second format or dispatch workflow associated with the second EMS agency. The motivations behind this being to incorporate the teachings of protocol format conversion as taught by Liu. Furthermore, in addition to being in the same CPC class, the teachings, suggestions, and motivations in this prior art would have led one of ordinary skill to modify the prior art reference or combine prior art reference teachings to arrive at the claimed invention.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hoover (US 2015/0244872 A1)
Pacholski et al. (US 2015/0100233 A1)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TYRONE E SINGLETARY whose telephone number is (571)272-1684. The examiner can normally be reached 9 - 5:30.
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, Beth Boswell can be reached at 571-272-6737. 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.
/T.E.S./Examiner, Art Unit 3625
/BETH V BOSWELL/Supervisory Patent Examiner, Art Unit 3625
Prosecution Insights