DETAILED ACTION
Status of Claims
This action is in reply to the Applicant Remarks and Amendments filed on 11/06/2025.
Claims 7-16 have been elected by Applicant and are hereby entered.
Claims 7-16 are currently pending and have been examined.
This action is made NON-FINAL.
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 .
Election/Restrictions
Applicant’s election without traverse of Claims 7-16 in the reply filed on 11/06/2025 is acknowledged.
Claim Objections
Claim 16 is objected to because of the following informalities: there is a typo – “The method of claim 14” which should recite as “The method of claim 15”. Appropriate correction is required.
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 7-16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 7-16 are directed to one of the four statutory categories (process, machine, article of manufacture, or composition of matter) since the claimed invention falls into “a process” (a method for improving user experience during an electronic transaction for a package delivery) and “a machine” (systems for initiating a package delivery order in real time) categories.
Regarding Claims 7-16, the claim invention is directed to a judicial exception to patentability, an abstract idea.
Claim 7 recites the following limitations:
A distributed e-package delivery system for initiating a package delivery order in real time, comprising:
… are configured to:
a) receive a delivery work request from a sender;
b) receive information related to one or more delivery work plans from all available sources,
c) select a best delivery work plan option based on time, cost and a sender’s requirements,
d) provide in real-time the best delivery work plan and a corresponding price to the sender,
e) confirm the delivery work plan with the sender,
f) create the delivery work order,
g) complete the transaction with the sender,
h) dispatch the delivery work order to at least one … of at least one assigned mobile worker,
i) track a status of the delivery work order in real time and respond to any inquiry from the sender, and
j) record completion of the delivery work order or enter an exception into a handling procedure.
Step 2A, Prong 1: The limitations for Claim 7 described above are processes that, under their broadest reasonable interpretation, cover concepts that involve commercial interactions. The limitations of receiving, selecting, providing, confirming, creating, completing, dispatching, tracking, and recording completion of the delivery work order are processes that, under their broadest reasonable interpretation, cover concepts that involve a commercial interaction such as managing business relations between customers and delivery drivers. Therefore, other than reciting a generic computerized system, a generic database, and generic user devices, nothing in the claim elements preclude anything outside the grouping of “Certain Methods of Organizing Human Activity”. Accordingly, this claim recites an abstract idea.
Step 2A, Prong 2: This judicial exception is not integrated into a practical application. Claim 7 recites additional elements – “at least one processor; at least one memory in communication with the processor; and at least one network connection from a central cloud server to an electronic device at an end-user location, said memory tangibly storing instructions, which when executed by the processor” and “mobile device”. The claim as a whole merely describes how to generally “apply” the concept of receiving, selecting, providing, confirming, creating, completing, dispatching, tracking, and recording completion of the delivery work order by using generic computer components. The claimed computer components are recited at high level of generality and merely invoked as a tool to perform a process for initiating a package delivery order in real time (See MPEP 2106.05(f)). Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. This claim is directed to an abstract idea.
Step 2B: Claim 7 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a computer system to perform a process for initiating a package delivery order in real time amount to no more than how to generally “apply” the exception using a generic computer component (See MPEP 2106.05(f)). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. As a result, this claim is not patent eligible.
Claims 8-10 are directed to substantially the same abstract idea as Claim 7 and are rejected for substantially the same reasons. The additional recited limitations of the dependent claims fail to establish that the claims do not recite an abstract idea because the additional recited limitations of the claims further narrow the abstract idea. These dependent claims further narrow the abstract idea of Claim 7 such as by defining “comprising further … executable instructions to: interface with … that is configured to: k) query in real time all the options of available intercity transportation schedules and capacities, l) select the desired intercity transportation schedule and capacity, and m) confirm the selection” in Claim 8, by defining “comprising further … executable instructions to: manage in real time operation of mobile workers at local cities or regions; receive delivery work plan options for picking up the package from the sender and delivery to the receiver; and confirm availability and time of the mobile workers or alternative options thereof” in Claim 9, and by defining “comprising further … executable instructions to: create one or more records of the transaction” in Claim 10.
Step 2A, Prong 2: Claims 8-10 do not integrate the abstract idea into practical application. Claim 8 recites additional elements – “processor” and “an Intercity Transportation Resource Management System that has at least one processor, a memory, and a network connection”, and Claims 9-10 recite an additional element – “processor”. These additional elements amount to no more than mere instructions to apply the exception using generic computer components. The limitations of these dependent claims do not integrate an abstract idea into a practical application because individually or in combination, these additional elements do not impose any meaningful limits on a practicing the abstract idea and amount to no more than mere instructions to apply the exception using a generic computer component (See MPEP 2106.05(f)).
Step 2B: Claims 8-10 do not amount to significantly more than the abstract idea. Claims 8-10 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a computer system to perform a process for initiating a package delivery order in real time amount to no more than how to generally “apply” the exception using a generic computer component (See MPEP 2106.05(f)). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Therefore, these claims are not patent eligible.
Claim 11 recites the following limitations:
The distributed e-package delivery system of claim 7, wherein the one or more records are of a sender’s orders, of a sender’s payments, of a sender’s confirmation messages, or of terms and conditions of the package delivery order.
Claim 11 is directed to substantially the same abstract idea as Claim 7 and is rejected for substantially the same reasons. The additional recited limitations of the dependent claim fail to establish that the claim does not recite an abstract idea because the additional recited limitations of the claim further narrow the abstract idea.
Step 2A, Prong 2: This dependent claim does not integrate the abstract idea into practical application because it does not recite additional elements.
Step 2B: This dependent claim does not amount to significantly more than the abstract idea because it does not recite additional elements. Therefore, this claim is not patent eligible.
Claim 12 recites the following limitations:
A distributed cloud computer system, comprising the distributed e-package delivery system of claim 7 … configured to initiate and process a package delivery order in real time.
Claim 12 is rejected as Claim 7 (See 101 rejection above in Claim 7). Additionally, Claim 12 recites an additional element – “installed on a computer as a platform”. This additional element amounts to no more than mere instructions to apply the exception using generic computer components. The limitations of this claim do not integrate an abstract idea into a practical application because individually or in combination, this additional element does not impose any meaningful limits on a practicing the abstract idea and amount to no more than mere instructions to apply the exception using a generic computer component (See MPEP 2106.05(f)).
Claims 13 and 14 are directed to substantially the same abstract idea as Claim 12 and are rejected for substantially the same reasons. The additional recited limitations of the dependent claims fail to establish that the claims do not recite an abstract idea because the additional recited limitations of the claims further narrow the abstract idea. These dependent claims further narrow the abstract idea of Claim 12 such as by defining “wherein the distributed e-package delivery system is …” in Claim 13 and by defining “wherein … is … for customer services; … for local mobile workers; and … for mobile workers which is … for local mobile workers” in Claim 14.
Step 2A, Prong 2: Claims 13 and 14 do not integrate the abstract idea into practical application. Claim 13 recites additional elements – “a virtual sorting and distribution system comprising a virtual sorting and distribution system engine with direct electronic connections to: a website and mobile app for customer services; a distributed internet services (DIS) system; a transaction support system; an Intercity Transportation Resource Management System; and a management system for local mobile workers”, and Claim 14 recites additional elements – “the DIS system” and “directly electronically connected to: the website and mobile app…; the management system …; and the mobile app … which is directly electronically connected to the management system”. These additional elements amount to no more than mere instructions to apply the exception using generic computer components. The limitations of these dependent claims do not integrate an abstract idea into a practical application because individually or in combination, these additional elements do not impose any meaningful limits on a practicing the abstract idea and amount to no more than mere instructions to apply the exception using a generic computer component (See MPEP 2106.05(f)).
Step 2B: Claims 13 and 14 do not amount to significantly more than the abstract idea. Claims 13 and 14 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a computer system to perform a process for initiating a package delivery order in real time amount to no more than how to generally “apply” the exception using a generic computer component (See MPEP 2106.05(f)). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Therefore, these claims are not patent eligible.
Claim 15 recites the following limitations:
A method for improving user experience during an electronic transaction for a package delivery, comprising the steps of:
receiving a user inquiry as input into … of claim 7;
…; and
displaying, in real time, a response to the inquiry to the user, thereby improving the user experience.
Step 2A, Prong 1: The limitations for Claim 15 described above are processes that, under their broadest reasonable interpretation, cover concepts that involve commercial interactions. The limitations of receiving and presenting a response to the inquiry to the user are processes that, under their broadest reasonable interpretation, cover concepts that involve a commercial interaction such as managing business relations between customers and delivery drivers. Therefore, other than reciting a generic computerized system, a generic database, and generic user devices, nothing in the claim elements preclude anything outside the grouping of “Certain Methods of Organizing Human Activity”. Accordingly, this claim recites an abstract idea.
Step 2A, Prong 2: This judicial exception is not integrated into a practical application. Claim 15 recites additional elements – “an e-commerce system networked to a central cloud server comprising the distributed e-package delivery system” and “processing the inquiry with an application or components thereof distributed and deployed to a local server on the distributed e-package delivery system from the central cloud server via a Distributed Internet Services system thereon”. The claim as a whole merely describes how to generally “apply” the concept of receiving and presenting a response to the inquiry to the user by using generic computer components. The claimed computer components are recited at high level of generality and merely invoked as a tool to perform a process for improving user experience during an electronic transaction for a package delivery (See MPEP 2106.05(f)). Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. This claim is directed to an abstract idea.
Step 2B: Claim 15 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a computer system to perform a process for improving user experience during an electronic transaction for a package delivery amount to no more than how to generally “apply” the exception using a generic computer component (See MPEP 2106.05(f)). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. As a result, this claim is not patent eligible.
Claim 16 recites the following limitations:
The method of claim [15], wherein the response comprises a real time offer of package delivery work plan options and corresponding fees.
Claim 16 is directed to substantially the same abstract idea as Claim 15 and is rejected for substantially the same reasons. The additional recited limitations of the dependent claim fail to establish that the claim does not recite an abstract idea because the additional recited limitations of the claim further narrow the abstract idea.
Step 2A, Prong 2: This dependent claim does not integrate the abstract idea into practical application because it does not recite additional elements.
Step 2B: This dependent claim does not amount to significantly more than the abstract idea because it does not recite additional elements. Therefore, this claim is not patent eligible.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 7 and 10-16 are rejected under 35 U.S.C. 102(a)(1) as being clearly anticipated by Gorlin; Marc (US PG Pub. No. 2016/0019496 A1; hereinafter "Gorlin").
Regarding Claim 7, Gorlin teaches a distributed e-package delivery system for initiating a package delivery order in real time, comprising: at least one processor; at least one memory in communication with the processor; and at least one network connection from a central cloud server to an electronic device at an end-user location, said memory tangibly storing instructions, which when executed by the processor are configured to (See Figs. 5, 26, and 27, “FIG. 5 is a block diagram illustrating participants of the system on a computer communications network, according to an embodiment.” in Paragraph [0143], “The processing unit 2600 can also be connected to a network connection 2603, which can connect the processing unit to a computer communications network such as the Internet, a LAN, WAN, etc. The processing unit 2600 is also connected to a RAM 2604 and a ROM 2605. The processing unit 2600 can also be connected to a storage device 2606 which can be a DVD-drive, CD-ROM drive, flash memory, etc. A non-transitory computer readable storage medium 2607 (CD-ROM DVD, flash memory, RAM, etc.) can store a program which can control the processing unit 2600 to perform any of the methods/features described herein and can be read by the storage device 2606.” in Paragraph [0258], and “Note that “server” as used herein refers to server 504 (which is also illustrated in more detailed as the production system 2700 in FIG. 27) which is maintained and configured by the entity that controls the entire peer to peer shipping system. This server can be programmed to perform all of the methods/features described herein including causing remote devices to perform and/or display any and all of the methods/features described herein. While the server 504 is illustrated as a single unit, it can be appreciated that this server can actually comprise more than one server operating together (either physically in the same location or different location with a virtual connection via the Internet or other computer communications network). Note that different devices can operate collaboratively to implement any features described herein.” in Paragraph [0339]): a) receive a delivery work request from a sender (See “In operation 200, a sender enters a request for a delivery to be made from a pick-up address (typically the sender's address although this is not required) and a destination address.” in Paragraph [0146] and see “200” in Fig. 6); b) receive information related to one or more delivery work plans from all available sources (See “When a user (sender, receiver, manager) makes a new request to send (deliver) a package, the system first identifies all of the potential participating drivers and their locations in order to identify which drivers are the best candidates for being the driver for this particular request. Then, and the request will then be broadcast to all drivers based on location and availability in addition to being queried by potential drivers if none are available at the moment.” in Paragraph [0114]), c) select a best delivery work plan option based on time, cost and a sender’s requirements, d) provide in real-time the best delivery work plan and a corresponding price to the sender, e) confirm the delivery work plan with the sender (See “A user (e.g., sender, receiver, manager) can log into the system using their mobile device or any web browser, request that a package be picked up at a certain location and dropped off at a certain location, and the system will locate a group of suitable drivers and present the option for the sender and receiver (recipient) to double accept (both agree to terms of trip and price although in another embodiment only one party needs to accept the price since they would be paying), and arrange for the package to be picked up and delivered.” in Paragraph [0113], “FIG. 2 is a flowchart illustrating an exemplary method of selecting a deliverer, according to an embodiment. A deliverer is the driver that is going to make the actual delivery of the package. The deliverer is selected out of all of the participating drivers as the most logical driver for the job. In one embodiment, the deliver that is selected can take on the task without the sender's approval, while in another embodiment the sender (sender) would need to approve the assignment of the particular deliverer for the task. A plurality of potential deliverers can be selected (the best ones for the task) and the sender (or manager or receiver) can select which of the potential deliverers he/she wishes to utilize for the task.” in Paragraph [0121], “If in operation 203, the potential deliverer (the one prompted in operation 202) agrees to make the delivery, then the method proceeds to operation 204, which then proceeds to operation 204, which prompts the sender to confirm they approve of the potential deliverer delivering the sender's package. The sender would be presented with the identification of the potential deliverer (e.g., a picture, name, etc.) and the sender can confirm (by clicking a button) whether he accepts this potential deliverer (upon which the method proceeds to operation 206) or declines (upon which the method returns to operation 201 wherein another potential deliverer can be selected).” in Paragraph [0126], “FIG. 18 is a flowchart illustrating an exemplary method of identifying compatible delivery tasks based on predictive routes, according to an embodiment. Compatible delivery tasks are prompted to the driver so the driver can accept the tasks if he/she chooses.” in Paragraph [0206], “The current server would be queried using the potential routes to retrieve any delivery tasks which meet the criterion being used. If no such compatible tasks exist at the current time then no delivery tasks would be prompted to the driver in operation 1804. If too many compatible delivery tasks exist then the set can be reduced, for example, by taking the best 5 (that have the lowest additional miles or time required for the driver).” in Paragraph [0216], and Fig. 8), f) create the delivery work order (See “If the sender agrees in operation 205 to accept the potential deliverer (see FIG. 8), then the method proceeds to operation 206, which initiates delivery (starts operation 300).” in Paragraph [0127]), g) complete the transaction with the sender (See “Note that the sender has to pay for the delivery, although the receiver of the package or a manager who arranged the delivery can also be responsible for payment. A manager can be someone besides the sender, deliverer, and driver who is a person who has authority to arrange for delivers (and would arrange for payment of them as well). For example, a manager can be employed by a company who utilizes the delivery system described herein for the company's shipments and would make all arrangements for them to be delivered accordingly and make payment as well. A credit card (or other payment mechanism) can be associated with the manager (or sender or receiver) to easily pay for deliveries… The sender can pay now (upon initiation of the service) or upon completion of the delivery… The sender can pay using their mobile device and or web site, and can pay by any electronic payment mechanism (bank account transfer, SQUARE CASH, credit card, PAYPAL, etc.)” in Paragraph [0127]), h) dispatch the delivery work order to at least one mobile device of at least one assigned mobile worker (See “In operation 300, the addresses of the pickup and drop-off (delivery) locations are transmitted to the deliverer. These may have already been transmitted in operation 202, but now the deliverer navigation system (which uses GPS or optimized geolocation tracking to tell the deliverer where to turn and how to find his/her way to the drop-off) receives these addresses so that the deliverer can easily navigate to the pick and drop-off locations (see operation 303).” in Paragraph [0130] and “From operation 302, the method proceeds to operation 303, which displays the route to the deliverer on a map on the deliverer's computing device (e.g., smart phone, etc.) This serves as a navigation system for the deliverer.” in Paragraph [0134]), i) track a status of the delivery work order in real time and respond to any inquiry from the sender (See “From operation 303, the method proceeds to operation 304, which monitors the progress of the deliverer. The location of the deliverer is transmitted in real time to the system (stored in a database) so that the system knows where the deliverer is at all times. If the deliverer deviates from his/her given route (to the drop-off location) then an alert can be triggered which can be handled in numerous ways (a text message or a call to the deliverer on the deliverer's cell phone can be made, etc.) The real-time location of the deliverer will also be displayed (in a map or coordinates) to the manager, the sender and the receiver (the person to whom the drop-off is intended to be made).” in Paragraph [0135], “The sender, receiver or manager can also call the deliverer (or vice-versa) by pressing a button the sender's screen which will call the deliverer's cell phone in case the sender wishes to contact the deliverer for any reason.” in Paragraph [0136], and “The system tracks all statuses of tasks like this and will store the driver's current status of being present at the pickup location. The party who will be providing the package to the driver/deliverer at the pickup location (typically the sender) will be notified (e.g., via text message, etc.) that the driver is present at the pickup location.” in Paragraph [0334]), and j) record completion of the delivery work order or enter an exception into a handling procedure (See “The server records that the delivery has taken place (verifies delivery).” in Paragraph [0185] and “In operation 1504, a result of this transaction is recorded at the server. If the key pressed by the receiver in operation 1503 indicates a successful delivery (e.g., ‘1’) then the server records that the package was delivered successfully. If the key pressed by the received in operation 1503 indicates that the package was not received (or no key at all is pressed), then the server would record that the package was not delivered successfully (and appropriate action can be taken, such as launching an investigation to track down the package).” in Paragraph [0191]).
Regarding Claim 10, Gorlin teaches all the limitations of Claim 7 as described above. Gorlin also teaches comprising further processor executable instructions to: create one or more records of the transaction (See “In operation 1504, a result of this transaction is recorded at the server. If the key pressed by the receiver in operation 1503 indicates a successful delivery (e.g., ‘1’) then the server records that the package was delivered successfully. If the key pressed by the received in operation 1503 indicates that the package was not received (or no key at all is pressed), then the server would record that the package was not delivered successfully (and appropriate action can be taken, such as launching an investigation to track down the package).” in Paragraph [0191]).
Regarding Claim 11, Gorlin teaches all the limitations of Claim 7 as described above. Gorlin also teaches wherein the one or more records are of a sender’s orders, of a sender’s payments, of a sender’s confirmation messages, or of terms and conditions of the package delivery order (See “From operation 301, the method proceeds to operation 302, which stores the task (the details of the shipment which can comprise the identity of the sender, the identity of the deliverer, the pickup location, the drop-off location, the size of package, weight of package, picture of package etc.)” in Paragraph [0132], “In operation 1504, a result of this transaction is recorded at the server. If the key pressed by the receiver in operation 1503 indicates a successful delivery (e.g., ‘1’) then the server records that the package was delivered successfully. If the key pressed by the received in operation 1503 indicates that the package was not received (or no key at all is pressed), then the server would record that the package was not delivered successfully (and appropriate action can be taken, such as launching an investigation to track down the package).” in Paragraph [0191], and “FIG. 46 is an exemplary mobile device screen illustrating a screen to capture a sender's credit card information, according to an embodiment. A picture of the credit card can be taken, the data optically recognized, and auto-filled into the application (e.g., credit card number, expiration date, etc.)” in Paragraph [0281]).
Regarding Claim 12, Gorlin teaches a distributed cloud computer system, comprising the distributed e-package delivery system of claim 7 installed on a computer as a platform configured to initiate and process a package delivery order in real time (See Claim 7 rejection above and “FIG. 26 is a block diagram illustrating one example of computer hardware that can be used to implement any computer used, according to an embodiment. The computer can also be any computing device, such as the server, cellular phone, GPS device, portable computing device, personal computer, tablet, etc. All of the methods/features described herein can be performed by a program that can be installed as software (e.g., an app) on the device. FIG. 26 can be considered an electrical circuit” in Paragraph [0257]).
Regarding Claim 13, Gorlin teaches all the limitations of Claim 12 as described above. Gorlin also teaches wherein the distributed e-package delivery system is a virtual sorting and distribution system comprising a virtual sorting and distribution system engine with direct electronic connections to: a website and mobile app for customer services; a distributed internet services (DIS) system; a transaction support system; an Intercity Transportation Resource Management System; and a management system for local mobile workers (See “In an embodiment, senders (senders) and/or receivers would not need to register an account, they can simply use a web site (or web links) to enter their shipment information without registering an account (e.g., they are a “guest”) and web links and text messages can be used to guarantee identify and chain of custody of a package” in Paragraph [0116], “FIG. 27 FIG. 27 is a block diagram illustrating the system and more particularly a production system, according to an embodiment. A production system 2700 is a secure system and what implements the entire system and communicates with all users over the internet. The productions system 2700 can be considered to be an electrical circuit.” in Paragraph [0260], “Application servers 2701 serve all of the downloads, communications, etc., to all of the users to the internet and also receive all communications from the users. Persistent storage 2702 stores data for all current processes and operations and other temporary and permanent data. A data warehouse 2703 stores long term data, such as all user location history (and any other data described herein). All components can communicate with one another even though such communications are not explicitly shown” in Paragraph [0261], “The sender can pay using their mobile device and or web site, and can pay by any electronic payment mechanism (bank account transfer, SQUARE CASH, credit card, PAYPAL, etc.) The deliverer will be paid for the delivery, typically the amount that the sender pays with a percentage taken out (which is the commission kept by the company that administers the delivery system described herein).” in Paragraph [0127], and “Note that “server” as used herein refers to server 504 (which is also illustrated in more detailed as the production system 2700 in FIG. 27) which is maintained and configured by the entity that controls the entire peer to peer shipping system. This server can be programmed to perform all of the methods/features described herein including causing remote devices to perform and/or display any and all of the methods/features described herein. While the server 504 is illustrated as a single unit, it can be appreciated that this server can actually comprise more than one server operating together (either physically in the same location or different location with a virtual connection via the Internet or other computer communications network). Note that different devices can operate collaboratively to implement any features described herein. For example a first processing unit on a mobile phone displays a GPS map which is in communication with a second processing unit on the server which transmits data to the mobile phone (e.g., suggested delivery tasks, etc.) which can appear on the GPS. Thus, multiple processors are working together in order to effectuate any and all of the methods/features described herein. Note that any methods/features can also be performed by an app (e.g., software running on a portable computing device such as a cell phone) and any methods/features can also be running on the server, or methods/features can be split up in any combination between portable computing device and server. The word “causing” as used herein, can also comprise providing software/instructions to run on portable computing devices and also providing signals to the portable computing devices to take certain actions, even though these devices may be physically separate from the server. Thus, all of the methods/features herein are essentially caused by the server and any entity operating the server (which may distribute software for portable computing devices which allow the server to cause any methods/features on the portable computing devices).” in Paragraph [0339]).
Regarding Claim 14, Gorlin teaches all the limitations of Claims 12 and 13 as described above. Gorlin also teaches wherein the DIS system is directly electronically connected to: the website and mobile app for customer services; the management system for local mobile workers; and the mobile app for mobile workers which is directly electronically connected to the management system for local mobile workers (See “In an embodiment, senders (senders) and/or receivers would not need to register an account, they can simply use a web site (or web links) to enter their shipment information without registering an account (e.g., they are a “guest”) and web links and text messages can be used to guarantee identify and chain of custody of a package.” in Paragraph [0116], “The sender can pay using their mobile device and or web site, and can pay by any electronic payment mechanism (bank account transfer, SQUARE CASH, credit card, PAYPAL, etc.) The deliverer will be paid for the delivery, typically the amount that the sender pays with a percentage taken out (which is the commission kept by the company that administers the delivery system described herein).” in Paragraph [0127], “FIG. 27 FIG. 27 is a block diagram illustrating the system and more particularly a production system, according to an embodiment. A production system 2700 is a secure system and what implements the entire system and communicates with all users over the internet. The productions system 2700 can be considered to be an electrical circuit.” in Paragraph [0260], “Application servers 2701 serve all of the downloads, communications, etc., to all of the users to the internet and also receive all communications from the users. Persistent storage 2702 stores data for all current processes and operations and other temporary and permanent data. A data warehouse 2703 stores long term data, such as all user location history (and any other data described herein). All components can communicate with one another even though such communications are not explicitly shown” in Paragraph [0261], and “All drivers (deliverers) should have a mobile phone (also referred to as portable computing device) that is capable is communicating wirelessly (e.g., cell phone calls) and also capable of download and running apps (such as an app programmed specifically to implement all features described herein) can also send/receive any type of data (including images, numbers, etc.) This type of mobile phone (that drivers should have) is commonly referred to as a “smart phone.” It is encouraged that other parties in the system (e.g., managers, receivers, senders) also have smart phones but it is not required.” in Paragraph [0340]).
Regarding Claim 15, Gorlin teaches a method for improving user experience during an electronic transaction for a package delivery, comprising the steps of: receiving a user inquiry as input into an e-commerce system networked to a central cloud server comprising the distributed e-package delivery system of claim 7 (See Claim 7 rejection above and “In operation 200, a sender enters a request for a delivery to be made from a pick-up address (typically the sender's address although this is not required) and a destination address. Also included in the request is information about the package to be delivered, such as the dimensions and weight of the package. A dialogue box such as that illustrated in FIG. 6 can be used, where the sender types in all of the answers to each of the fields. Note that this is just one example, and any other fields can be used as well. Note that the sender can also take a picture of the package with the sender's sell phone and upload it so that potential deliverers can see the size of the package. A category field can also be inputted from the sender (and displayed to the potential delivers). Categories can comprise electronics, perishables, etc. All known information about a package would be displayed to potential deliverers.” in Paragraph [0146]); processing the inquiry with an application or components thereof distributed and deployed to a local server on the distributed e-package delivery system from the central cloud server via a Distributed Internet Services system thereon (See “Drivers 500, 501 can communicate with a server 504 (also referred to herein as the system) using their mobile phones (or other portable computing devices such as laptops, etc.) The server 504 communicates with all of the participants of the system and directs all features herein Senders 502,503 use their computers, mobile phones, etc. to communicate with the server 504 (senders can also use mobile phones as well). All information herein can be transmitted by any party described herein and received by any party described herein including the server 504. It can be appreciated that any number of users (e.g., drivers, senders, receivers, managers, etc.) can utilize the system simultaneously even though all such parties are typically in different physical locations throughout the country. For example, there can be 10, over 10, 10-100, over 100, 1000, over 1000, or any number (from 1 to a million or more) of simultaneous users (with any number of drivers, senders, receivers, managers, etc.) of the system which are all processed virtually simultaneously. For example, there can be 1-100 or more drivers being location tracked at one time and the server 504 will process the tracking of all such drivers simultaneously even though they are located all over the country.” in Paragraph [0144], “Note that any methods/features can also be performed by an app (e.g., software running on a portable computing device such as a cell phone) and any methods/features can also be running on the server, or methods/features can be split up in any combination between portable computing device and server.” in Paragraph [0339], and “All drivers (deliverers) should have a mobile phone (also referred to as portable computing device) that is capable is communicating wirelessly (e.g., cell phone calls) and also capable of download and running apps (such as an app programmed specifically to implement all features described herein) can also send/receive any type of data (including images, numbers, etc.) This type of mobile phone (that drivers should have) is commonly referred to as a “smart phone.” It is encouraged that other parties in the system (e.g., managers, receivers, senders) also have smart phones but it is not required.” in Paragraph [0340]); and displaying, in real time, a response to the inquiry to the user, thereby improving the user experience (See Fig. 8, “FIG. 8 is an example of a dialogue box which illustrates a confirmation query so the sender can approve the selection of the potential deliverer, according to an embodiment.” in Paragraph [0149], and “The sender is presented (operation 205) with the identity of the potential deliverer so that the sender can then approve or decline this particular potential deliverer. If the sender does not approve of this particular deliverer, then the system can find another potential deliverer (return to operation 201). In one embodiment, for privacy reasons the information about a potential deliverer presented to the sender (or other party who is arranging for shipment of the package such as a manager or sender) is limited (such as only displaying a username, location, reviews from other users of the system, etc.) In another embodiment, all details about a potential deliverer can be presented to the sender (including the potential deliverer's real name, photo, reviews by other users who have used this particular deliverer, average rating, etc.). Each receiver who receives a package delivered by the deliverer can write a review and also give a star rating (e.g., out of four stars with four being the best) and all of a deliverer's star ratings can be averaged and displayed to other users of the system such as future senders they can utilize this information when making their choice of driver.” in Paragraph [0150]).
Regarding Claim 16, Gorlin teaches all the limitations of Claim 15 as described above. Gorlin also teaches wherein the response comprises a real time offer of package delivery work plan options and corresponding fees (See Fig. 8 which shows corresponding fees of $20, “FIG. 8 is an example of a dialogue box which illustrates a confirmation query so the sender can approve the selection of the potential deliverer, according to an embodiment.” in Paragraph [0149], and “The sender is presented (operation 205) with the identity of the potential deliverer so that the sender can then approve or decline this particular potential deliverer. If the sender does not approve of this particular deliverer, then the system can find another potential deliverer (return to operation 201). In one embodiment, for privacy reasons the information about a potential deliverer presented to the sender (or other party who is arranging for shipment of the package such as a manager or sender) is limited (such as only displaying a username, location, reviews from other users of the system, etc.) In another embodiment, all details about a potential deliverer can be presented to the sender (including the potential deliverer's real name, photo, reviews by other users who have used this particular deliverer, average rating, etc.). Each receiver who receives a package delivered by the deliverer can write a review and also give a star rating (e.g., out of four stars with four being the best) and all of a deliverer's star ratings can be averaged and displayed to other users of the system such as future senders they can utilize this information when making their choice of driver.” in Paragraph [0150]).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Gorlin in view of Gibbon et al. (US PG Pub. No. 2015/0348282 A1; hereinafter "Gibbon").
Regarding Claim 8, Gorlin teaches all the limitations of Claim 7 as described above. Gorlin does not explicitly teach; however, Gibbon teaches comprising further processor executable instructions to: interface with an Intercity Transportation Resource Management System that has at least one processor, a memory, and a network connection that is configured to: k) query in real time all the options of available intercity transportation schedules and capacities, l) select the desired intercity transportation schedule and capacity, and m) confirm the selection (See “In some embodiments, courier selection module 326 and/or on-demand pickup client application 106 can directly and/or indirectly query and/or write to one or more of data stores 354, 358, 362, 366 when implementing aspects of processes 1400. For example, courier selection module 326 and/or on-demand pickup client application 106 can directly and/or indirectly retrieve, update, and/or analyze information related to courier selection, such as courier and user information, in one or more of data stores 354, 358, 362, 366.” in Paragraph [0093], “Courier information 358 can include, for example, current and historical information related to couriers, such as personnel and/or equipment capacity and/or capability, as well as …, available schedules, coverage area, …, and/or the like. “Courier” as used herein can refer to an individual and/or company, organization, or group of individuals having personnel and/or equipment (e.g., vehicle) for picking up and/or transporting items, such as goods or documents. In some embodiments, couriers pick up items at a user's location (e.g., user's house or place of business), and transport those items to a packing-and-shipping location, where the items are packaged and shipped to an ultimate destination (e.g., handed off to a shipping company). Courier information 358 can include real-time and/or near real-time location and/or availability information. For example, such information can include a phone number, application identifier, and/or other information that enables real or near real-time tracking of a courier's location. The location could be expressed in terms of GPS location, address, city, state, region, and/or country. The location could also be the name or other identifying information of the business entity where the courier is located (e.g., currently picking up an item), such as a business, a restaurant, a venue, etc.” in Paragraph [0056], “Courier information 358 can also include information related to a courier's availability. Such information can include a list of the courier's recent pickups and scheduled future pickups, as well as information about the size and weight of the items at each pickup and/or information about the courier's capacity (i.e., aggregated size and weight of items the courier can carry at one time).” in Paragraph [0057], “Shipping information 362 can include cost and performance data for multiple shipping companies. “Shipping company” as used herein can refer to a company and/or organization that transporting items, such as goods or documents. In some embodiments, couriers transport items locally (e.g., intracity), whereas shipping companies transport items longer distances (e.g., intercity).” in Paragraph [0059], “In some embodiments, the image processing and item transport system can be configured to estimate a shipping cost and a transit time for shipping the item to the shipping destination, the shipping costing and the transit time being estimated based at least in part on the physical characteristic of the item and the shipping destination. In some embodiments, the image