DETAILED ACTION
Acknowledgement
This final office action is in response to the amendment filed on 11/20/2025.
Status of Claims
Claims 1, 5, 7, 8, 11,13-15, and 20 have been amended.
Claims 1-17 and 19-20 are now pending.
Response to Arguments
The 35 U.S.C. 112(a) and 112(b) rejections are withdrawn in light of amendments.
Applicant's arguments filed on 11/20/2025 regarding the 35 U.S.C. 101 and 103 rejections of claims 1-17 and 19-20 have been fully considered. The Applicant argues the following.
(1) As per the 101 rejection, the Applicant argues, in summary, that (i) even if the claims were found to be directed to a judicial exception, the claims integrate the alleged abstract idea into a practical application. The prioritization software tool provides a number of advantages and computing efficiencies. The prioritization software tool may be used to individually prioritize items, rather than prioritizing entire purchase orders, which allows overseas transport logistics software to separately manage overseas transit of different items from the same vendor, even when presented on the same purchase order; and (ii) the claims are similar to claims in Ex parte Mirza, in that the claimed invention is directed to a technical solution to a technical problem.
The Examiner respectfully disagree with all arguments. The Examiner maintains the position that the additional elements recited in the claims and listed in Steps 2A(2) and 2B do not integrate the abstract idea into a practical application nor provide significantly more because the additional elements do not improve the functioning of a computer, improve another technology or technical field, or provide a technical solution to a technical problem. The combination of the additional elements are viewed as mere instructions to implement an abstract idea on a computer and merely indicates a field of use or technological environment in which to apply a judicial exception. The prioritization software tool is performing the abstract process of computing/calculating a dynamic risk factor and prioritizing/scheduling shipments. Performing and minimizing the number of computations/calculations and updating prioritizations/schedules is abstract and does not represent a direct technological improvement or an improved efficiency in a technological component. As per MPEP 2106.05, the judicial exception alone cannot provide the improvement and an inventive concept cannot be furnished by the abstract idea itself.
The Examiner also submits that the proposed problem that the Applicant's claim is solving is a prioritization and lateness of product shipment problem. The Applicant’s proposed solution as reflected in paragraph [0004] is to “accurately track their shipment and program and predict when the items will arrive at their destination. Improvements are in purchase order item and status prediction via shipment data monitoring and calculations”. The proposed problem and solution does not reflect a “technical” problem addressed by a “technical” solution. Per MPEP 2106.05 (a), if it is asserted that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes, a technical explanation as to how to implement the invention should be present in the specification. That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. An indication that the claimed invention provides an improvement can include a discussion in the specification that identifies a technical problem and explains the details of an unconventional technical solution expressed in the claim, or identifies technical improvements realized by the claim over the prior art. The Applicant’s specification is lacking details of a technological improvement. Therefore, the 35 U.S.C. 101 rejection is maintained.
(2) As per the 103 rejections, the Applicant argues, in summary, that (i) As per claims 1-10 and 20, the combination of Jenkins, Cova, Sandberg, and Abuhab does not teach amended claim 1 limitation of "generating, at the prioritization software tool, a set of prioritized shipment tiers....wherein the set of prioritized shipment tiers includes a highest prioritization tier and a lowest prioritization tier..."; (ii) As per claims 11, 17, and 19, Cova does not teach a predictive, dynamically calculated risk factor that is used to identify at-risk items within purchase orders. The system's risk-related features are focused on reporting and alerting based on events and historical data, not on predictive risk assessment derived from dynamic shipment data.; (iii) Cova's system can update user with notification and supply chain statistics, and can process event-driven updates, it does not describe a feedback loop where the prioritization of specific at-risk items is automatically updated in response to a calculated risk factor or predicted late delivery.
As per argument (i) and amended claims 1-10 and 20, the Examiner finds the Applicant’s argument persuasive. Therefore, the 35 U.S.C. 103 rejection of claims 1-10 and 20 is withdrawn.
As per argument (ii) and amended claims 11, 17, and 19, the Examiner respectfully disagrees. The Examiner submits that based on the broadest reasonable interpretation of the claims, that the combination of Cova and Abuhab teach all of the limitations recited in the claims as shown in the updated rejection below. Cova teaches generating timely, dynamic supply chain management statistics that reflects forecasts/prediction of future events and risks. For example, useful statistics such as actual lead-times, fulfillment risk, dynamic estimated time of arrival, inventory status, demand and supply balance, and carrier and vendor scorecards can be calculated. Real-time risk management solutions can be provided to end users" [0008]. "The information service 204 allows end user systems 206 to track the status of assets 210 in real-time, integrates enterprise data for end user systems, and performs supply chain analysis, including generating supply chain managements statistics [0027]. Cova also teaches calculating various risk categories such as fulfillment risk (Cova e.g. The portal 304 also presents track and trace data, event and exception notifications, end-to-end supply chain visibility, risk management information, customs inspection risk scores, and supply chain statistics, for example, generated by the information service module 702 [0082]. The system can also allow end users to see the particular purchase orders, products, etc. that are in each risk category. The fulfillment risk allows end users to quickly see how much money they stand to lose in the face of events such as port strikes [0107]. FIG. 10G illustrates an example user interface 1060 for displaying fulfillment risk to an end user [0122]). The Examiner submits that the claims do not recite a specific dynamic risk factor that excludes Cova’s teachings.
As per argument (iii), the Examiner finds this argument moot because the claims do not recite “a feedback loop”. The Examiner submits Cova in combination with Abuhab teach all the limitations recited in amended claim 11.
Therefore, the 35 U.S.C. 103 rejection of claims 11, 17, and 19 is maintained. The 35 U.S.C. 103 rejection of claims 12-16 is also maintained. See details below.
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 .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-17 and 19-20 are rejected under 35 U.S.C. 101 because the claimed invention, “Methods and Systems for Prioritization of Selected Overseas Imports and Improving Visibility and Prediction of Import Status”, is directed to an abstract idea, specifically Certain Methods of Organizing Human Activity and Mental Processes, without significantly more. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements individually or in combination provide mere instructions to implement the abstract idea on a computer.
Step 1: Claims 1-17 and 19-20 are directed to a statutory category, namely a process (claims 1-10) and a machine (claims 11-17 and 19-20).
Step 2A (1): Independent claims 1, 11, and 20 are directed to an abstract idea of Certain Methods of Organizing Human Activity and Mental Processes, based on the following claim limitations: “managing prioritization of overseas imports comprising: receiving…a shipping priority…, the shipping priority being associated with one or more items to be imported via overseas carriers; determining an overall prioritization of the one or more items as included within the set of pending purchase orders by applying a plurality of business rules to a set of pending purchase orders issued to overseas vendors; generating…a set of prioritized shipment tiers for the items included within the set of pending purchase orders based on the plurality of business rules, wherein the set of prioritized shipment tiers includes a highest prioritization tier and a lowest prioritization tier and each tier in the set of prioritized shipment tiers is associated with a dwelling period; automatically transmitting prioritized shipment information… to schedule overseas carriers for shipment of the items to the enterprise; scheduling the overseas carriers for transport of the one or more items within the set of pending purchase orders in accordance with the prioritized shipment information; receiving,…, raw shipping status data associated with the one or more items wherein at least a portion of the raw shipping status data is received from the overseas carriers; aggregating,…, the received raw shipping status data by consolidating the raw shipping status data into one or more…data interchange transaction tables of dynamic shipment status data; consolidating the dynamic shipment status data; based on the consolidated shipment status data, automatically calculating a dynamic lead time and a dynamic projected arrival date, wherein the dynamic projected arrival date is based at least in part on the dynamic lead time; automatically calculating,…, a dynamic risk factor, the dynamic risk factor being based on the dynamic projected arrival date and indicating a likelihood that the one or more items will not reach the enterprise by a predetermined goal date; …displaying at least the dynamic risk factor; identifying one or more items as being at risk of late delivery based at least in part on the dynamic risk factor; and automatically updating the prioritization of the identified one or more items; and automatically transmitting updated prioritized shipment information…to schedule overseas carriers for shipment of the items to the enterprise. .” (claim 1); predicting a dynamic risk factor for a shipment of items …; receive,…, raw shipping status data from one or more overseas carriers; aggregating the received raw shipping status data by consolidating the raw shipping status data into one or more…data interchange transaction tables of dynamic shipment status data; receive,…, dynamic shipment status data associated with the shipment of items, the shipment of items being included within a set of purchase orders, wherein at least a portion of the dynamic shipment status data is associated with the one or more overseas carriers; consolidate,…, the dynamic shipment status data, wherein consolidating the shipment status data comprises: reconcile the dynamic shipment status data from the…data interchange transaction tables of dynamic shipment status data; enrich the dynamic shipment status data with data received…; and parse the consolidated shipment status data per purchase order; based on the consolidated shipment status data, automatically calculate a dynamic lead time and a dynamic projected arrival date, wherein the dynamic projected arrival date is based at least in part on the dynamic lead time; automatically calculate,…, a dynamic risk factor, the dynamic risk factor being based on the dynamic projected arrival date and indicating a likelihood that the shipment of items will not reach the enterprise by a predetermined goal date; … displaying at least the dynamic risk factor; identifying one or more items as being at risk of late delivery based at least in part on the dynamic risk factor; automatically update a prioritization of the identified one or more items; and automatically transmit updated prioritized shipment information…to schedule overseas carriers for shipment of items to the enterprise.” (claims 11); “receive,…, a shipping priority…, the shipping priority being associated with one or more items to be imported via overseas carriers; determine, …, an overall prioritization of the one or more items as included within a set of pending purchase orders by applying a plurality of business rules to a set of pending purchase orders issued to overseas vendors; generate, …, a set of prioritized shipment tiers for the items included within the set of pending purchase orders based on the plurality of business rules, wherein the set of prioritized shipment tiers includes a highest prioritization tier and a lowest prioritization tier and each tier in the set of prioritized shipment tiers is associated with a dwelling period; automatically transmit prioritized shipment information…, … to schedule overseas carriers for shipment of the items to the enterprise; and schedule the overseas carriers for transport of the one or more items within the set of pending purchase orders in accordance with the prioritized shipment information; receive,…, raw shipping status data from overseas carriers; aggregate,…, the received raw shipping status data by consolidating the raw shipping status data into one or more…data interchange transaction tables of dynamic shipment status data; receive, …, dynamic shipment status data associated with the one or more items, wherein at least a portion of the dynamic shipment status data is associated with the overseas carriers; consolidate,…, the dynamic shipment status data, wherein consolidating the shipment status data comprises: reconcile the dynamic shipment status data…; enrich the dynamic shipment status data with data received…; and parse the consolidated shipment status data per purchase order; based on the consolidated shipment status data, automatically calculate a dynamic lead time and a dynamic projected arrival date, wherein the dynamic projected arrival date is based at least in part on the dynamic lead time; automatically calculate,…, a dynamic risk factor, the dynamic risk factor being based on the dynamic projected arrival date and indicating a likelihood that the one or more items will not reach the enterprise by a predetermined goal date; … displaying at least the dynamic risk factor; identify one or more items as being at risk of late delivery based at least in part on the dynamic risk factor; and automatically update a prioritization of the one or more identified items; and automatically transmitting updated prioritized shipment information…to schedule overseas carriers for shipment of items to the enterprise” (claim 20). These claims describe a process of prioritizing, scheduling, and monitoring shipment status of items with overseas carriers which can be actions performed by a human (e.g. logistics coordinator). Prioritizing and scheduling shipments with overseas carriers reflects managing personal behavior, relationships, or interactions between people (e.g. carriers and customers) as the prioritizing and scheduling provides instructions for someone to follow and facilitates business transactions. Certain Methods of Organizing Human Activity encompasses managing personal behavior or relationships or interactions between people including social activities, teaching, and following rules or instructions. The claims also reflect Mental Processes as the steps of “determining an overall prioritization of one or more items by applying a plurality of business rules to a set of pending purchase orders issued to overseas vendors, generating a set of prioritized shipment tiers…; receive…dynamic shipping status data…; aggregating…the received dynamic shipping status data…; consolidating the dynamic shipment status data; reconcile the dynamic shipment status data…, enrich the dynamic shipment status data…, parse the consolidated shipment status data…, automatically calculating a dynamic lead time and a dynamic projected arrival date…, automatically calculate a dynamic risk factor…; display at least the dynamic risk factor; and automatically updating the prioritization of the one or more items..” can practically be performed in the human mind with pen and paper via observations, mathematical evaluations, judgments, and opinions. Mental Processes include concepts performed in the human mind such as observations, evaluations, and opinions. Dependent claims 2-10, 12-15, and 17-18, further describe the mental process steps as recited above. Dependent claims 5, 8, 12-13, and 15-16 further describe the certain methods of organizing human activity steps of “scheduling the overseas carriers…; selecting one or more second overseas carriers…; and wherein the one or more second overseas carriers are different than the first overseas carriers”. Therefore, these limitations, under the broadest reasonable interpretation, fall within the abstract groupings of Certain Methods of Organizing Human Activity and Mental Processes. Certain Methods of Organizing Human Activity can encompass the activity of a single person (e.g. a person following a set of instructions), activity that involve multiple people (e.g. a commercial interaction), and certain activity between a person and a computer (e.g. a method of anonymous loan shopping). Mental Processes include claims directed to collecting information, analyzing it, and displaying certain results of the collection and analysis even if they are claimed as being performed on a computer. 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. Therefore, claims 1-17 and 19-20 are directed to an abstract idea and are not patent eligible.
Step 2A (2): This judicial exception is not integrated into a practical application. In particular, claims 1-2, 5-6, 8, 11-15, 17 and 19-20 recite additional elements of “a prioritization software tool; one or more planning systems within an enterprise; an overseas transportation management system, the overseas transportation management system being configured to; real-time; an operations management system; one or more electronic data interchange transaction tables; a purchase order visualization tool; a dynamic user interface; an enterprise vendor shipment coordination tool, one or more enterprise routing systems, an enterprise operations management system, an enterprise inventory system;; the system comprising: a software tool executable on an enterprise computing system, the software tool comprising computer-executable instructions which, when executed, cause the enterprise computing system to…; an overseas transportation management system communicatively connected to the enterprise computing system, the overseas transportation management system being configured to…; an operations management system communicatively connected to the enterprise computing system; a user computing device configured to access the enterprise computing system, and wherein the instructions further cause the enterprise computing system to display the dynamic user interface on the user computing device; a computing system including one or more computing devices, the system comprising instructions to execute a first application and a second application, wherein the first application when executed causes the one or more computing devices to…; wherein the second application when executed causes the one or more computing devices to:”. These additional elements do not integrate the abstract idea into a practical application because the claims do not recite (a) an improvement to another technology or technical field and (b) an improvement to the functioning of the computer itself and (c) implementing the abstract idea with or by use of a particular machine, (d) effecting a particular transformation or reduction of an article, or (e) applying the judicial exception in some other meaningful way beyond generally linking the use of an abstract idea to a particular technological environment. These additional elements evaluated individually and in combination are viewed as computing and display devices that are used to perform the abstract processes and communicate results. Limitations that recite mere instructions to implement an abstract idea on a computer or merely uses a computer as a tool to perform an abstract idea are not indicative of integration into a practical application (see MPEP 2106.05(f)). Also, limitations that amount to merely indicating a field of use or technological environment (e.g. supply chain/logistics) in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application (see MPEP 2106.05(h)). Therefore, claims 1-17 and 19-20 do not include individual or a combination of additional elements that integrate the judicial exception into a practical application and thus are not patent eligible.
Step 2B: The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Claims 1-2, 5-6, 8, 11-15, 17, and 19-20 recite additional elements as stated above. These additional elements are viewed as mere instructions to implement an abstract idea on a computer and merely indicates a field of use or technological environment in which to apply a judicial exception. Applying an abstract idea on a computer and/or generally linking the use of the abstract idea to a particular technological environment does not integrate a judicial exception into a practical application or provide an inventive concept (see MPEP 2106.05 (f) and (h)). Therefore, claims 1-17 and 19-20 do not include individual or a combination of additional elements that are sufficient to amount to significantly more than the judicial exception and thus are not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 11, 17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Cova et al. (US 2012/0303498 A1) in view of Abuhab (US 2020/0175465 A1).
As per claim 11 (Currently Amended), Cova teaches a system for predicting a dynamic risk factor for a shipment of items, the system comprising (Cova e.g. Techniques for tracking physical assets such as intermodal shipping containers, and providing intelligent services to an end user based on locations of the assets, are disclosed [0007]. Fig. 3 illustrates an example architecture of a tag tracking system 302 [0034]. Practical, timely statistics can be generated to allow end users to identify, and solve, potential problems. For example, useful statistics such as actual lead-times, fulfillment risk, dynamic estimated time of arrival, inventory status, demand and supply balance, and carrier and vendor scorecards can be calculated. Real-time risk management solutions can be provided to end users [0008]. Fulfillment risk is what an end user stands to lose when orders are not fulfilled on time (e.g., by the time agreed upon by the seller and purchaser). The system can label a given order and/or asset according to the probability that it will not be fulfilled [0107].): Cova teaches a software tool executable on an enterprise computing system, the software tool comprising computer-executable instructions which, when executed, cause the enterprise computing system to (Cova e.g. The features described above can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The features can be implemented in a computer program product tangibly embodied in a computer readable medium, e.g., in a machine readable storage device, for execution by a programmable processor; and method steps can be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output [0124]. To provide for interaction with a user, the features can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer [0127].):
Cova teaches receive, in real-time at an operations management system, raw shipping status data from one or more overseas carriers; (Cova e.g. FIG. 2 is a block diagram of an example tag system 200 that associates a tag with an asset and monitors and tracks the asset using data received from the tag [0024]. The information service 204 allows end user systems 206 to track the status of assets 210 in real-time, integrates enterprise data for end user systems, and performs supply chain analysis, including generating supply chain managements statistics [0027]. The information service module 700 receives data from four primary sources: portal 304, tag database 216, event server 316, and message server 320 [0082]. The message server 320 receives data from various sources including RFID readers, EDI gateways, and ZCC input devices, and provides this data to the information service module [0043]. FIG. 7 illustrates an example information service module 702 [0081]. The information service module 702 provides end users with track and trace functionality that allows the end users to track assets as the assets journey from an origin location to a destination location [0081]. The information service module 702 can additionally generate one or more supply chain management statistics based on both data from the tags and enterprise data for the end user [0081].The message server 320 receives RFID data for RFID enabled tags ( e.g., tag 210b ), for example, from one or more RFID readers at various locations along the tag's journey, such as at one or more ports [0085]. The message server 320 also receives various data through the message (EDI) gateway services 704. Messages received through the message (EDI) gateway services 704 can come from various sources including, for example, shipment messages, location status messages, import-export messages, and messages from end users [0085]. Location status messages can include, for example, truck carrier messages, ocean carrier messages, rail carrier messages, ocean vessel latitude and longitude messages (e.g., through either 315 messages or GPS transponders) [0085]. The messages received through the Message (EDI) Gateway Services 404 can include information purchase orders and additional EDI, shipping instructions, booking data, multi-modal carrier status updates, and customs compliance data [0085]. The enterprise data can also include transaction data describing a sale or purchase of items in the asset. For example, the transaction data can be purchase orders or invoice data that lists one or more of the items in the asset, the buyer and seller of the items in the asset, and promised dates regarding delivery of the asset (ship by date, deliver by date, etc.) [0090]. The information service module 702 consists of purchase order to fulfillment services (P2F+SCA Services) 706, and operational data store (ODS) 708, as well as the data warehouse 712, rules engine 714, and reporting services 716. These components can be communicatively coupled to one or more of each other [0091].)
Cova teaches aggregating the received raw shipping status data by consolidating the raw shipping status data into one or more electronic data interchange transaction tables; (Cova e.g. The information service 204 allows end user systems 206 to track the status of assets 210 in real-time, integrates enterprise data for end user systems, and performs supply chain analysis, including generating supply chain managements statistics [0027]. The information service module 700 receives data from four primary sources: portal 304, tag database 216, event server 316, and message server 320 [0082]. The message server 320 receives data from various sources including RFID readers, EDI gateways, and ZCC input devices, and provides this data to the information service module (i.e. aggregates) [0043]. The message server 320 also receives various data through the message (EDI) gateway services 704. Messages received through the message (EDI) gateway services 704 can come from various sources including, for example, shipment messages, location status messages, import-export messages, and messages from end users [0085]. Shipment messages can include, for example, purchase orders, purchase order changes, advance ship notices, shipping instructions, bill-of-landing, and commercial invoices [0085]. The messages received through the Message (EDI) Gateway Services 404 can include information purchase orders and additional EDI, shipping instructions, booking data, multi-modal carrier status updates, and customs compliance data [0085]. The tag 114 reports various events, including for example, security events, environmental events, process events, and tracking events. The event information can be stored by the tag provider 106, for example, in an event database [0021].)
Cova teaches receive, in real-time at a purchase order visualization tool from one or more electronic data interchange transaction tables, dynamic shipment status data associated with the shipment of items, the shipment of items being included within a set of purchase orders, wherein at least a portion of the dynamic shipment status data is associated with one or more overseas carriers; (Cova e.g. FIG. 2 is a block diagram of an example tag system 200 that associates a tag with an asset and monitors and tracks the asset using data received from the tag [0024]. The information service 204 allows end user systems 206 to track the status of assets 210 in real-time, integrates enterprise data for end user systems, and performs supply chain analysis, including generating supply chain managements statistics [0027]. The message server 320 receives data from various sources including RFID readers, EDI gateways, and ZCC input devices, and provides this data to the information service module [0043]. FIG. 7 illustrates an example information service module 702 [0081]. The information service module 702 provides end users with track and trace functionality that allows the end users to track assets as the assets journey from an origin location to a destination location [0081]. The information service module 702 can additionally generate one or more supply chain management statistics based on both data from the tags and enterprise data for the end user [0081].The message server 320 receives RFID data for RFID enabled tags (e.g., tag 210b), for example, from one or more RFID readers at various locations along the tag's journey, such as at one or more ports [0085]. The message server 320 also receives various data through the message (EDI) gateway services 704. Messages received through the message (EDI) gateway services 704 can come from various sources including, for example, shipment messages, location status messages, import-export messages, and messages from end users [0085]. Location status messages can include, for example, truck carrier messages, ocean carrier messages, rail carrier messages, ocean vessel latitude and longitude messages ( e.g., through either 315 messages or GPS transponders) [0085]. The messages received through the Message (EDI) Gateway Services 404 can include information purchase orders and additional EDI, shipping instructions, booking data, multi-modal carrier status updates, and customs compliance data [0085]. The enterprise data can also include transaction data describing a sale or purchase of items in the asset. For example, the transaction data can be purchase orders or invoice data that lists one or more of the items in the asset, the buyer and seller of the items in the asset, and promised dates regarding delivery of the asset (ship by date, deliver by date, etc.) [0090]. The information service module 702 consists of purchase order to fulfillment services (P2F+SCA Services) 706, and operational data store (ODS) 708, as well as the data warehouse 712, rules engine 714, and reporting services 716. These components can be communicatively coupled to one or more of each other [0091].)
Cova teaches consolidate, at an operations management system, the dynamic shipment status data, wherein consolidating the shipment status data comprises: reconcile the dynamic shipment status data from the one or more electronic data interchange transaction tables; enrich the dynamic shipment status data with data received at least from: an enterprise vendor shipment coordination tool, one or more enterprise routing systems, an enterprise operations management system, and an enterprise inventory system; and parse the consolidated shipment status data per purchase order; (Cova e.g. Practical, timely statistics can be generated to allow end users to identify, and solve, potential problems. For example, useful statistics such as actual lead-times, fulfillment risk, dynamic estimated time of arrival, inventory status, demand and supply balance, and carrier and vendor scorecards can be calculated. A single point of access to inventory, shipment, and other information, across all points in the physical supply chain and throughout the entire purchase order to fulfillment lifecycle can be provided [0008]. A tracking system (e.g., system 200 of FIG. 2) can process the tracking events to determine when an asset has entered or left a predefined area [0021]. FIG. 4 illustrates an example journey of an asset from a origin location 402 to a destination location 404. As the asset travels from the origin location 402 to the destination location 404, a tag associated with the asset issues various event notifications [0048]. FIG. 3 illustrates an example architecture of a tag tracking system 302. These components can be communicatively coupled to one or more of each other [0034]. The message server 320 receives data from various sources including RFID readers, EDI gateways, and ZCC input devices, and provides this data to the information service module [0043]. The information service module 700 receives data from four primary sources: portal 304, tag database 216, event server 316, and message server 320 [0082]. Messages received through the message (EDI) gateway services 704 can come from various sources including, for example, shipment messages, location status messages, import-export messages, and messages from end users. Shipment messages can include, for example, purchase orders, purchase order changes, advance ship notices, shipping instructions, bill-of-landing, and commercial invoices. Location status messages can include, for example, truck carrier messages, ocean carrier messages, rail carrier messages, ocean vessel latitude and longitude messages (e.g., through either 315 messages or GPS transponders). Import/export messages can include, for example, entry messages, entry summaries, and customs status updates. The messages received through the Message (EDI) Gateway Services 404 can include information purchase orders and additional EDI, shipping instructions, booking data, multi-modal carrier status updates, and customs compliance data [0085]. Much of the data received by the message server 302 is enterprise data, that is, data describing the enterprise shipping the assets, data describing the items in the assets, for example, transaction data for the asset, data describing forecasting and planning information for the enterprise, and data describing the shipment context for the asset [0086]. The enterprise data can also include shipment context information for the assets, for example, an expected route that the asset will take, along with dates and times for key milestones in the journey. Shipment context information can also include EDI 315 and EDI 214 status update messages, certificates of origin, export and import certificates, carrier invoices, bills of landing, booking information, shipping instructions, data from non-intrusive inspection systems such as radiation portal monitors, and the customs compliance data and carrier status updates described above [0088]. Enterprise data can also include forecasting and planning information for the enterprise, supplier and vendor information, pricing information, and third party information such as information on end customers of the end user, carriers, forwarding agents, and logistics providers [0089]. The information service module 324 provides various levels of information to end users. The information service module 324 can provide a track and trace service that allows end users to view the location of their assets over time, as well as a description of any events that occurred during the asset's journey [0045]. The information service module 702 can additionally generate one or more supply chain management statistics based on both data from the tags and enterprise data for the end user [0081]. Examples of supply chain management statistics include, but are not limited to, estimated time of arrival for inventory, lead time, fulfillment risk, demand and supply balance, products inbound, perfect order fill rate, shipment fill rate, on-time shipment rate, on-time arrival rate, amount ordered, amount shipped, amount arrived, inventory in-transit, and carrier and vendor performance scorecards [0104]. The information service module 702 consists of purchase order to fulfillment services (P2F+SCA Services) 706, and operational data store (ODS) 708, as well as the data warehouse 712, rules engine 714, and reporting services 716. These components can be communicatively coupled to one or more of each other. The information service module 702 uses the data that it receives to provide two main types of functionality to the end user: track and trace, and supply chain analysis [0091]. The system receives enterprise data describing items being shipped in assets (902) [0102]. The P2F+SCA services 706 may further use enterprise data from the end user to augment the track and trace notifications, for example, as described below with reference to FIG. 8 [0092]. The portal module 304 provides a portal through which end users and internal users (e.g., tracking system employees) can send data to the system and receive data from the system (Fig. 3 and [0035]). FIGS. 10A-10H illustrate various example user interfaces for providing data generated by the information service module 324 to the end user [0115].)
Cova teaches based on the consolidated shipment status data, automatically calculate a dynamic lead time and a dynamic projected arrival date, wherein the dynamic projected arrival date is based at least in part on the dynamic lead time; (Cova e.g. Practical, timely statistics can be generated to allow end users to identify, and solve, potential problems. For example, useful statistics such as actual lead-times, fulfillment risk, dynamic estimated time of arrival, inventory status, demand and supply balance, and carrier and vendor scorecards can be calculated [0008]. In some implementations, the user notification also includes a dynamic estimated time of arrival for the asset, calculated, for example, from the data received about the asset's journey and historical lead time information gathered from past journeys along the same route [0098]. The system generates one or more supply chain management statistics using the enterprise data and the tag data for each asset (906). Examples of supply chain management statistics include, but are not limited to, estimated time of arrival for inventory, lead time, fulfillment risk, demand and supply balance, products inbound, perfect order fill rate, shipment fill rate, on-time shipment rate, on-time arrival rate, amount ordered, amount shipped, amount arrived, inventory in-transit, and carrier and vendor performance scorecards. In general, an supply chain management statistic provides an overview (e.g., metrics, computations, visualizations, and control thresholds) of a particular aspect of the enterprise's supply chain [0104]. The estimated time of arrival for an asset (or items in an asset) is the time the system predicts the asset will arrive at its destination. The system can calculate an estimated time of arrival for an item in one of the assets by identifying the asset containing the item, and then calculating an estimated time of arrival for the asset [0105]. Lead time is the time from when a tag is coupled to an asset (indicating that the journey is beginning) to the time when the tag is uncoupled from the asset at the asset's final destination (indicating that the journey is ending). The system calculates lead time from historical data that is stored for the end user [0106].)
Cova teaches automatically calculate, by the purchase order visualization tool, a dynamic risk factor, the dynamic risk factor being based on the dynamic projected arrival date and indicating a likelihood that the shipment of items will not reach the enterprise by a predetermined goal date; (Cova e.g. Practical, timely statistics can be generated to allow end users to identify, and solve, potential problems. For example, useful statistics such as actual lead-times, fulfillment risk, dynamic estimated time of arrival, inventory status, demand and supply balance, and carrier and vendor scorecards can be calculated. Real-time risk management solutions can be provided to end users [0008]. FIG. 9 is a flow diagram of an example process 900 for generating supply chain management statistics [0101]. The system receives enterprise data describing items being shipped in assets (902) [0102]. The system receives tag data for a tag associated with each asset while the asset is in transit (904) [0103]. The system generates one or more supply chain management statistics using the enterprise data and the tag data for each asset (906) [0104]. Examples of supply chain management statistics include, but are not limited to, estimated time of arrival for inventory, lead time, fulfillment risk, demand and supply balance, products inbound, perfect order fill rate, shipment fill rate, on-time shipment rate, on-time arrival rate, amount ordered, amount shipped, amount arrived, inventory in-transit, and carrier and vendor performance scorecards [0104]. Fulfillment risk is what an end user stands to lose when orders are not fulfilled on time (e.g., by the time agreed upon by the seller and purchaser). The system can label a given order and/or asset according to the probability that it will not be fulfilled. For example, the system can label the order/asset as one of "likely late," "past due," "exception," or "on time". An orders/asset is "likely late" when the dynamic estimated time of arrival for the order/asset is after the time the order/asset is supposed to arrive. An order/asset is "past due" when it is already past the time the order/asset is supposed to arrive. An order/asset has an "exception" when a security and/or environmental event occurred during the journey. Once the orders and/or assets are labeled, the system can allow end users to view the total dollar amount of the items in the orders and/or assets at risk for each label. For example, the system can calculate the total dollar amount that is "likely late". The system can also allow end users to see the particular purchase orders, products, etc. that are in each risk category. The fulfillment risk allows end users to quickly see how much money they stand to lose in the face of events such as port strikes [0107].)
Cova teaches generate a dynamic user interface, the user interface displaying at least the dynamic risk factor; and (Cova e.g. The portal 304 also presents track and trace data, event and exception notifications, end-to-end supply chain visibility, risk management information, customs inspection risk scores, and supply chain statistics, for example, generated by the information service module 702 [0082]. The system can also allow end users to see the particular purchase orders, products, etc. that are in each risk category. The fulfillment risk allows end users to quickly see how much money they stand to lose in the face of events such as port strikes [0107]. FIG. 10G illustrates an example user interface 1060 for displaying fulfillment risk to an end user [0122].)
Although Cova teaches overseas transport of items and calculating a dynamic risk factor (e.g. fulfillment risk) that indicates a likelihood that the one or more items will not reach the enterprise by a predetermined goal date, Cova does not explicitly teach automatically updating the prioritization of the one or more items to minimize a number of items identified as being at risk of late delivery based at least in part on the dynamic risk factor and automatically transmitting updated prioritized shipment information to the overseas transportation management system being configured to schedule overseas carriers for shipment of items to the enterprise.
However, Abuhab teaches automatically update the prioritization of the one or more items to minimize a number of items identified as being at risk of late delivery based at least in part on the dynamic risk factor; and (Abuhab e.g. A shipment prioritization computing system may process inventory, order and/or shipping information to enable suppliers to prioritize product shipments to retailers and distributors to provide responsiveness and timely delivery of products to the correct destination on time (Abstract and [0024]). The invention adjusts shipment prioritization using the Throughput Value Day (TVD) (risk value of sales loss) concept, in which a calculation is made to consider the gains and the number of days for product shortage risk, and including information on the manufacturing enterprise resource management systems [0009]. To maintain a single priority criterion, retail networks are integrated into a single cloud system that allows the standard calculation of the TVD indicator, updating daily the priorities in the ERPs of the manufacturing companies based on inputs from the manufacturing system and/or the changing sales inputs from retail or distribution computing systems [0010]. A cross-platform application programming interface may provide functions that may be integrated into different ERP computing systems to prioritize shipments by a sales order and/or a product identifier (e.g., a SKU) [0024]. ERPs define shipment priorities though an analysis of internal criteria and/or by observing a best location criterion. However, these ERP computing systems do not consider the risk of a potential loss of sales [0025]. To ensure that there is no inventory supply break at the point of sale, the prioritization of order delivery by manufacturers must take into account the risk that a particular product may have a break in availability in the store. Based on this information, the manufacturers can better plan its delivery of orders to increase the turnover of its products and, at the same time, the retail outlets can increase the availability in these same goods, reducing both manufacturing and retail losses caused by the lack of the product [0026]. For at least these reasons, a need was recognized to adjust the prioritization of shipment of the items of sales orders through use of calculated information, such as the Throughput Value Day (TVD) indicator. The TVD indicator relates to a value associated with the risk of loss of sales and may be calculated considering during the gain and the number of risk days of absence of the product [0027].)
Abuhab teaches automatically transmitting updated prioritized shipment information to the…transportation management system, the…transportation management system being configured to schedule…carriers for shipment of items to the enterprise. (Abuhab e.g. Another aspect of this disclosure is providing shipment prioritization algorithms that process existing inventory data, order data and the like using algorithms to output ideal inventory information... [0011]. These algorithms may compare the current inventory levels with ideal inventory levels, and identify and predict a risk of breakdown of each product's supply at one or more points of sale, thus allowing a centrally located computing system (e.g., a cloud computing system) to perform dynamic calculations for shipment priority [0012]. This information may be accessible and communicated through one or more API functions that can be accessed dynamically by networked ERP computing systems from manufacturing company computing systems, distribution center computing systems, retail outlet computing systems to update dynamically an open order's priority fields [0012].)
The Examiner submits that before the effective filing date, it would have been obvious to one of ordinary skill in the art to combine Cova’s system and method of monitoring and tracking assets (e.g. overseas imports) with EDI and Abuhab’s shipment prioritization process that includes updating/adjusting and transmitting priorities of shipments based on a risk factor/indicator (e.g. Throughput Value Day) in order to reduce both manufacturing and retail losses caused by the lack of the product (Abuhab e.g. [0026]).
As per claim 17 (Previously Presented), Cova in view of Abuhab teach the method system of claim 11, further comprising instructions causing the enterprise computing system to:
Cova teaches receive, from the one or more electronic data interchange transaction tables, second dynamic shipment status data associated with the shipment of items; (See claim 11 response.)
Cova teaches consolidate the second dynamic shipment status data, wherein consolidating the second shipment status data comprises: reconcile the second dynamic shipment status data from the one or more electronic data interchange transaction tables; enrich the second dynamic shipment status data with data received at least from: an enterprise vendor shipment coordination tool, one or more enterprise routing systems, an enterprise operations management system, and an enterprise inventory system; and parse the second consolidated shipment status data per purchase order; (See claim 11 response.)
Cova teaches based on the second consolidated shipment status data, automatically calculate a second dynamic lead time and a second dynamic projected arrival date, wherein the second dynamic projected arrival date is based at least in part on the second dynamic lead time; and (See claim 11 response.)
Cova teaches automatically calculate a second dynamic risk factor, the second dynamic risk factor being based on the second dynamic projected arrival date and indicating a likelihood that the shipment of items will not reach the enterprise by the predetermined goal date. (See claim 11 response.)
As per claim 19 (Original), Cova in view of Abuhab teach the system of claim 11, Cova teaches further comprising a user computing device configured to access the enterprise computing system, and wherein the instructions further cause the enterprise computing system to display the dynamic user interface on the user computing device. (Cova e.g. To provide for interaction with a user, the features can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer [0127]. FIGS. 10A-10H illustrate various example user interfaces for providing data generated by the information service module 324 to the end user [0115].)
Claims 12-16 are rejected under 35 U.S.C. 103 as being unpatentable over Cova et al. (US 2012/0303498 A1) in view of Abuhab (US 2020/0175465 A1) and in further view of Jenkins et al. (US 2002/0188499 A1).
As per claim 12 (Previously Presented), Cova in view of Abuhab teach the system of claim 11, further comprising instructions causing the enterprise computing system to:
Cova teaches of a system and method of monitoring and tracking shipments of items to be imported via overseas carriers (Cova e.g. Techniques for tracking physical assets such as intermodal shipping containers, and providing intelligent services to an end user based on locations of the assets, are disclosed [0007]. FIG. 1 illustrates an example buyer 102, seller 104, and tag provider 106 interacting in a shipping scenario. An example asset 108 is shipped from the seller 104 to the buyer 102 on an example conveyance 110 [0019]. Examples of conveyances include, but are not limited to, trucks, trains, ships, and airplanes. Examples of assets include, but are not limited to, containers such as dry-van containers, refrigerated containers, ISO tanks, trailers, box trucks, and unit load devices (ULDs) [0019]. In some implementations, the asset is an intermodal shipping container, however the asset can also be, for example, equipment, or other items capable of being monitored or tracked [0019]. The selected tag 114 can be coupled to the asset 108 before the asset begins its journey and/or re-coupled to the asset 108 during the journey (e.g., after authorized custom inspections) [0021]. During the journey, the tag 114 can be programmed to wake up periodically, initiate communication with the tag provider 106, and send event notifications to the tag provider 106 [0021]. The information service module 324 can provide a track and trace service that allows end users to view the location of their assets over time, as well as a description of any events that occurred during the asset's journey [0045]. FIG. 4 illustrates an example journey of an asset from a origin location 402 to a destination location 404. As the asset travels from the origin location 402 to the destination location 404, a tag associated with the asset issues various event notifications [0048]. Some of the tracking events (e.g., tracking events 408 and 418) can be used to determine that the asset has entered or left a port or other designated area (e.g., because the location is now inside or outside a geofence associated with the designated area) [0050]. Location status messages can include, for example, truck carrier messages, ocean carrier messages, rail carrier messages, ocean vessel latitude and longitude messages (e.g., through either 315 messages or GPS transponders) [0085]. Import/export messages can include, for example, entry messages, entry summaries, and customs status updates [0085].)
Cova teaches monitoring/tracking import assets/items associated with purchase orders issued to overseas suppliers/vendors (Cova e.g. Techniques for tracking physical assets such as intermodal shipping containers, and providing intelligent services to an end user based on locations of the assets, are disclosed [0007]. FIG. 1 illustrates an example buyer 102, seller 104, and tag provider 106 interacting in a shipping scenario. An example asset 108 is shipped from the seller 104 to the buyer 102 on an example conveyance 110 [0019]. FIG. 7 illustrates an example information service module 702 [0081]. The information service module 702 provides end users with track and trace functionality that allows the end users to track assets as the assets journey from an origin location to a destination location [0081]. The information service module 700 receives data from four primary sources: portal 304, tag database 216, event server 316, and message server 320 [0082]. The message server 320 also receives various data through the message (EDI) gateway services 704. Messages received through the message (EDI) gateway services 704 can come from various sources including, for example, shipment messages, location status messages, import-export messages, and messages from end users. Shipment messages can include, for example, purchase orders, purchase order changes, advance ship notices, shipping instructions, bill-of-landing, and commercial invoices [0085]. Much of the data received by the message server 302 is enterprise data, that is, data describing the enterprise shipping the assets, data describing the items in the assets, for example, transaction data for the asset, data describing forecasting and planning information for the enterprise, and data describing the shipment context for the asset [0086]. The information service module 702 consists of purchase order to fulfillment services (P2F+SCA Services) 706, and operational data store (ODS) 708, as well as the data warehouse 712, rules engine 714, and reporting services 716. These components can be communicatively coupled to one or more of each other [0091]. Demand and supply balance measures any difference from the number of items ordered and the number of items shipped. The demand and supply balance allows end users to have an aggregate view of inventory flow, as purchase orders are matched to actual shipments [0108]. The system can also allow end users to see the particular purchase orders, products, etc. that are in each risk category [0107].The enterprise data can also include transaction data describing a sale or purchase of items in the asset. For example, the transaction data can be purchase orders or invoice data that lists one or more of the items in the asset, the buyer and seller of the items in the asset, and promised dates regarding delivery of the asset (ship by date, deliver by date, etc.) [0090].The system receives enterprise data describing items being shipped in assets (902) [0102].)
Cova nor Abuhab explicitly teach, however, Jenkins teaches the following:
Jenkins teaches receive a shipping priority from one or more planning systems within an enterprise, the shipping priority being associated with the shipment of items via carriers; (Jenkins e.g. A fulfillment system 100 is illustrated in FIGS. 1A-1B [0013]. The fulfillment system 100 is divided into a distribution component 200, a deployment component 300, a production component 400, a material allocation component 500, and a database 600 [0017]. A central component of the distribution module 200 is the planning component 210 used to generate planned arrivals and planned orders to meet replenishment requirements for stock-keeping units (SKUs) (Fig. 1A and [0027]). By coordinating with deployment module 300, the planning component 210 also can generate recommended shipments that consider inventory constraints in addition to demand (Fig. 1A and [0027]). After the planning component 210 process has created planned orders, the user can export those orders to the external execution system 10. The external system 10 modifies the planned orders as necessary, then releases them as actual production orders or vendor orders. The user can then import those actual orders to fulfillment system 100 as scheduled receipts, to be used as replenishments by the planning component 210 and scheduling component 220 [0057]. To manage the deployment process in the deployment component 300, the user uses the planning component 210 to create recommended shipments based on both the demand at the destination SKUs and the actual stock available at the source [0138]. Recommended shipments produced by the deployment component 300 can be used to construct transportation plans and build shipment requirements into loads [0137]. The planning component 210 groups together all recommended shipments with the same item, source, and destination whose schedule shipping date falls within a given interval. The quantity of the recommended shipment is the sum of the recommended shipments being aggregated [0174]. The deployment component 300 offers the user four deployment logic options. With one option, the deployment component 300 sorts requirements in order by location priority, demand priority, and the need to ship date. With this rule, the deployment component 300 uses the earliest available stock to meet the highest priority demand. The deployment component 300 sorts demand in order by the need to ship date, from earliest (longest lead time) to latest (shortest lead time). It recommends shipments to meet demand for the destination SKU with the earliest need to ship date (or longest lead time) first, followed by the destination with the next earliest NeedShipDate, and so on [0228].)
Jenkins teaches apply a plurality of business rules to the set of pending …orders issued to…vendors to determine an overall prioritization of the shipments of items as included within the set of pending … orders; (Jenkins e.g. When the planning component 210 is running in constrained mode and source stock is limited within the minimum allocation duration, you can tell the planning component 210 which locations have priority over others when meeting demand. The planning component 210 will meet demand (firm planned arrivals and demand based on an allocation strategy) at locations with highest priority first [0178]. When source stock is limited, the allocation strategy determines the order in which the planning component 210 allocates stock to meet demand within a given location priority. For example, if the user assigns a priority of 1 to distribution demand, 2 to dependent demand, 3 to forecasted customer orders, 4 to nonforecasted in customer orders, and 5 to adjusted allocated total forecast, within each location priority the planning component 210 will allocate stock to meet distribution demand first [0180]. The priority the user assigns to different demand categories determines how the planning component 210 calculates the Available to Ship Date. Later demand with a higher priority will have an earlier Available to Ship Date than earlier demand with a lower priority [0203]. The deployment component 300 offers the user four deployment logic options. With one option, the deployment component 300 sorts requirements in order by location priority, demand priority, and the need to ship date. With this rule, the deployment component 300 uses the earliest available stock to meet the highest priority demand. The deployment component 300 sorts demand in order by the need to ship date, from earliest (longest lead time) to latest (shortest lead time). It recommends shipments to meet demand for the destination SKU with the earliest need to ship date (or longest lead time) first, followed by the destination with the next earliest NeedShipDate, and so on [0228]. Alternatively, the deployment component 300 sorts requirements in order by location priority, demand priority, or need to arrive date. With this rule, the deployment component 300 uses the earliest available stock to meet the highest priority demand. The deployment component 300 sorts demand in order by need to arrive date, rather than need to ship date [0229]. Alternatively, the deployment component 300 sorts requirements in order by demand priority based on the allocation strategy assigned to the SKU, location priority, and need to arrive date [0232].)
Jenkins teaches generate a set of prioritized shipment tiers for the shipments of items included within the set of pending…orders based on the plurality of business rules; (Jenkins e.g. The deployment process begins with the planning component 210, which creates a replenishment plan, then generates recommended shipments to cover the planned arrivals [0139]. The automated load builder 310 recommended shipments into feasible vehicle loads, based on a solution strategy that the user specify [0246]. Before the user generate vehicle loads, the user must define a solution strategy that automated load builder 310 will use when it builds loads. This strategy determines which recommended shipments must be included in a load,..., and sets the priority for adding recommended shipments to a partially filled load [0261]. When the automated load builder 310 builds a load, the first recommended shipment it adds to the load is a must go shipment. It then completes the load by adding additional recommended shipments [0269]. A recommended shipment may qualify as a must go shipment with one transportation mode and not with another. This is because the transportation lead times between transportation modes may differ, causing the needed ship date of a recommended shipment to fall on a different day [0275]. The automated load builder 310 calculates a priority value for each recommended shipment between the source and destination it is working with by adding values for rewards and subtracting values for penalties. The recommended shipment having the highest value is added to the load first, followed by the next highest value, and so on [0270]. The user sets priorities by entering values associated with several costs,...[0271]. First, the automated load builder 310 selects target recommended shipments to start the load, sorts recommended shipments according to needed arrival date, and selects a target recommended shipment [0280]. Subsequently, the automated load builder 310 calculates priority values for all the candidate recommended shipments and assigns priority values [0280]. The automated load builder 310 adds shipments to load, by selecting the shipment with the highest priority, adding that shipment to the load, and continuing to add shipments to the load in order by priority, until there are no more shipments that can be added to the load [0281].)
Jenkins teaches automatically transmit prioritized shipment information to a …transportation management system communicatively connected to the enterprise computing system, the…transportation management system being configured to schedule one or more…carriers for shipment of the items to the enterprise; and (Jenkins e.g. The fulfillment system 100 divided into a distribution component 200, a deployment component 300, a production component 400, a material allocation component 500, and a database 600 [0017]. As illustrated in FIG. 1B, the external system 10 may connect to the fulfillment system 100 via an integration server 200 connected to an application server 30 housing the fulfillment system 100. Likewise, a web client 40 may connect to the fulfillment system 100 through web services components. Companies that use an external execution system 10 to release production orders and vendor orders can provide input to and receive output from that system through the scheduling component 220 feature in fulfillment system 100. After the planning component 210 process has created planned orders, the user can export those orders to the external execution system 10. The external system 10 modifies the planned orders as necessary, then releases them as actual production orders or vendor orders [0057]. Recommended shipments produced by the deployment component 300 can be used to construct transportation plans and build shipment requirements into loads [0137]. The planning component 210 groups together all recommended shipments with the same item, source, and destination whose schedule shipping date falls within a given interval. The quantity of the recommended shipment is the sum of the recommended shipments being aggregated [0174]. The automated load builder 310 builds loads using the transportation mode(s) defined for the source and destination. The user can define alternate transportation modes for the automated load builder 310 to use in the event it cannot fill the load using the primary or preferred transportation mode [0273]. The automated load builder 310 finds the optimal load configuration by attempting to place all recommended shipments on all available alternate carriers [0276].)
Jenkins teaches schedule the one or more … carriers for transport of the shipment of items within the set of pending…orders in accordance with the prioritized shipment information. (Jenkins e.g. Companies that use an external execution system 10 to release production orders and vendor orders can provide input to and receive output from that system through the scheduling component 220 feature in fulfillment system 100 (Fig. 1A-1B and [0057]). The system 100 determines the source and destination locations the user wants to work with based on the user data selection. It displays all the lanes for those sources and destinations: a lane is a combination of source, destination, and transportation mode. The user may select the lanes she wants to work with. Also, the user can work with multiple lanes for the same source and destination [0290]. The automated load builder 310 builds loads using the transportation mode(s) defined for the source and destination. The user can define alternate transportation modes for the automated load builder 310 to use in the event it cannot fill the load using the primary or preferred transportation mode [0273].The automated load builder 310 selects the preferred transportation mode for the recommended shipment. Then, the automated load builder 310 creates a load using the selected transportation mode [0280]. The automated load builder 310 adds shipments to load, by selecting the shipment with the highest priority, adding that shipment to the load, and continuing to add shipments to the load in order by priority, until there are no more shipments that can be added to the load [0281]. If the load is full, the automated load builder 310 commits the load and goes to create the next load [0281].)
The Examiner submits that before the effective filing date, it would have been obvious to one of ordinary skill in the art to combine Cova in view of Abuhab’s system and method of monitoring and tracking shipment of assets (e.g. overseas imports) with Jenkin’s system and method of ensuring order fulfillment via prioritizing shipments in order to provide the user with real-time network visibility of planned shipments, in-transit, available inventory, and expiring product (Jenkins e.g. [0008]).
As per claim 13 (Currently Amended ), Cova in view of Abuhab and Jenkins teach the system of claim 12, further comprising instructions causing the enterprise computing system to:
Cova teaches identifying one or more items as being at risk of late delivery (Cova e.g. Practical, timely statistics can be generated to allow end users to identify, and solve, potential problems. For example, useful statistics such as actual lead-times, fulfillment risk, dynamic estimated time of arrival, inventory status, demand and supply balance, and carrier and vendor scorecards can be calculated [0008]. Fulfillment risk is what an end user stands to lose when orders are not fulfilled on time (e.g., by the time agreed upon by the seller and purchaser). The system can label a given order and/or asset according to the probability that it will not be fulfilled. For example, the system can label the order/asset as one of "likely late," "past due," "exception," or "on time". An orders/asset is "likely late" when the dynamic estimated time of arrival for the order/asset is after the time the order/asset is supposed to arrive. An order/asset is "past due" when it is already past the time the order/asset is supposed to arrive. An order/asset has an "exception" when a security and/or environmental event occurred during the journey. Once the orders and/or assets are labeled, the system can allow end users to view the total dollar amount of the items in the orders and/or assets at risk for each label. For example, the system can calculate the total dollar amount that is "likely late." [0107].)
Cova nor Abuhab explicitly teach based on identifying one or more items as being at risk of late delivery, generate a second set of prioritized shipment tiers for the shipment of items based on the plurality of business rules and the determination.
However, Jenkins teaches generate a second set of prioritized shipment tiers for the shipment of items based on the plurality of business rules and the determination; (Jenkins e.g. See claim 12 response. & Five options on the automated load builder 310 dialog allow the user to define the priority for adding shipments to a partially filled load. Each of these options has either a reward or penalty associated with it [0270]. The automated load builder 310 calculates a priority value for each recommended shipment between the source and destination it is working with by adding values for rewards and subtracting values for penalties. The recommended shipment having the highest value is added to the load first, followed by the next highest value, and so on [0270]. The recommended shipment with the highest priority is added to the load first. Every time the automated load builder 310 adds a shipment to a load, it automatically recalculates priority values and resorts recommended shipments by priority. Reprioritizing the shipments optimizes the load, since the priorities guide the algorithm into generating better quality loads [0272].)
Cova in view of Abuhab and Jenkins teach automatically transmit a second instance of prioritized shipment information to the overseas transportation management system; and (See claim 12 response.)
Cova in view of Abuhab and Jenkins teach schedule the overseas carriers for transport of the shipment of items within the set of pending purchase orders in accordance with the second instance of prioritized shipment information. (See claim 12 response.)
The Examiner submits that before the effective filing date, it would have been obvious to one of ordinary skill in the art to combine Cova in view of Abuhab’s system and method of monitoring and tracking shipment of assets (e.g. overseas imports) with Jenkin’s system and method of ensuring order fulfillment via prioritizing shipments with in order to provide the user with real-time network visibility of planned shipments, in-transit, available inventory, and expiring product (Jenkins e.g. [0008]).
As per claim 14 (Currently Amended), Cova in view of Abuhab and Jenkins teach the system of claim 12, further comprising instructions causing the enterprise computing system to:
Cova teaches identifying one or more items as being at risk of late delivery (Cova e.g. Practical, timely statistics can be generated to allow end users to identify, and solve, potential problems. For example, useful statistics such as actual lead-times, fulfillment risk, dynamic estimated time of arrival, inventory status, demand and supply balance, and carrier and vendor scorecards can be calculated [0008]. Fulfillment risk is what an end user stands to lose when orders are not fulfilled on time (e.g., by the time agreed upon by the seller and purchaser). The system can label a given order and/or asset according to the probability that it will not be fulfilled. For example, the system can label the order/asset as one of "likely late," "past due," "exception," or "on time". An orders/asset is "likely late" when the dynamic estimated time of arrival for the order/asset is after the time the order/asset is supposed to arrive. An order/asset is "past due" when it is already past the time the order/asset is supposed to arrive. An order/asset has an "exception" when a security and/or environmental event occurred during the journey. Once the orders and/or assets are labeled, the system can allow end users to view the total dollar amount of the items in the orders and/or assets at risk for each label. For example, the system can calculate the total dollar amount that is "likely late." [0107].)
Cova teaches automatically generating a notification, the notification including at least one of: the dynamic risk factor, the dynamic lead time, and the dynamic projected arrival date; and transmitting the notification to a user within the enterprise. (Cova e.g. Techniques for monitoring and tracking assets and providing notifications to users are disclosed (Abstract). During the journey, the tag 114 can be programmed to wake up periodically, initiate communication with the tag provider 106, and send event notifications to the tag provider 106 [0021]. As the asset continues on its journey, the tag periodically generates tracking event notifications associated with tracking events (e.g., tracking events 408, 410, 412, 414, and 418) [0050].These event notifications provide updates on the current location of the asset, and can be used by the system to obtain useful information such as the path that the asset has traveled from its origin, remaining distance or estimated time to the destination, and the current location of the asset [0050]. In some implementations, the user notification also includes a dynamic estimated time of arrival for the asset, calculated, for example, from the data received about the asset's journey and historical lead time information gathered from past journeys along the same route [0098]. In some implementations, the user notification includes one or more supply chain management statistics [0100]. Examples of supply chain management statistics include, but are not limited to, estimated time of arrival for inventory, lead time, fulfillment risk, demand and supply balance, products inbound, perfect order fill rate, shipment fill rate, on-time shipment rate, on-time arrival rate, amount ordered, amount shipped, amount arrived, inventory in-transit, and carrier and vendor performance scorecards [0104].)
As per claim 15 (Currently Amended), Cova in view of Abuhab and Jenkins teach the system of claim 12, further comprising instructions causing the enterprise computing system to:
Cova teaches identifying one or more items as being at risk of late delivery (Cova e.g. Practical, timely statistics can be generated to allow end users to identify, and solve, potential problems. For example, useful statistics such as actual lead-times, fulfillment risk, dynamic estimated time of arrival, inventory status, demand and supply balance, and carrier and vendor scorecards can be calculated [0008]. Fulfillment risk is what an end user stands to lose when orders are not fulfilled on time (e.g., by the time agreed upon by the seller and purchaser). The system can label a given order and/or asset according to the probability that it will not be fulfilled. For example, the system can label the order/asset as one of "likely late," "past due," "exception," or "on time". An orders/asset is "likely late" when the dynamic estimated time of arrival for the order/asset is after the time the order/asset is supposed to arrive. An order/asset is "past due" when it is already past the time the order/asset is supposed to arrive. An order/asset has an "exception" when a security and/or environmental event occurred during the journey. Once the orders and/or assets are labeled, the system can allow end users to view the total dollar amount of the items in the orders and/or assets at risk for each label. For example, the system can calculate the total dollar amount that is "likely late." [0107].)
Cova nor Abuhab explicitly teach based on identifying one or more items as being at risk of late delivery, automatically assigning a second set of prioritized shipment tiers for the one or more items, the second set of prioritized shipment tiers indicating a higher priority than the first set of prioritized shipment tiers.
However, Jenkins automatically assigning a second set of prioritized shipment tiers for the one or more items, the second set of prioritized shipment tiers indicating a higher priority than the first set of prioritized shipment tiers; (Jenkins e.g. See claim 12 response. & Five options on the automated load builder 310 dialog allow the user to define the priority for adding shipments to a partially filled load. Each of these options has either a reward or penalty associated with it [0270]. The automated load builder 310 calculates a priority value for each recommended shipment between the source and destination it is working with by adding values for rewards and subtracting values for penalties. The recommended shipment having the highest value is added to the load first, followed by the next highest value, and so on [0270]. The recommended shipment with the highest priority is added to the load first. Every time the automated load builder 310 adds a shipment to a load, it automatically recalculates priority values and resorts recommended shipments by priority. Reprioritizing the shipments optimizes the load, since the priorities guide the algorithm into generating better quality loads [0272].)
Cova in view of Abuhab and Jenkins teach automatically transmitting a second instance of prioritized shipment information to the overseas transportation management system; (See claim 12 response.)
Cova in view of Abuhab and Jenkins teaches selecting one or more second overseas carriers for transport of the one or more items within the set of pending purchase orders (See claim 12 response.), Cova in view of Abuhab and Jenkins teach based on the one or more second overseas carriers being associated with a lower second dynamic lead time than the first lower dynamic lead time associated with the first overseas carriers; and
Cova teaches providing vendor/carrier lead time performance statistics (Cova e.g. Practical, timely statistics can be generated to allow end users to identify, and solve, potential problems. For example, useful statistics such as actual lead-times, fulfillment risk, dynamic estimated time of arrival, inventory status, demand and supply balance, and carrier and vendor scorecards can be calculated [0008]. The system generates one or more supply chain management statistics using the enterprise data and the tag data for each asset (906) [0104]. Examples of supply chain management statistics include, but are not limited to, estimated time of arrival for inventory, lead time, fulfillment risk, demand and supply balance, products inbound, perfect order fill rate, shipment fill rate, on-time shipment rate, on-time arrival rate, amount ordered, amount shipped, amount arrived, inventory in-transit, and carrier and vendor performance scorecards [0104]. The carrier scorecards indicate the performance of carriers over time. For example, the scorecard can calculate one or more of the statistics described above, such as lead time, for assets carried by a particular carrier and provide the statistics to the end user as an overview of the carrier's effectiveness. Similarly, vendor scorecards can be generated with vendor-specific statistics [0112].)
Cova nor Abuhab explicitly teach, however, Jenkins teaches selecting carriers based on needed and/or scheduled arrival dates that includes lead time (Jenkins e.g. The planning component 210 works with five dates when it recommends shipments: available to ship date, needed arrival date, scheduled arrival date, needed shipping date, and scheduled shipping date [0216]. The user also can tell the automated load builder 310 to use the Scheduled Arrival Date instead of the needed arrival date to determine the date on which a shipment must be delivered at a destination [0265]. The scheduled arrival date is typically the scheduled shipping date plus the lead time, plus any time required for an arrival calendar adjustment [0164]. In trying to build complete loads, the automated load builder 310 may add recommended shipments to the load whose Needed Arrival Date falls after the load is scheduled to arrive at the destination. Automated load builder 310 calculates the earliest arrival date for a recommended shipment as NeedArrivdate minus Look Ahead Days [0267]. The automated load builder 310 finds the optimal load configuration by attempting to place all recommended shipments on all available alternate carriers [0276]. First, the automated load builder 310 selects target recommended shipments to start the load, sorts recommended shipments according to needed arrival date, and selects a target recommended shipment [0280]. Next, the automated load builder 310 selects the preferred transportation mode for the recommended shipment. Then, the automated load builder 310 creates a load using the selected transportation mode [0280]. The automated load builder 310 builds loads using the transportation mode(s) defined for the source and destination. The user can define alternate transportation modes for the automated load builder 310 to use in the event it cannot fill the load using the primary or preferred transportation mode [0273]. When the automated load builder 310 builds a load, it first tries to fill it using the preferred transportation mode. If it cannot fill the load using the preferred mode, it tries to fill the load using the mode with the next highest rank [0274].)
The Examiner submits that before the effective filing date, it would have been obvious to one of ordinary skill in the art to combine Cova in view of Abuhab’s system and method of monitoring/tracking assets (e.g. overseas imports) and providing carrier/vendor lead time performance with Jenkin’s system and method of prioritizing shipments and selecting carriers based on arrival dates in order to allow a user to orchestrate the time-phased storage and flow of supply to match demand by creating an optimal inventory strategy that includes deployment plans, master production schedules, and procurement requirements (Jenkins e.g. [0013]).
Cova in view of Abuhab and Jenkins teach scheduling the one or more second overseas carriers for transport of the one or more items within the set of pending purchase orders. (See claim 12 response.)
As per claim 16 (Original), Cova in view of Abuhab and Jenkins teach the system of claim 15, Cova teaches wherein the one or more second overseas carriers are different than the first overseas carriers. (Cova e.g. Practical, timely statistics can be generated to allow end users to identify, and solve, potential problems. For example, useful statistics such as actual lead-times, fulfillment risk, dynamic estimated time of arrival, inventory status, demand and supply balance, and carrier and vendor scorecards can be calculated. These statistics can be used to improve supply chain performance and help end users make decisions about their supply chain, such as which ports and which carriers to use [0008]. Enterprise data can also include forecasting and planning information for the enterprise, supplier and vendor information, pricing information, and third party information such as information on end customers of the end user, carriers, forwarding agents, and logistics providers [0089]. FIG. 1 illustrates an example buyer 102, seller 104, and tag provider 106 interacting in a shipping scenario. An example asset 108 is shipped from the seller 104 to the buyer 102 on an example conveyance 110 [0019]. Examples of conveyances include, but are not limited to, trucks, trains, ships, and airplanes. Examples of assets include, but are not limited to, containers such as dry-van containers, refrigerated containers, ISO tanks, trailers, box trucks, and unit load devices (ULDs) [0019]. The multi-modal carrier status updates are updates from the conveyances used to transport the asset (e.g., the status of a ship carrying the asset). The multi-modal carriers status updates can include, for example, the status of a conveyance carrying the asset as well as conveyance stow plans indicating where assets are stored on a particular conveyance [0085].)
Conclusion
The closest prior art(s) to the claimed invention recited in claims 1-10 and 20 includes Jenkins et al. (US 2002/0188499 A1) “System and Method for Ensuring Order Fulfillment”, Cova et al. (US 2012/0303498 A1) “Asset Monitoring and Tracking System”, Abuhab (US 2020/075465 A1) “Distributed Shipment Prioritization Computing System”, and Hodge et al. (US 7,801,640 B1) “Continuous Item Picking In A Distribution Center Using Coordinated Item Picking Periods”. However, none of the prior art(s) alone or in combination teach the claimed invention as detailed in independent claims 1-10 and 20.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ayanna Minor whose telephone number is (571)272-3605. The examiner can normally be reached M-F 9am-5 pm.
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, Jerry O'Connor can be reached at 571-272-6787. 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.
/A.M./Examiner, Art Unit 3624
/Jerry O'Connor/Supervisory Patent Examiner,Group Art Unit 3624