DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-3, 5-9, and 11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites a newly added limitation “transmit information requesting to scan the idem identification information for each of items” is vague/ indefinite because it is unclear why/ how all the items would be requested to be scanned based on a prohibited quantity change of an item. Claim 9 recites the newly added limitation “transmitting information requesting to scan the item identification information for each of items” which is also unclear as to why/ how based on a prohibited quantity change, a request to scan the items would be transmitted when the items have already been previously scanned in the claim prior to this new limitation being added. For purposes of examination the examiner will interpret the limitations to mean transmitting information as is part of the scanning process for items.
Appropriate correction is requested.
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-3, 5-9, and 11 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) limitations drawn to organized human activity/ financial transactions/ mental concepts, as the inventive concept is seen as an abstract rule for prohibiting quantity/ count changes. This judicial exception is not integrated into a practical application because the limitations are drawn to generic computer components (server, memory, processors) performing generic steps as part of the abstract idea, namely acquiring data, comparing it to stored/ reference data, and then providing an output, wherein the output can be seen as part of the abstract idea of providing data, or can be seen as post solution activity. The inventive concept appears to be the abstract rule as it pertains to quantity changing (matching to a change quantity triggering an error). Further, the limtaitons are similar that of a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, as taught as Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016), wherein in the instant application, the limitations are in the environment of a checkout/ point of sale, are generic computer implementations of such a mental concept/ organized human activity. Further, per MPEP 2106.04a2.III. (mental processes), just because there is a computer does not remove the claim from being a mental step… Nor do the courts distinguish between claims that recite mental processes performed by humans and claims that recite mental processes performed on a computer. As the Federal Circuit has explained, "[c]ourts have examined claims that required the use of a computer and still found that the underlying, patent-ineligible invention could be performed via pen and paper or in a person’s mind." Versata Dev. Group v. SAP Am., Inc., 793 F.3d 1306, 1335, 115 USPQ2d 1681, 1702 (Fed. Cir. 2015). See also Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1318, 120 USPQ2d 1353, 1360 (Fed. Cir. 2016) (‘‘[W]ith the exception of generic computer-implemented steps, there is nothing in the claims themselves that foreclose them from being performed by a human, mentally or with pen and paper.’’); the courts do not distinguish between mental processes that are performed entirely in the human mind and mental processes that require a human to use a physical aid (e.g., pen and paper or a slide rule) to perform the claim limitation. See, e.g., Benson, 409 U.S. at 67, 65, 175 USPQ at 674-75, 674 (noting that the claimed "conversion of [binary-coded decimal] numerals to pure binary numerals can be done mentally," i.e., "as a person would do it by head and hand.")
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they are merely generic computer elements that are used to apply the abstract idea which cannot integrate the abstract idea into a practical application because it imposes no meaningful limitations on its practice. The generic computer devise are being used as a tool to perform abstract comparisons of data and then returning a result of the comparison (see Universal Secure Registry). The dependent claims are rejected as they further recite limitations drawn to specifying details of the abstract idea and routine data gathering as it pertains to the acquisition, sending, receiving, and displaying of data. Storing in a database is abstract/ mental concepts or is part of a generic computer and thus is not a practical application. Scanning/ reading/ imaging can be abstract in that it can be mental or it can be seen as routine data gathering necessary for abstract limitations of the mental steps, as receiving data is routine data gathering.
For example, re claim 1, the receiving clause is routine data gathering using generic computer components merely as tools (device, image capture, processors, memory). The generating clause is mental steps/ organized human activity such as making a list. The next generating clause including the transmission of data is routine data gathering and insignificant post solution activity, similar to displaying results. The receiving clause is routine data gathering using generic computer components. The determining clause is mental steps and is similar to the comparison of data to stored data as per Electric Power v. Alstom. The detection an error is a generic computer implementation of mental steps, tantamount to data matching similar to the concepts discussed in Electric Power v. Alstom. The prohibiting clause is the completion of the abstract idea using generic computer components and/ or mental steps one would do at a checkout when processing a transaction (organized human activity) and the transmission clause is insignificant post solution activity similar to displaying results.
Re the newly added limitation to claim 1 of generating and exchanging information, this is routine data gathering for the abstract idea.
Re the newly added limitation of automatically invalidating to prohibit the addition of the item when its scanned several times, the Examiner again notes this is organized human activity/ mental processes including applying a rule using generic computer components as a tool to such ends as part of automating manual activity.
Re the newly added limitation of transmitting a request to scan, this is routine data gathering using generic computer components.
Re claim 2, the limitations are merely drawn to routine data gathering and mental steps (comparison) performed on genre computer components. Re claim 3, the limtaitons are drawn to mental steps (data matching / comparisons). Re claim 5, the limitations are specifying details of the abstract idea (data gathering limitations). Re claims 6-7, a mobile terminal/ image capture device is intpereted as a generic computer component for applying the abstract idea. Re claim 8, the limitations are merely specifying details of the abstract idea such as the type of items. The corresponding method and system claims (9 and 11) are rejected for similar reasons as discussed above.
Appropriate correction is requested.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-3, 5-9, and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Itani et al. (US 201503104140) in view of Kadapurath et al. (US 20200184446).
Re claim 1, Itani et al. teaches: a server apparatus (paragraph [0102]) which implicitly has memory and processor(s).
Itani et al. teaches receiving item identification information based on an item from a terminal (FIG.1, FIG. 8 and FIG. 10), to create a list of items to be purchased based on the received item identification information (FIG. 5+);
Itani et al. teaches receiving a quantity change request of an item in the list from the terminal and transmit information indicating that the quantity is unchangeable to the terminal apparatus with the item is prohibited to have a quantity change (a warning is displayed to that effect (refer to fig. 8 and 10, Itani et al. teaches all processes are performed in a server device, or can be local or refer to paragraph [0107+]). Itani et al. teaches that discount information and special sales information are included in transaction information, and stored in another table (refer to paragraphs [0047]+ and [0100+]). Itani et al. teaches that products are specified on the basis of images captured by a POS terminal (refer to paragraph [0030]+). Itani et al. teaches limiting changes in quantity with regard to clearance goods (refer to paragraph [0097]). FIG. 8 teaches that an alarm is displayed when the quantity changed exceeds a limit, thus teaching prohibiting to change the quantity to exceed. Therefore, it would have been obvious that no quantity change be permitted in certain instances, based on the discount information for example, when the quantity would be limited to “1”, such as based on system constraints for sales/ promotions. Additionally, the Examiner notes that as the server and terminal work together, it would have been obvious to one of ordinary skill in the art that the server receive the information form the terminal and provide the response, such as when the data is stored at the server, as is known in the art.
The Examiner notes that FIG. 8+ teaches that a plurality of same items are received and an error is detected when this happens and when a change to quantity is attempted (an alarm sounds when a request change indicates the quantity is exceeded). It would have been obvious that the items (first items) already scanned and desired to be changed to a greater quantity would be received multiple times, such as via scanning, as known to input product data for purchasing.
Re the limitation of the server receiving from a self-checkout device, the items corresponding to those scanned by the self-checkout terminal device, scanner 23/13 reads on such limitations which scans a barcode. Paragraph [0030]+ teaches image capturing as recited.
Re the limitation of transmitting the error to the self-checkout device, paragraph [0076]+ teaches the displaying of the alarm on the display 12 or 22 (paragraph [0076]).
Though silent to explicitly reciting “self-checkout” the use of self-checkouts is an obvious expedient for convenience, reduced workforce, costs, etc.
Re the list of items to be purchased, this has been discussed above as part of the conventional checkout transaction for items desired.
Re the limitation of the transmitting the list of items to the self-checkout device to be displayed, the limitations are interpreted to be taught at paragraphs [0027]+) wherein a GUI to display is an obvious expedient for preferred outputs/ displays, wherein information exchange is implicit to generate the GUI.
Paragraph [0030]+ teaches a CCD and FIG. 8 teaches the code prohibits a quantity change, as a quantity limit is a specific code (paragraph [0065]+ teaches the product code corresponds to a limited sales product prohibiting a quantity change (increase), such as when the quantity code is one, a change to greater than one creates an alarm. A single item limit is an obvious expedient based on promotions/ sales. Therefore, this is interpreted as the first item being determined to quantity change is prohibited, and the amount of that item available being within the ordinary skill in the art based on the desired purchase restricting by the merchant/ vendor.
Re the limitation that the list of items also include the first item identification information, the Examiner notes that all scanned items are interpreted as to be purchased as is known in the art and thus are part of the transaction and list of items.
Re the limitation that the GUI screen is generated and transmitted to the self-checkout, this has been interpreted as the data for the displaying is transmitted to the checkout, and has been discussed above.
Re the limitation of receiving the first item identification information acquired again by scanning the barcode of the first item at a second time by the image capturing device, the Examiner notes that as discussed above, a quantity restricted item, such as a quantity of 1, would result in the same information being received based on the code but then an error / fault is generated because the quantity is a limited purchase item indicated by its code, and thus the item is unable to be purchased a second time at the pricing because it is interpreted that the item change is prohibited based on the code and an error detected and transmitted.
The Examiner notes that Itani et al. teaches restricting the quantity of items able to be purchased at a sale price and that past that quantity is regular price, but does not teach prohibiting a quantity in general to be scanned for purchase (regardless of price).
Kadapurath et al. teaches a self-checkout (paragraph [0041]+ and business rules that provide quantity restrictions on limited quantity items) that limits the number of an item that can be purchased. As there are quantity restrictions for items, it would have been obvious that in order to disallow such numbers to exceed a set amount of times, that additional items past a quantity would result in an error/ fault/ message to a user automatically invalidating or not allowing such a transaction to occur. This is accomplished through use of an API which restricts the quantities on certain items to be purchased, which obviates invalidating when the quantity of a particular item becomes too high (after several scans of the item).
Prior to the effective filing date, it would have been obvious to combine the teachings to limit selected items to a purchase quantity amount, such as for security, to prevent scalping, etc. Doing so would prevent the addition of an item a second time to be added to a list of items to be purchased, per the amendments at the bottom of claim 1, thus restricting the purchase of items past a predetermined limit (max of 1/2/3, etc. per customer for example, obviated by the desired security/ inventory settings) expanding on the teachings of Itani et al. for restricting purchase of items past a limit. It would have been obvious to one of ordinary skill in the art that such information is part of the barcode item, and thus a code/ part of the barcode indicates such as it is tied to the information that is used by the system to prohibit such additions or exceeding of quantity.
Simply put, exchanging information for a display is implicit in displaying fetched information. Automatically invalidating has been discussed above as obviated by security to invalidate subsequent scanning of a same item such as a weight or alcoholic beverage item from being scanned multiple instances (as opposed to just not being able to just have the quantity changed). Re the newly added limitation of transmitting information requesting to scan the item identification information for each of the items, this is broadly interpreted as fetching information related to the plurality of items scanned.
Re claim 2, this has been discussed above as the particular item is identified, and thus a second item also being restricted.
Re claim 3, a product information table is taught in paragraph [0047] and [0067]wherein a database is an obvious expedient as a central storage for product information as known in the art, such as storing data about restricted items as discussed above.
Re claim 5, as discussed above, the limited quantity sales product would have been obvious to be a single amount, such as based on the specific desired limited quantity. Accordingly, when it is received multiple times, an error/ fault is provided, which is interpreted as an indication it has already been included in the list. Transmitting information that its already included in the list of scanned items is interpreted to read on logging items quantities as they occurs, as is known in the art, and restricting changing them in restricted item cases as discussed above.
Re claim 6, a handheld scanner/ reader has been discussed above (23) and thus is interpreted as a mobile device that scans codes,
Re claim 7, paragraph [0030]+ teaches such limitations.
Re claim 8, paragraph [0063]+ teaches limited quantity for sales products.
Re claims 9 and 11, the limitations have been discussed above. Re claim 11, a display device is obvious in a checkout for displaying.
Claim(s) 1-3, 5-9, and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Itani et al. (US 201503104140) in view of Sasaki et al. (US 20210192902) and Kadapurath et al., as discussed above.
Re claim 1, the teachings of Itani et al. have been discussed above, and Itani et al. teaches: a server apparatus (paragraph [0102]) which implicitly has memory and processor(s).
Itani et al. teaches receiving item identification information based on an item from a terminal (FIG.1, FIG. 8 and FIG. 10), to create a list of items to be purchased based on the received item identification information (FIG. 5+);
Itani et al. teaches receiving a quantity change request of an item in the list from the terminal and transmit information indicating that the quantity is unchangeable to the terminal apparatus with the item is prohibited to have a quantity change (a warning is displayed to that effect (refer to fig. 8 and 10, Itani et al. teaches all processes are performed in a server device, or can be local or refer to paragraph [0107+]). Itani et al. teaches that discount information and special sales information are included in transaction information, and stored in another table (refer to paragraphs [0047]+ and [0100+]). Itani et al. teaches that products are specified on the basis of images captured by a POS terminal (refer to paragraph [0030]+). Itani et al. teaches limiting changes in quantity with regard to clearance goods (refer to paragraph [0097]). FIG. 8 teaches that an alarm is displayed when the quantity changed exceeds a limit, thus teaching prohibiting to change the quantity to exceed. Therefore, it would have been obvious that no quantity change be permitted in certain instances, based on the discount information for example, when the quantity would be limited to “1”, such as based on system constraints for sales/ promotions. Additionally, the Examiner notes that as the server and terminal work together, it would have been obvious to one of ordinary skill in the art that the server receive the information form the terminal and provide the response, such as when the data is stored at the server, as is known in the art.
Itani et al. is silent to explicitly reciting no changes to quantity are permitted for weight items/ automatically invalidating and specifically reciting “self-checkout” with a mobile terminal.
Re the newly added limitations, they have been discussed above in preceding rejection.
Sasaki et al. teaches such limitations (paragraph [0327]) teaching disabling changing count for weight items and self-checkout (paragraph [0002]+) and mobile terminals (20). Further, Sasaki et al. teaches the POS of the self-checkout can be separated POS, opposing POS, or a full self-checkout, thus providing motivation to combine with Itani et al. Itani et al. also teaches registration screen 810 for displaying information, wherein it would have been obvious that as it disables changing counts on the display, that the displaying of an alarm/ alert (as taught by Itani et al.) on said display, would have been obvious to convey information to the user.
Prior to the effective fling date, it would have been obvious to combine the teachings for security for specific item classes.
Itani et al./ Sasaki et al. are silent to prohibiting the addition/ automatically invalidating of the first item scanned at a second time when it is determined that it is a quantity change of a prohibited item a first item is scanned several times. Sasaki et al. teaches disabling the purchase count change option for variable weight products (paragraph [0327]+) which obviates not allowing changes in quantity to weight items to be made for security at a given time but is silent to subsequent scans and the automatic invalidating of the second scan of the items.
Nonetheless, Kadapurath et al., as discussed above, teachings limiting a number of an item that can be purchased at a checkout, as discussed above, such as quantity of items, using an API 270, which evaluates items in the cart and thus is interpreted to obviate/ invalidate after quantity problems are detected, which would obviate invalidating after a second/ several scan of the items (which results in too high of a quantity being received), by disallowing/ invalidating those scans that past the threshold.
Prior to the effective filing date, it would have been obvious to combine the teachings.
One would have been motivated to do this to control/ limit particular quantities of an item, such as for security, marketing, etc. by enforcing rules regarding the number of items scanned (limited quantity items) made during a shopping visit.
Re claim 2, this has been discussed above as the particular item is identified. It would have been obvious to receive from the self-checkout device based on the user/ customer attempting to buy and thus make changes.
Re claim 3, a product information table is taught in paragraph [0047] and [0067]wherein a database is an obvious expedient as a central storage for product information as known in the art, and claim 3 has been discussed above.
Re claim 5, as discussed above, the limited quantity sales product would have been obvious to be a single amount, such as based on the specific desired limited quantity. Accordingly, when it is received multiple times, an error/ fault is provided, which is interpreted as an indication it has already been included in the list. Transmitting information that its already included in the list of scanned items is interpreted to read on logging items quantities as they occurs, as is known in the art, and restricting changing them in restricted item cases as discussed above.
Re claim 6, a handheld scanner/ reader has been discussed above (23) and thus is interpreted as a mobile device that scans codes, and Sasaki et al. teaches such limitations as discussed above.
Re claim 7, paragraph [0030]+ teaches such limitations. Sasaki et al. teaches such limitations with the terminals 20+.
Re claim 8, paragraph [0063]+ teaches limited quantity for sales products.
Re claims 9 and 11, the limitations have been discussed above.
Response to Arguments
Applicant's arguments filed have been fully considered but they are not persuasive. The 103 rejection is provided and expanded upon as above. A 112 rejection has been provided above as it is unclear why a request to scan the items would be executed after a list has of the scanned items has already been generated prior. The Examiner has maintained the 101 and notes that the inventive concept appears to be the abstract rule being applied in a generic computer environment and thus remains rejected under 101. The limitations are drawn to mental/ economic steps of the transaction being performed using generic computer components, in accordance with the abstract rule regarding item restrictions.
Re the 103 rejection, the Examiner notes that the prior art teachings prevented quantity changes but were silent receiving the first item at a second time (an item being scanned more than once) that has quantity change prohibited. Kadapurath et al. teaches restricting purchases of an item past a certain quantity (limits on a number of an item that can be purchased via quantity restrictions on limited quantity items as item restrictions), thus obviating invalidating subsequent scans of the item (the API looks at the cart contents to determine if any rules are violated, and thus any scans past a certain amount would have been obvious to be automatically invalidated). Simply put, Itani et al. teaches the limitations except for prohibiting the purchase past a quantity amount/ automatic invalidation, as Itani et al. prohibits changing the quantity past a permitted quantity (for sales price) but not a general restriction of a quantity of an item. Kadapurath et al. teaches limiting the number of an item that can be purchased, and this in combination obviates the new limitations based on limited quantity, security, marketing, reducing scalping, etc. It would have been obvious that such information is part of the barcode because that is how the item is identified as is routine in the art and linked to quantity changes not being allowed as the barcode information identifies such items as such. Sasaki et al., in similar fashion, disables quantity count changes for variable weight products (restricted item) wherein Kadapurath et al. follows rules of item quantities in a cart and thus would obviate automatic invalidation and would be interpreted to cover instances of separate scans of the items that are restricted, such as scanning many of the same item (alcohol).
Re the newly added limitations of exchanging information for a GUI, information change is implicit in order to generate a display for items.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL I WALSH whose telephone number is (571)272-2409. The examiner can normally be reached 7-9pm.
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, Steven Paik can be reached on 571-272-2404. 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.
/DANIEL I WALSH/ Primary Examiner, Art Unit 2876
Prosecution Insights