DETAILED ACTION
In the response filed October 24, 2025, the Applicant amended claim 2. Claims 1-4, 6, and 8, are pending in the current application.
Notice of 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 .
Response to Arguments
The drawings were objected to for informalities. Examiner thanks the Applicant and hereby withdraws the objection from the previous Office action.
Applicant’s arguments for claims 1-4, 6, and 8, with respect to the 35 U.S.C. 101 rejection have been considered but are unpersuasive.
Applicant argues the Examiner has not established a prima facie case of subject matter ineligibility. Examiner respectfully disagrees. Per the guidance, the Examiner has specifically "identified the specific claim limitations" (see the quoted claim limitations that together comprise the abstract idea) and "explained why those claim limitations set forth a judicial exception" (see the comparison to the cases ruled on by the courts). The Examiner's characterization is in line with the guidance, and has provided explicit guidance to the Applicant, i.e., has identified exactly which claim elements/limitations are part of the identified abstract idea, and which claim elements/limitations are considered to be “additional elements.” Applicant’s arguments remain unpersuasive and as such, the 101 rejection is proper and maintained herein.
Applicant argues that the claims are not directed to a judicial exception. Examiner respectfully disagrees. Applicant argues that the claims are not directed to a judicial exception as they provide a technological solution to a technical problem. Examiner respectfully disagrees. In light of the rejections below under 35 U.S.C. 102 and 35 U.S.C. 103, the claims recite elements that were known at the time of the invention, and the elements are combined in such a way that is either anticipated or obvious in light of the prior art. The specific problem (determination of damage to goods) is not a problem specifically arising in the technical field of computer-implemented business methods. The fact that the generating, receiving, storing, validating, and providing of data is executed on a networked system does not somehow automatically make problem unique to the realm of computer networks. The fact that the determinations are made by a generic computer processor does not somehow automatically make the solution necessarily rooted in computer technology. The instant claims merely limit the use of the abstract idea to a particular environment - that being a computer environment. This same problem would exist in non-computer environments, and the same solution would be appropriate. Stripped of the generic computer elements recited in the claims, the problem and solution would remain intact. Limitations that link the use of a judicial exception to a particular technological environment or field of use do not qualify as "significantly more," and do not transform the judicial exception into patent-eligible subject matter.
Here, the alleged improvements are non-technical subjective/abstract improvements, not technical improvements to computers or technological processes, but addresses a business challenge regarding the monitoring of goods during shipment. Monitoring shipped goods to determine damage or mishandling is directed to, if anything, a business “improvement”. That a computer is used to generate and transmit data or “condition records” serves merely to implement the abstract idea on a generic computer.
These steps, under broadest reasonable interpretation, describe or set-forth validating and providing condition records of goods in transit for a user, which amounts to commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). These limitations therefore fall within the “certain methods of organizing human activity” subject matter grouping of abstract ideas.
The requirement to execute the claimed steps/functions using “a system for monitoring goods in transit, the system comprising: one or more user devices, each user device comprising one or more sensors,” and “a server device, communicatively coupled with the one or more user devices via one or more data communication networks,” (claim 1) and “a user interface” (claim 8), is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. These limitations do not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application. See § MPEP 2106.05(f).
Viewing the additional limitations in combination also shows that they fail to ensure the claims amount to significantly more than the abstract idea. When considered as an ordered combination, the additional components of the claims add nothing that is not already present when considered separately, and thus simply append the abstract idea with words equivalent to “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. While preemption is a concern when it comes to subject matter eligibility, the scope of an abstract idea is not of great significance. If a claim is directed to an extremely detailed and specific abstract, the claims must still contain claim elements that qualify as "significantly more" than the abstract idea itself (limitations that do more than merely further limit the scope of the abstract idea). Novelty and obviousness have not been identified as factors that transform an abstract idea into patent-eligible subject matter. These factors are relevant to patentability under 35 U.S.C. 102 and 103. Applicant’s arguments remain unpersuasive. The 35 U.S.C. 101 rejection is hereby maintained.
Applicant’s arguments for claims 1-4, 6, and 8, with respect to the 35 U.S.C. 102/103 rejections have been considered but are unpersuasive. Applicant argues that Morimoto does not disclose “one or more user devices.” Examiner respectfully disagrees. The claim language of the application do not require that the one or more user devices are specifically a laptop computer, tablet computer, smart phone, etc. Morimoto discloses one or more user devices (memory devices 50A-50N), each user device (one of memory devices 50A-50N) comprising one or more sensors configured to generate a condition record (Fig. 1 & 10; Par. [0011]). Even if Applicant’s characterization of “user devices” were applied, Morimoto still discloses one or more user devices comprising one or more sensors (Par. [0011], In one embodiment, the system may also include hand-held communicating device, with a display device, that allows the user to easily view the contents of the memory device. The hand-held device may also have an input device (e.g., a set of buttons or an entire keyboard) that allows the user to append and edit information for storage in the memory device. The hand-held device may also include a network interface configured to allow the hand-held device to send and receive to information from a computer network (e.g., the Internet)). Applicant’s argument remains unpersuasive.
Applicant argues that Morimoto does not disclose a “condition record.” Examiner respectfully disagrees. Morimoto explicitly discloses a data file (Par. [0011], [0012], [0039], [0056], etc. - The memory device may store shipping and insurance information related to the item being shipped in a data file. The memory device may include input devices and sensors to gather and store information before, during and after shipment. The data file may be updated by the memory device to reflect the changes). Here, Morimoto discloses the condition record and that condition record is updated with gathered and stored information during shipment such as location, condition, time, by the memory device. As explained above, if Applicant’s characterization of “user devices” were applied, Morimoto still discloses “a condition record” (data file) and the “generation” of a condition record (Par. [0063], The central server may also be configured to generate a data file that includes information about the goods to be shipped and the selected routing. As noted above, one embodiment of such a data file is shown in FIG. 4. This data file may be transmitted with the confirmation sent out by the central server in Step 114. The originating shipping company may update (if desired) and store a copy of the data file in the memory device). Applicant’s argument remains unpersuasive.
Applicant argues Morimoto does not disclose sending condition records to server. Examiner respectfully disagrees. Morimoto discloses the sending and receiving of updates to the data file and the maintenance of such records on a real time database (Par. [0064]). Applicant’s argument remains unpersuasive.
Applicant argues Morimoto does not disclose “the server device further configured to validate each of the first plurality of condition records by analyzing the time value and the location value of the respective condition record to correlate the respective condition record to the predetermined route of the first goods.” Examiner respectfully disagrees. Morimoto discloses verifying the status of the shipment (Par. [0075], central server 90 may be configured to receive updates at any time before, during or after the shipping process. This includes updates received from intermediate destinations (Step 180). Central server 90 may be configured to periodically check shipping schedules for subsequent intermediate destinations (Step 182) to verify the availability and/or feasibility of the future intermediate destination(Step 184 ) ... If, however, no issues concerning availability of shipment at intermediate destinations arise, or if no better alternatives are available, then the central server may simply be configured to communicate a verification of the original route to one or more of the parties to the shipping transaction (Stepl92); the system may verify [validate] the record using the location and time data during the shipping transit). The system in Morimoto explicitly discloses correlating or verifying a predetermined original route of the shipment to the updates of the shipment conditions and shipment information received from the devices monitoring the shipment. Applicant’s argument remains unpersuasive.
Applicant argues Maas does not teach “wherein each of the plurality of condition record comprise a plurality of customizable data fields that can be activated for inclusion in the condition record and deactivated for exclusion from the condition record.” Examiner respectfully disagrees. Maas teaches a record with an indication of condition and a plurality of customized fields; as there is no limit to the custom fields and only some fields are needed for shipping, if a field is used, then it is active, and if it is not used, it is not active – which means it can be activated or deactivated as recited in the claims (Par. [0073], An operator at the trade-in system 102 can then review the retrieved record and confirm that the item received matches the specifics of the record including item type, condition, etc.; an item [goods] can include a record with an indication of condition and a plurality of customized fields; as there is no limit to the custom fields and only some fields are needed for shipping, if a field is used, then it is active, and if it is not used, it is not active).
Applicant’s arguments remain unpersuasive and as such, the 35 U.S.C. 102 and 35 U.S.C. 103 rejection is hereby maintained.
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-4, 6, and 8 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1: Claims 1-4, 6, and 9 are drawn to a device, which is within the four statutory categories (e.g., a process, a machine). (Step 1: YES).
Step 2A – Prong One: In prong one of step 2A, the claims are analyzed to evaluate whether they recite a judicial exception.
Claim 1 recites/describes the following steps:
“…generate a condition record, the condition record comprising a time value, a location value, and a physical condition of goods, wherein the time value and the location value correspond to a predetermined route for transport of the goods between an origination point and a destination point;”
“…receive a first plurality of condition records from a plurality of the one or more user devices, each of the first plurality of condition records corresponding to a time value and a location value during transport of first goods on the predetermined route,”
“…store the first plurality of condition records in association with the first goods and in association with each other,”
“…validate each of the first plurality of condition records by analyzing the time value and the location value of the respective condition record to correlate the respective condition record to the predetermined route of the first goods;”
“…provide at least a portion of information from the first plurality of condition records in response to a request for transit information related to the first goods.”
These steps, under broadest reasonable interpretation, describe or set-forth validating and providing condition records of goods in transit for a user, which amounts to commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). These limitations therefore fall within the “certain methods of organizing human activity” subject matter grouping of abstract ideas.
As such, the Examiner concludes that claim 1 recites an abstract idea (Step 2A – Prong One: YES).
Each of the depending claims 2-4, 6, and 8 likewise recite/describe these steps (by incorporation - and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and these claims are therefore determined to recite an abstract idea under the same analysis. Any elements recited in a dependent claim that are not specifically identified/addressed by the Examiner under step 2A (prong two) or step 2B of this analysis shall be understood to be an additional part of the abstract idea recited by that particular claim.
Step 2A – Prong Two:
The claims recite the additional elements/limitations of: “a system for monitoring goods in transit, the system comprising: one or more user devices, each user device comprising one or more sensors,” and “a server device, communicatively coupled with the one or more user devices via one or more data communication networks,” (claim 1).
The claims also recite the additional elements/limitations of: “a user interface” (claim 8).
The requirement to execute the claimed steps/functions using “a system for monitoring goods in transit, the system comprising: one or more user devices, each user device comprising one or more sensors,” and “a server device, communicatively coupled with the one or more user devices via one or more data communication networks,” (claim 1) and “a user interface” (claim 8), is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. These limitations do not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application. See § MPEP 2106.05(f).
Remaining dependent claims 2-4 and 6 either recite the same additional elements as noted above or fail to recite any additional elements (in which case, note prong one analysis as set forth above – those claims are further part of the abstract idea as identified by the Examiner for each respective dependent claim).
The Examiner has therefore determined that the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application. Accordingly, the claims are directed to an abstract idea (Step 2A – Prong two: NO).
Step 2B:
As discussed above in “Step 2A – Prong 2,” the requirement to execute the claimed steps/functions using “a system for monitoring goods in transit, the system comprising: one or more user devices, each user device comprising one or more sensors,” and “a server device, communicatively coupled with the one or more user devices via one or more data communication networks,” (claim 1) and “a user interface” (claim 8), is equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. These limitations therefore do not qualify as “significantly more.” See MPEP § 2106.05(f).
Viewing the additional limitations in combination also shows that they fail to ensure the claims amount to significantly more than the abstract idea. When considered as an ordered combination, the additional components of the claims add nothing that is not already present when considered separately, and thus simply append the abstract idea with words equivalent to “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer.
Remaining dependent claims 2-4 and 6 either recite the same additional elements as noted above or fail to recite any additional elements (in which case, note prong one analysis as set forth above – those claims are further part of the abstract idea as identified by the Examiner for each respective dependent claim).
The Examiner has therefore determined that no additional element, or combination of additional claims elements is/are sufficient to ensure the claims amount to significantly more than the abstract idea identified above (Step 2B: NO).
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 1, 4, 6, and 8 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Morimoto (US 2017/0316293 A1).
Regarding claim 1, Morimoto discloses a system for monitoring goods (containers 40A through 40N) in transit (Fig. lA & 2; Par. [0003], The present invention generally relates to the shipping or mailing of items from one place to another; Par. [0008]; Par. [0034], Par. [0054], the central server 90 may maintain real time price and shipping quotes by periodically monitoring shipping companies and hubs; the items [goods] are shipped and tracked), the system comprising:
one or more user devices (Par. [0011], In one embodiment, the system may also include hand-held communicating device, with a display device, that allows the user to easily view the contents of the memory device. The hand-held device may also have an input device (e.g., a set of buttons or an entire keyboard) that allows the user to append and edit information for storage in the memory device. The hand-held device may also include a network interface configured to allow the hand-held device to send and receive to information from a computer network (e.g., the Internet)), each user device comprising one or more sensors configured to generate a condition record (Fig. 1 & 10; Par. [0011], The memory device may store shipping and insurance information related to the item being shipped in a data file. The memory device may include input devices and sensors to gather and store information before, during and after shipment. The data file may be updated to reflect the changes ... The sensor may also include a digital camera configured to capture digital images of the carrier/container/item. The weight and images may be useful for customs purposes and to prove the condition of the item being shipped. The system may be configured to transmit information from the sensors using the computer network, or to store the information in the memory device; Par. [0034], Similarly, memory devices 50A through 50N may be configured to store electronic data corresponding to containers 40A through 40N, respectively; Par. [0039], In embodiments that utilize active memory devices (e.g., electronic or magnetic memory as opposed to barcodes, which are a passive memory), additional features such as global positioning and environmental (e.g., temperature, humidity, vibration, sound, light, air contaminants) sensors may also be implemented as part of the memory devices; Par. [0040], 'The memory device may also store digital images of the items being shipped (e.g., as the items are being packed to prove that the items are in good condition before shipment); Par. [0089], Advantageously, this unique identifier may also be used to control billing receipts and customs records for the shipped item; the digital camera [sensor] captures images to generate a condition [record] for storage on the memory devices 50A-50N),
the condition record comprising a time value, a location value, and a physical condition of goods (40A-40N), wherein the time value and the location value correspond to a predetermined route for transport of the goods (40A-40N) between an origination point and a destination point (Par. [0012], the system may be configured to interface with the memory device (e.g., using a wireless link) and read the memory device to determine the best routing for the item to be shipped; Par. [0014], This may simplify the transfer of the container at intermediate destinations, and may also allow the information stored in the memory device to be updated as the container progresses through its designated routing. For example, at each intermediate destination, the shipping company may update the information in the memory device to reflect the time that the container was received. Other information may also be updated (e.g., the condition of the container and/or item); Par. [0053], the system may be configured to interface with the memory device (e.g., using a wireless link) and read the memory device to determine the best routing for the item to be shipped; Par. [0069], The selection of the successful bidder may depend on various criteria such as cost efficiency, reliability, time to deliver, past history and geographic coverage. In one embodiment, the selection criteria may be based on securing the maximum value of a product or service at the least cost. Once the central server has selected a particular routing for the goods or items to be shipped, it may confirm this routing with the customer, the originating shipping company, the destination, the insurance company, and any intermediate locations/shipping companies; the time for the goods to be shipped from the origin to the destination may be determined as part of the quoting process and included in the condition record; the condition record can be updated during the transit of the goods);
a server device (central server 90), communicatively coupled with the one or more user devices (50A-50N) via one or more data communication networks (network 92), the server device (90) configured to receive a first plurality of condition records from a plurality of the one or more user devices (50A-50N), each of the first plurality of condition records corresponding to a time value and a location value during transport of first goods on the predetermined route (Fig. IA, 2 & 10; Par. [0014], This may simplify the transfer of the container at intermediate destinations, and may also allow the information stored in the memory device to be updated as the container progresses through its designated routing. For example, at each intermediate destination, the shipping company may update the information in the memory device to reflect the time that the container was received. Other information may also be updated ( e.g., the condition of the container and/or item); Par. [0039], In embodiments that utilize active memory devices (e.g., electronic or magnetic memory as opposed to barcodes, which are a passive memory), additional features such as global positioning and environmental (e.g., temperature, humidity, vibration, sound, light, air contaminants) sensors may also be implemented as part of the memory devices; Par. [0052], Each hub is represented by a processing device (e.g., a computer configured to interface with memory devices 50A-N and/or 60),; Par. [0053], each regional shipping company or hub 80-88 may be configured with a container processing apparatus that is directly or indirectly connected to a network 92. In one embodiment, as shown in the figure, network 92is used to couple the processing apparatuses to a central server 90. While different types of networks may be used, in one embodiment the processing devices at the regional shipping company hubs and central server 9Omay be connected via the Internet; Par. [0069], The selection of the successful bidder may depend on various criteria such as cost efficiency, reliability, time to deliver, past history and geographic coverage. In one embodiment, the selection criteria may be based on securing the maximum value of a product or service at the least cost. Once the central server has selected a particular routing for the goods or items to be shipped, it may confirm this routing with the customer, the originating shipping company, the destination, the insurance company, and any intermediate locations/shipping companies; the memory devices 50A-50N can provide the condition records through the hub and network to the central server 90),
the server device (90) further configured to store the first plurality of condition records in association with the first goods (40A-40N) and in association with each other (Fig. 2; Par. [0053], the central server 90 may be configured to routinely poll each regional hub to determine availability, shipping times, and prices. Central server 90 may be configured to maintain a database of this information that is periodically updated; Par. [0060], central server 90 may be configured to periodically update the database independent of any request for quotes (e.g., by interrogating sources of external information for updated shipping and/or insurance information). In one embodiment, a first database may be maintained for shipping information; Par. [0064], central server 90 may be configured to maintain a real time or near real time database of the status of all goods being shipped using the network. For example, a customer or shipping company may enter in a unique identifier that identifies the goods being shipped, and the database may respond by outputting the data file (e.g., as shown in FIG. 4). At any point before, during or after the shipping process the data file may be updated to match current conditions. For example, events such as arrival of the item at an intermediary destination, arrival at the final destination, damage to the item during shipment, and confirmation by the recipient of receiving the item may be conveyed to the central server, which may then update the database accordingly');
the server device further configured to validate each of the first plurality of condition records by analyzing the time value and the location value of the respective condition record to correlate the respective condition record to the predetermined route of the first goods (Par. [0075], Turning now to FIG. 6, a flowchart depicting one portion of one embodiment of a method for arranging shipment and insurance for an item being shipped or mailed is shown. In this figure, details of how the container may be handled upon arriving at an intermediate destination is shown. First, the container is received at the intermediate destination (Stepl30). Next, the data file, or at least the routing information, may be read from the memory device attached to the container and/or the carrier (Step l32). Next, the shipping company may be configured to communicate or verify the receipt of the goods using the network; Par. [0080], As previously noted, the central server may be contacted to verify the next intermediate destination; Par. [0082], Turning now to FIG. 8, one embodiment of a method for operating central server 90 is illustrated. In this embodiment, central server 90 may be configured to receive updates at any time before, during or after the shipping process. This includes updates received from intermediate destinations (Step 180). Central server 90 may be configured to periodically check shipping schedules for subsequent intermediate destinations (Step 182) to verify the availability and/or feasibility of the future intermediate destination(Step 184 ) ... If, however, no issues concerning availability of shipment at intermediate destinations arise, or if no better alternatives are available, then the central server may simply be configured to communicate a verification of the original route to one or more of the parties to the shipping transaction (Stepl92); the system may verify [validate] the record using the location and time data during the shipping transit); and
the server device (90) further configured to provide at least a portion of information from the first plurality of condition records in response to a request for transit information related to the first goods (40A-40N; Fig. IA & 2; Par. [0064], Advantageously, central server90may be configured to maintain a real time or near real time database of the status of all goods being shipped using the network. For example, a customer or shipping company may enter in a unique identifier that identifies the goods being shipped, and the database may respond by outputting the data file (e.g., as shown in FIG. 4). At any point before, during or after the shipping process the data file may be updated to match current conditions. For example, events such as arrival of the item at an intermediary destination, arrival at the final destination, damage to the item during shipment, and confirmation by the recipient of receiving the item may be conveyed to the central server, which may then update the database accordingly. Similarly, the updated information may be sent to any parties associated with the shipment (e.g., via e-mail)).
Regarding claim 4, Morimoto discloses wherein the condition record comprises at least one of a digital image of the goods and a video including a complete perimeter of the goods (40A-40N; Fig. IA; Par. [0011], The sensor may also include a digital camera configured to capture digital images of the carrier/container/item; Par. [0040], The memory device may also store digital images of the items being shipped (e.g., as the items are being packed to prove that the items are in good condition before shipment); Par. [0089], Advantageously, this unique identifier may also be used to control billing receipts and customs records for the shipped item; the digital camera [user device] captures images to generate a condition [record]).
Regarding claim 6, Morimoto discloses wherein the predetermined route comprises a plurality of alternative routes and a plurality of intermediate points between the origination point and the destination point of each alternative route (Par. [0053], In response, central server 90 may execute an optimization program configured to search out the most efficient (e.g., lowest cost) routing for the package within the specified time constraints. Central server 90 included in the intelligent shipping agent may also have information about traditional shipping alternatives (e.g., direct routing using one shipping company) for comparison; Par. [0082], This includes updates received from intermediate destinations (Step l80). Central server 90 may be configured to periodically check shipping schedules for subsequent intermediate destinations (Step 182) to verify the availability and/or feasibility of the future intermediate destination (Step 184). If availability of shipment through one or more of the subsequent intermediate destinations is in question (Step 186), then the server may be configured to request quotes for alternate routes (Step 188). If one or more better alternative routes are available (Step 190), then the server may then communicate the newly selected route to all parties to the shipping transaction (Step 192)).
Regarding claim 8, Morimoto discloses wherein the one or more user devices are further configured to receive via a user interface one or more indications corresponding to the physical condition of the goods and further configured to include the one or more indications corresponding to the physical condition of the goods in the condition record (40A-40N; Fig. 1 A; Par. [0011], The memory device may store shipping and insurance information related to the item being shipped in a data file. The memory device may include input devices and sensors to gather and store information before, during and after shipment. The data file may be updated to reflect the changes ... The hand-held device may also have an input device (e.g., a set of buttons or an entire keyboard) that allows the user to append and edit information for storage in the memory device ... The sensor may also include a digital camera configured to capture digital images of the carrier/container/item. The weight and images may be useful for customs purposes and to prove the condition of the item being shipped; Par. [0085], apparatus further comprises an interface).
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.
Claims 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Morimoto (US 2017/0316293 A1) in view of Maas et al. (US 2006/0089897 A1), hereinafter Maas.
Regarding claim 2, Morimoto does not explicitly disclose wherein each of the plurality of condition record comprise a plurality of customizable data fields that can be activated for inclusion in the condition record and deactivated for exclusion from the condition record. Maas teaches wherein each of the plurality of condition record comprise a plurality of customizable data fields that can be activated for inclusion in the condition record and deactivated for exclusion from the condition record (Maas is in the field of shipping goods (Par. [0039]); Fig. 1; Par. [0046], The transaction processing module 210 accepts input from the user and creates the interfaces to specify goods for trade-in, present pricing, create inventory records and processes other information required to complete the transaction. For example, a trader navigates to the base product they are interested in trading (e.g., Callaway Driver) and identifies the specifics of their club (e.g., loft, shaft type, condition); Par. [0066], The pricing guide preferably creates a record format for all data associated with a trade-in; Par. [0071], Many of the category attributes will affect the trade-in value of the item. Category attributes are custom defined data fields for the item. For example, these include but are not limited to title, description, picture URL, type, options list, age, condition, etc.; Par. [0073], An operator at the trade-in system 102 can then review the retrieved record and confirm that the item received matches the specifics of the record including item type, condition, etc.; an item [goods] can include a record with an indication of condition and a plurality of customized fields; as there is no limit to the custom fields and only some fields are needed for shipping, if a field is used, then it is active, and if it is not used, it is not active).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the shipping record system of Morimoto to include the data field abilities of Maas as a need exists for providing information related to an item, thereby allowing for the system to determine a price/value before the item is shipped (Maas, Par. [0071]). As in Maas, it is within the capabilities of one of ordinary skill in the art before the effective filing date to include customizable data fields to Morimoto’s shipping record system with the predicted result of providing an improved system for arranging shipment for an item as needed in Morimoto (Morimoto, Par. [0007]).
Regarding claim 3, Morimoto does not explicitly disclose wherein the plurality of customizable data fields have customizable labels and a first customizable data field is configured to carry a data payload corresponding to a first customized label. Maas teaches wherein the plurality of customizable data fields have customizable labels and a first customizable data field is configured to carry a data payload corresponding to a first customized label (Fig. 1; Par. [0046], The transaction processing module 210 accepts input from the user and creates the interfaces to specify goods for trade-in, present pricing, create inventory records and processes other information required to complete the transaction. For example, a trader navigates to the base product they are interested in trading (e.g., Callaway Driver) and identifies the specifics of their club (e.g., loft, shaft type, condition); Par. [0066], The pricing guide preferably creates a record format for all data associated with a trade-in; Par. [0070], The user then sends 512 the trade-in item with the transaction information and it is received by the trade-in system 102. This could be simply a tracking code, SKU or other information provided on the shipping label, or it could be more detailed information. It need only be information sufficient to match the trade-in item to the record created in the database in step 510; Par. [0071], Many of the category attributes will affect the trade-in value of the item. Category attributes are custom defined data fields for the item. For example, these include but are not limited to title, description, picture URL, type, options list, age, condition, etc.; Par. [0073], Then the system 102 identifies 804 the reverse logistic code, and retrieves 806 the record in the database 214 corresponding to the reverse logistic code. This can be done in one embodiment by scanning a bar coded on the shipping label of the received item. An operator at the trade-in system 102 can then review the retrieved record and confirm that the item received matches the specifics of the record including item type, condition, etc.; Par. [0074], The process begins with the user browsing 902 master SKUs. The master SKU s are templates or partially completed records that include much of the information necessary to identify, process and re-list a trade-in item. Once the user selects 904 a master SKU, the system 102 creates 906 a new instance or record based on the information In the master SKU. Then the system 102 adds 908 a unique ID number to the new instance or record of the SKU. This unique ID number uniquely identifies this trade-in item from all others even if of the same type ... Then the new instance of the SKU is used 916 as has been described above to identify the transaction, printed on the return label for the trade-in item, and used to process the trade-in item when it is received.; a shipping label [custom] can include information from the customized fields in the record; this includes an item identifier [data payload] that is printed on the label to identify said item from other items).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the shipping record system of Morimoto to include the data field abilities of Maas as a need exists for providing information related to an item being shipped, thereby ensuring that the item is identified correctly from other items that may be similar (Maas; [0073]-[0074]). As in Maas, it is within the capabilities of one of ordinary skill in the art before the effective filing date to include customizable data fields to Morimoto’s shipping record system with the predicted result of providing an improved system for arranging shipment for an item as needed in Morimoto (Morimoto, Par. [0007]).
Conclusion
THIS ACTION IS MADE FINAL. 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 Patrick Kim whose telephone number is (571)272-8619. The examiner can normally be reached Monday - Friday, 9AM - 5PM EST.
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, Lynda Jasmin can be reached at (571)272-6782. 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.
/Patrick Kim/Examiner, Art Unit 3628
/RESHA DESAI/Supervisory Patent Examiner, Art Unit 3648