DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on XXXXXXXXXXXXXX has been entered.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims X are canceled.
Claims X are new.
Claims 1-8 are pending and have been examined.
This action is in reply to the papers filed on 11/25/2025 (effective filing date 07/23/2024).
Information Disclosure Statement
The information disclosure statement(s) submitted: 11/25/2025 and 02/03/2026 have been considered by the Examiner and made of record in the application file.
Amendment
The present Office Action is based upon the original patent application filed on xxx as modified by the amendment filed on xxx.
Reasons For Allowance
Prior-Art Rejection withdrawn
Claims xxx are potentially allowable over the prior-art, but, are still subject to the 35 USC §101 and/or 35 USC §112 rejections herein. The closest prior art (See PTO-892, Notice of References Cited) does not teach the claimed:
Claims xxx are allowed. Independent claims X, Y, and Z all contain the same inventive scope. The closest prior art (See PTO-892, Notice of References Cited) does not teach the claimed:
The invention teaches… and the prior-art teaches…, however, the prior-art does not teach…
The closest prior-art (xxx) teach the features as disclosed in Non-final Rejection (xxxx), however, these cited references do not teach and the prior-art does not teach at least the following combination of features and/or elements:
Claim Rejections - 35 USC §101 - Withdrawn
Per Applicant’s amendments and arguments and considering new guidance in the MPEP, the rejections are withdrawn. Specifically, in Applicant’s Remarks (dated 03/14/2017, pgs. 8-11), Applicant traverses the 35 USC §101 rejections arguing that the amended claims recite new limitations that are not abstract, amount to significantly more, are directed to a practical application, etc… For example, Applicant argues….
In support of their arguments, Applicant cites to the following recent Fed. Cir. court cases (i.e., Alice Corp. v. CLS Bank Int’l, SRI Int’l, Inc. v. Cisco Systems, Inc., Ultramercial, Inc. v. Hulu, LLC, Berkheimer, Core Wireless, McRO, Enfish, Bascom, DDR, etc…).
Claim Rejections - 35 USC §112
The following is a quotation of 35 U.S.C. §112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
(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.
35 U.S.C. § 112(a) — Written Description (MPEP § 2163)
Claims 1–8 are rejected under 35 U.S.C. § 112(a) because the written description fails to reasonably convey that the inventor had possession of the full scope of the claimed invention as of the filing date. Ariad Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc) (the test is "whether the disclosure … reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date").
Claim 1 broadly claims a "detected terminal" that is identified, connected, verified, and bound, without any structural limitation on what that "detected terminal" is. The specification discloses only a narrow, non-representative set of species purporting to support this broad functional genus: "the detection terminal may be a chip … in another embodiment, the detected terminal may be a graphic code such as a two-dimensional code (QR code) or a barcode, and the detection terminal may be a commonly Internet communication equipment such as a mobile phone. Identification between the detection terminal and the detected terminal includes at least one of methods such as numbers, symbols, letters, images, and frequency bands" ([0067]). The specification provides no algorithm, protocol, or structural description of how a "detected terminal" identified by, e.g., "letters" or "images" alone (as opposed to a chip with an RFID/NFC radio, or a printed QR code) is read, connected to a network, and made to "send a first password to the cloud platform" as claim 1 requires. To the extent claim 1 (and claims 2–6, 8, which depend from or incorporate claim 1, and claim 7, which recites commensurate functional language) is construed to cover the full genus of "detected terminals" identifiable by any of the disclosed identification methods, the specification's disclosure of a small number of specific, structurally dissimilar species (a chip; a QR code/barcode; a mobile phone) does not reasonably convey possession of the full functional genus claimed. See MPEP § 2163.03(I)–(II) (a claimed genus is not adequately described by disclosure of a few species where the species are not representative of the full variety within the genus).
Applicant may overcome this rejection by amending the claims to recite the specific detected-terminal structures actually disclosed as being capable of performing the claimed functions (e.g., limiting "detected terminal" to a chip, or to a graphic code together with a corresponding terminal reader), or by pointing to disclosure (with citations) that reasonably conveys possession of the full scope currently claimed.
35 U.S.C. § 112(b) — Indefiniteness / Lack of Antecedent Basis (MPEP §§ 2173.05(e), 2172.01)
Claims 1, 2, 7 (and claims 3–6, 8 by dependency/incorporation) are rejected under 35 U.S.C. § 112(b) as indefinite because, read in light of the specification, they fail to inform a person of ordinary skill in the art about the scope of the invention with reasonable certainty. Nautilus, Inc. v. Biosig Instruments, Inc., 572 U.S. 898, 901 (2014).
Ambiguous relationship between the claimed connection scenarios. Claim 1 recites two fact patterns for how "the current detection terminal is connected to the cloud platform": (a) "when the current detection terminal is connected to the cloud platform without identifying the detected terminal through a preset system," triggering the first-password/verification-program sequence; and (b) "when the detection terminal is connected to the cloud platform with identifying the detected terminal by the preset system," triggering the bound/not-bound determination sequence. The claim does not recite whether these are mutually exclusive alternative embodiments (i.e., "either/or"), sequential steps both required in every transaction, or optional branches that may or may not occur. Because infringement of a method claim generally requires performance of every recited step, a POSA cannot determine with reasonable certainty which of the two branches — or both — must be performed for the claimed method to be practiced, or under what condition the method transitions from branch (a) to branch (b). This same ambiguity is present in claim 2 (which depends from claim 1) and in system claim 7, which recites the identical branching language.
"the verification program" lacks clear antecedent basis in the second branch. Claim 1 first introduces "a verification program" only within branch (a) above ("the cloud platform sends a verification program to the current detection terminal" when the detected terminal is not identified through the preset system). Claim 1 later recites, within the separate branch (b) fact pattern, "sending a second password and the verification program to the current detection terminal, when the cloud platform detects that the detected terminal is not bound to a detection terminal." Because branch (b) is a distinct, seemingly mutually exclusive scenario from branch (a) in which "the verification program" was originally introduced, it is unclear whether "the verification program" in branch (b) refers back to the verification program of branch (a) (which, on its face, arises under a different, inconsistent set of facts), or is intended to introduce an antecedent-less, potentially different, "the verification program" specific to branch (b). See MPEP § 2173.05(e). The same defect appears in claim 2, which similarly reintroduces "the verification program" in connection with sending a counterfeit alert message, and in system claim 7.
"a changed first password" versus "the changed first password" / relationship to "the changed password" in dependent claims. Claim 1 recites obtaining "a changed first password" and granting "exclusive view access to the changed first password." Claim 4, however, refers to "the changed first password" while claim 3 refers only to "the first password" and "the reference code" without clarifying how the "reference code" of claim 3 relates antecedently to the "changed first password" and "synchronizing the reference code" of claim 4 — i.e., claim 4 requires "synchronizing the reference code," but no antecedent "reference code" is separately established as distinct from (or the same as) the password values, rendering the synchronization step's object unclear. Clarifying amendment is suggested.
Applicant may overcome the rejections in this subsection by amending the claims to clearly delineate the two connection scenarios as express alternatives (e.g., "comprising one of the following: (a) … or (b) …"), by separately and consistently naming any "verification program" associated with each branch (e.g., "a first verification program" and "a second verification program"), and by ensuring every noun phrase preceded by "the" or "said" has a single, unambiguous antecedent.
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
35 U.S.C. § 112(f) — Means- (or Step-) Plus-Function Limitations (MPEP § 2181)
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) except as otherwise indicated in an Office action.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f).
Claim 7 recites the detection terminal as comprising "an access module," and the cloud platform as comprising "an identification module, a detection module, a verification module, a determination module, an access grant module, and a notification module," each performing recited functions (accessing, identifying, detecting, verifying, determining, granting access, and notifying, respectively).
Applying the three-prong test of MPEP § 2181(I) and Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1348 (Fed. Cir. 2015) (en banc):
Prong (A): The limitations use the generic placeholder "module" in lieu of "means." MPEP § 2181(I)(A) expressly lists "module for" among the common generic placeholders ("nonce" terms) that can invoke § 112(f) in place of "means."
Prong (B): Each "module" is modified by functional language (e.g., an "identification module" that "identifies a manner in which the current detection terminal accesses the cloud platform"; a "determination module" that "determines whether the bound detection terminal is the current detection terminal").
Prong (C): The generic term "module" is not modified by sufficient structure, material, or acts for performing the claimed functions; "module" is a purely functional label that, standing alone, does not connote a specific structure to a person of ordinary skill in the art.
Because all three prongs are satisfied, the "access module," "identification module," "detection module," "verification module," "determination module," "access grant module," and "notification module" limitations of claim 7 are being interpreted under 35 U.S.C. § 112(f). Corresponding structure was sought in the specification; however, the specification states only that "[t]he modules … may be entirely or partially implemented through software, hardware, or a combination thereof. The modules may be embedded in the hardware or separate from the processor … or may be stored in … software in a memory … , and that the processor invokes operations corresponding to the modules" ([0110]), without disclosing any algorithm, flowchart, or step-by-step procedure for performing the identifying, detecting, verifying, determining, access-granting, or notifying functions beyond restating the claimed functional outcome. For computer-implemented means-plus-function limitations, disclosure of a general-purpose processor alone, without disclosure of the specific algorithm used to perform the claimed function, is inadequate corresponding structure, rendering the claim indefinite under 35 U.S.C. § 112(b). Aristocrat Techs. Australia Pty Ltd. v. Int'l Game Tech., 521 F.3d 1328, 1333 (Fed. Cir. 2008); Blackboard, Inc. v. Desire2Learn, Inc., 574 F.3d 1371, 1385 (Fed. Cir. 2009). Because the specification here discloses no algorithm for any of the six recited modules, claim 7 (and any claim depending therefrom) is additionally rejected under 35 U.S.C. § 112(b) as indefinite for failure to disclose adequate corresponding structure for the claimed means-plus-function limitations.
Applicant may overcome this rejection by amending the "module" limitations to recite sufficient structure that avoids invocation of § 112(f) (e.g., "circuitry configured to …," if supported), or, if § 112(f) treatment is intended, by amending the specification and/or claims to disclose the specific algorithm(s) (e.g., in flowchart or step-by-step prose form, with reference to Figs. 1–5 and paragraphs [0065]–[0105]) that the processor executes to perform each claimed module's function.
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–8 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to patent-ineligible subject matter without significantly more. The eligibility analysis below follows the framework of MPEP § 2106 (Step 1, Step 2A Prong One, Step 2A Prong Two, and Step 2B), consistent with Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208 (2014), and Mayo Collaborative Servs. v. Prometheus Labs., Inc., 566 U.S. 66 (2012), as reflected in the current USPTO 2019 Revised Patent Subject Matter Eligibility Guidance and the August 2025 examiner reminder memorandum reiterating that framework.
Step 1 — Statutory Category (MPEP § 2106.03)
Claim 1 recites a method and therefore falls within the process category of 35 U.S.C. § 101. Claims 2–6 depend from claim 1, add no new statutory category, and remain method claims within the process category. Claim 7 recites a system comprising physical components (a detection terminal and a cloud platform, each reciting modules) and falls within the machine category. Claim 8 recites "a memory and a processor" and falls within the machine category. Claims 1–8 therefore satisfy Step 1 and require further analysis under Step 2A.
Step 2A, Prong One — Does the Claim Recite a Judicial Exception? (MPEP § 2106.04)
Independent claim 1 recites, in relevant part:
"…the current detection terminal sends a first password to the cloud platform for verification… the cloud platform discriminates the first password according to a preset comparison rule, when the cloud platform discriminates the first password to be correct, the cloud platform changes the first password according to a preset change rule to obtain a changed first password, grants the current detection terminal ordinary view access to product information and exclusive view access to the changed first password… and when the cloud platform discriminates the first password to be incorrect, the cloud platform sends a counterfeit alert message… determining whether the detection terminal bound to the detected terminal is the current detection terminal… granting the current detection terminal the ordinary view access to the product information, when the cloud platform detects that the bound detection terminal is the current detection terminal; and sending the counterfeit alert message to the current detection terminal, when the cloud platform detects that the bound detection terminal is not the current detection terminal."
Stripped of the generic computer nomenclature ("cloud platform," "detection terminal," "detected terminal"), claim 1 recites nothing more than: (i) receiving a code from a person seeking to verify a product's authenticity; (ii) comparing that code to a reference value; (iii) if the codes match, updating the reference value and granting the requester permission to view information and an exclusive right to the new code, while recording who now "holds" the product; (iv) if a second person later presents the code, determining whether that second person is the same person who was already recognized as the holder; and (v) allowing viewing if so, and issuing a warning if not. This is a scheme for certifying the authenticity of a good and controlling who may rely on that certification as it changes hands — i.e., verifying a transaction and guarding against fraud in the sale/resale of goods. It falls within at least two of the abstract-idea groupings identified in MPEP § 2106.04(a)(2):
Certain methods of organizing human activity — specifically, a commercial interaction (sales activity and behavior; business relations) analogous to guaranteeing or certifying the validity of a transaction, as in buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355 (Fed. Cir. 2014) (claims to "generating a transaction performance guaranty … in a computer-aided transaction" were directed to the abstract idea of "creat[ing] a contractual relationship – a 'transaction performance guaranty'"), and Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (a series of steps instructing how to use advertising as an exchange currency is an abstract idea).
Mental processes — the core operations of comparing a submitted code to a stored reference value and evaluating whether they match, and of determining whether the entity presenting the code is the same entity previously recognized, are observations, evaluations, and judgments that (but for the generic "cloud platform" and "terminal" labels) could be performed by a human, for example a shopkeeper checking a submitted password against a ledger entry and comparing the customer's identity to the last recorded purchaser. See CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372 (Fed. Cir. 2011) (a method of verifying the validity of a transaction by comparing it against information about past transactions is an unpatentable mental process, and use of the Internet does not impose meaningful limits).
Claims 7 and 8 recite the same abstract idea in system and device form, merely adding the words "module," "memory," and "processor" as generic implementing hardware. See Alice, 573 U.S. at 226 ("[T]he system claims are no different from the method claims in substance[; they] recite generic computer components configured to implement the same idea.").
Each of dependent claims 2–6 remains directed to the same abstract idea identified above; none introduces a different or additional judicial exception, as follows:
Claim 2: adds a parallel "second password" branch — comparing a second password, changing it, and granting or denying access accordingly — which is the identical certification/mental-process comparison-and-gatekeeping activity recited in claim 1, merely applied a second time to a second code value.
Claim 3: adds retrieving a "reference code" keyed to a "password storage address number" and comparing it to the first password — an indexing/lookup-and-compare operation that a human could perform manually (e.g., locating a ledger entry by an assigned number and comparing the values), and therefore remains within the mental-processes grouping.
Claim 4: adds generating "encrypted data" from a randomly generated UUID using the MD5 algorithm and using that value as the new password — a mathematical/algorithmic data-transformation step that does not change the fundamental character of the claim as directed to the same password-certification scheme; generating an identifier and applying a hash function are themselves the kind of abstract data-manipulation operations that do not integrate the exception into anything beyond the same certification activity.
Claim 5: adds performing the same password-comparison, changing, binding, and access-granting operations "synchronously" for a group of "product detected terminals" associated with a "package detected terminal" — i.e., applying the identical certification scheme in parallel to multiple related items, which remains "organizing human activity" (analogous to a warehouse clerk updating a batch of related records together) rather than a different or narrower judicial exception.
Claim 6: adds associating a detection-terminal ID code with the changed password in a "traceability table," matching an incorrect password against that table, and, once a preset numeric threshold of matches is reached, marking the password abnormal and sending an alert — i.e., recording, counting, and comparing data against a threshold, which are quintessential mental-process and data-analysis activities (evaluations and judgments a human record-keeper could perform by tallying repeat mismatches in a log and flagging an entry once a count is reached).
Step 2A, Prong Two — Practical Application? (MPEP § 2106.04(d))
Because claims 1–8 recite the abstract idea identified above, Prong Two asks whether the claim as a whole integrates the exception into a practical application. It does not.
The claims recite the abstract idea (password receipt, comparison, updating, and gatekeeping) performed using purely generic, result-oriented components: a "cloud platform," a "detection terminal," a "preset system," a "preset comparison rule," and a "preset change rule." None of these terms is limited to any particular technological implementation; the specification confirms this genericness, stating that the detection terminal "may be a chip," "a graphic code (QR code) or barcode," or "a commonly Internet communication equipment such as a mobile phone," ([0067]) and that the "cloud platform" performs generic identification, comparison, and messaging functions. The claims do not recite any improvement to the functioning of a computer or network itself (contrast DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1257 (Fed. Cir. 2014), where the claimed solution was "necessarily rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks"), nor do they recite a specific, non-conventional arrangement of generic components that improves the operation of those components themselves (contrast BASCOM Global Internet Servs., Inc. v. AT&T Mobility LLC, 827 F.3d 1341, 1350 (Fed. Cir. 2016)). Instead, the claims use generic computer components (cloud platform, terminal, memory, processor) as tools to carry out the abstract password-verification and gatekeeping scheme — i.e., "apply it" on a computer. This is precisely the kind of generic, functional-result claiming the Federal Circuit held ineligible in buySAFE, 765 F.3d at 1355, and Ultramercial, 772 F.3d at 715–16.
Applied specifically to each claim, none integrates the exception into a practical application:
Claims 1 and 7: use only generic "cloud platform," "detection terminal," "preset system," "preset comparison rule," and "preset change rule" components/modules to carry out the certification scheme, without reciting any technical mechanism for how connection, identification, or communication is technically achieved.
Claim 2: performs its added second-password comparison and update using the same undefined generic "cloud platform," adding no technical implementation detail.
Claim 3: recites retrieving data via a "password storage address number" — a generic, unspecified addressing/indexing scheme with no disclosed technical particulars — which is no more than a generic database lookup operation.
Claim 4: recites using an unspecified "password generation system" and generic, off-the-shelf UUID generation and MD5 hashing; the specification discloses no non-conventional or technically improved manner of generating or applying these values, so the claim merely selects known cryptographic building blocks to implement the abstract password-changing step.
Claim 5: recites performing claim 1's operations "synchronously" for package and product terminals without reciting any particular technical synchronization mechanism (e.g., a specific messaging protocol, timing scheme, or data structure) — "synchronously" is used only in its ordinary sense of contemporaneously, not as a technical improvement.
Claim 6: recites generic "traceability table" and "exception record table" data structures and a generic "preset threshold," with no disclosed technical mechanism for how the table is structured, searched, or indexed beyond ordinary database storage and lookup, and no disclosed technique for selecting the threshold value.
Claim 8: recites only a generic "memory" and "processor" executing a stored computer program to implement claim 1's steps — the quintessential "apply it" on a general-purpose computer, adding no technical improvement of its own.
Nor does any claim recite an improvement to another technology or technical field, effect a particular machine, effect a transformation of an article, or apply the exception in a meaningful way beyond generally linking it to a technological environment. Accordingly, claims 1–8 do not integrate the judicial exception into a practical application, and the claims are directed to the abstract idea under Step 2A.
Step 2B — Inventive Concept / "Significantly More" (MPEP § 2106.05)
Because the claims are directed to an abstract idea, Step 2B asks whether the claims recite additional elements, considered individually and as an ordered combination, that amount to significantly more than the abstract idea itself. They do not.
The only additional elements beyond the abstract idea are the generic "cloud platform," "detection terminal," "preset system," "memory," and "processor" recitations, and the further generic elements added by the dependent claims, addressed claim-by-claim below. The specification confirms that these are conventional, off-the-shelf components performing their well-understood, routine, and conventional functions. See MPEP § 2106.05(d); see also [0111-0114] (describing the "electronic device" generically as "a computer" with a "processor," "memory," "network interface," and "database," and listing conventional storage media such as "a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM)").
Claim 1: the only additional elements are the generic "cloud platform," "detection terminal," and "preset system" recitations, performing well-understood, routine, and conventional functions — receiving and sending data over a network, storing data, comparing two values, and updating a stored value. MPEP § 2106.05(d).
Claim 2: adds only a repetition of the same generic comparison, updating, and access-granting functions applied to a second password value using the same undefined "cloud platform" — the same category of well-understood, routine, conventional computer functions as claim 1, merely applied a second time.
Claim 3: adds retrieving a "reference code" via a "password storage address number." Indexed database lookup and retrieval by a stored address or key is one of the most basic, well-understood, routine, and conventional computer/database functions, of which official notice is taken. MPEP § 2144.03.
Claim 4: adds generating a UUID and applying the MD5 algorithm. Both are well-known, publicly available, off-the-shelf building blocks — MD5 has been a standard, publicly documented hashing algorithm since 1992 — and their use here is "insignificant extra-solution activity" (generating and appending a data value) rather than a technical improvement. MPEP § 2106.05(d), (g).
Claim 5: adds performing claim 1's operations for a group of related "product detected terminals" tied to a "package detected terminal." Extending an abstract scheme to operate on a related group of records, rather than a single record, is a generic scaling of the abstract idea using conventional database operations (e.g., updating multiple linked records), not an inventive concept.
Claim 6: adds populating a "traceability table" and "exception record table" and comparing a count to a "preset threshold" before sending an alert. Populating and querying database tables, counting occurrences, and comparing a count to a threshold are each routine, conventional data-processing functions; selecting a particular threshold value is, at most, routine optimization of a result-effective variable. MPEP §§ 2106.05(d), 2144.05(II).
Claim 7: recites the same additional elements as claim 1, reorganized into an "access module," "identification module," "detection module," "verification module," "determination module," "access grant module," and "notification module." As discussed below in connection with 35 U.S.C. § 112(f), the specification discloses no more than that these modules may be generic hardware, software, or a combination, with no algorithm or structure beyond the claimed function itself — confirming that the modules are nothing more than a generic, functional relabeling of claim 1's generic "cloud platform" limitation, not an inventive concept.
Claim 8: adds only a generic "memory" and "processor" that store and execute a computer program to implement claim 1. A general-purpose processor and memory executing stored instructions are among the most basic, well-understood, routine, and conventional computer components, of which official notice is taken. MPEP § 2144.03.
Considered individually or as an ordered combination, these additional elements amount to nothing more than "generic computer implementation" of the abstract idea and fail to supply the requisite inventive concept. Alice, 573 U.S. at 225–26; see also Mayo, 566 U.S. at 79–80 ("[S]imply appending conventional steps, specified at a high level of generality," is not "enough" to supply an inventive concept).
For these reasons, claims 1–8 are not patent eligible under 35 U.S.C. § 101.
Suggestion for Overcoming the § 101 Rejection
Applicant may be able to overcome this rejection by amending the claims to integrate the judicial exception into a practical application or to recite significantly more than the abstract idea - for example, by reciting a specific technical mechanism by which the "cloud platform" and "detection terminal" communicate and authenticate that is unconventional and solves a technical (as opposed to purely commercial) problem, analogous to the specific, claimed improvement to network-address-routing technology found eligible in DDR Holdings, or the specific, claimed non-conventional arrangement of filtering-tool components found eligible in BASCOM. Simply reciting additional generic hardware, or additional generic data-processing steps (e.g., further database lookups), is unlikely to overcome this rejection. Applicant's remarks addressing eligibility should be directed to the particular claim limitations discussed above.
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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
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.
Prior Art of Record
Primary Reference — Hu (CN 105096128 A), "Commodity anti-counterfeiting method and system characterized by identity code and auxiliary verifying passwords," published November 25, 2015 (priority May 5, 2014) ("Hu"). Hu discloses generating a unique identity code for a commodity, attaching the code to the commodity and its packaging, and, upon a purchaser reading the code with a mobile/reader device, connecting over a network to a server to verify authenticity. On first-time verification the system authenticates the item and prompts the user to set a new verifying password (or assigns one by a default rule if the user does not); the password is required to be obtained from the immediately preceding verifying user for any subsequent verification, and each successful verification updates ("changes") the stored password to a new value set by the current user. A mismatch is flagged as a suspected counterfeit and logged in the server database as abnormal-verification information. Hu is prior art under 35 U.S.C. § 102(a)(1)/(a)(2) at least as of its 2015 publication date, more than nine years before the critical date.
Secondary Reference — Jiang et al. (CN 105590227 A), "Dynamic verification method, apparatus, and system of authenticity of commodity," published May 18, 2016 (priority January 14, 2016) ("Jiang"). Jiang discloses a verification device that authenticates a commodity either (i) by scanning a printed QR code or (ii) by reading anti-counterfeiting chip information directly, generating authentication information, and sending it to a remote "authentication center" that matches the submitted information against pre-stored information in a database; when the match succeeds, the authentication center updates ("when the authentication result is passed, updating the pre-stored information matching the authentication information") the stored reference information, and synchronously instructs the on-product chip to update its own stored anti-counterfeiting information, keeping the two synchronized. Jiang further discloses that the authentication center can respond to manufacturer queries regarding authentication status. Jiang is prior art under § 102(a)(1)/(a)(2).
Secondary Reference — Wang (WO 2016/145705 A1), "Time-based encrypted NFC cell phone terminal anti-counterfeit system and method," published September 22, 2016 (priority March 13, 2015) ("Wang"). Wang discloses an NFC anti-counterfeit tag that, upon being read by a cell-phone (mobile) terminal, participates in a challenge/response scheme in which a time value is used together with a per-tag secret ("time seed") to generate encrypted check data (a hash) using a one-way encryption algorithm; the mobile terminal relays the tag's identifier and hash to a background database management server, which independently regenerates the expected hash using the same algorithm and the server's own stored time seed, compares the two hash values, and returns a pass/fail verification result to the mobile terminal. Wang is prior art under § 102(a)(1)/(a)(2).
Claims 1-4, 7, 8 are rejected under 35 U.S.C. 103 as being unpatentable over: Hu; in view of Jiang; in further view of Wang.
19/399, 749 – Claim 1. Hu teaches A variable anti-counterfeiting method for a product sales terminal, comprising: connecting a current detection terminal to a cloud platform by identifying a detected terminal, wherein the cloud platform identifies a manner in which the current detection terminal is connected to the cloud platform (Hu [0008, (Step S1): the manufacturer generates a unique identity code for each commodity via the system and attaches it to the commodity and packaging; "verification user" reads the unique commodity identity code on the commodity/packaging using read-write equipment, then connects to the system's server over a network to verify.][0044: consumer may install a dedicated APP to perform "mobile online scanning verification."] Hu's reading device/mobile-app terminal and server architecture correspond to the claimed detection terminal / cloud platform, connected by identifying (reading) the detected terminal's identity code.), comprising: when the current detection terminal is connected to the cloud platform without identifying the detected terminal through a preset system, the cloud platform sends a verification program to the current detection terminal, the current detection terminal sends a first password to the cloud platform for verification, wherein the first password is provided by a previous seller (Hu [0045: when purchasing, the consumer need only scan the commodity identity code with a phone and "obtain the verification password from the seller" to complete verification.][0010, (Step S3): the password is "obtained from the previous verification user."] Jiang [0012; 0014: verification device scans a two-dimensional (QR) code and generates authentication information from the QR-code information together with the anti-counterfeit-chip information — a path requiring no chip-level preset protocol.] Hu [0045: discloses, in language closely tracking the claim, that the party verifying a commodity obtains the password directly from the seller.] Before the effective filing date of the claimed invention, it would have been obvious to a ‘Person of Ordinary Skill In The Art’ (POSITA) to have modified Hu to include Jiang's QR-code-scan verification path (no preset chip protocol) with this seller-to-buyer password hand-off, as both are alternative, art-recognized item-verification entry points serving the same authenticity-confirmation purpose; combining known elements according to known methods to yield predictable results. KSR, 550 U.S. at 416.), the cloud platform discriminates the first password according to a preset comparison rule, when the cloud platform discriminates the first password to be correct, the cloud platform changes the first password according to a preset change rule to obtain a changed first password, grants the current detection terminal ordinary view access to product information and exclusive view access to the changed first password (Hu [0009-0010, (Steps S2–S3): server compares the submitted password to the stored value; upon a correct password, "the verification password of the commodity identity code is changed to the new verification password set by the current verification user … and the corresponding replacement is completed in the system database."][0015: "the new verification password is also synchronously modified in the database … the new verification password is known only to the current verification user."] Hu expressly teaches comparing, and, upon success, changing the stored password and conveying the new password value together with information access to the verifying (i.e., now-authorized) user, meeting this limitation.), and simultaneously incorporates the detected terminal into a warehousing system associated with the current detection terminal (Hu [0040: the manufacturer may, according to its commodity warehousing/shipping packaging specifications, use the system's identity-code layer-binding submodule to set a parent-child relationship - the shipped large-package identity code as "parent" and each individual commodity identity code within the package as "child."][0020: (Claim 10 subject matter): the system further includes "manufacturer shipment and logistics management" and "identity-code layer-by-layer binding."] Recording the newly-verified item within Hu's own disclosed warehousing/logistics-management binding structure is a predictable extension of Hu's chain-of-custody password hand-off; a POSITA would have found it obvious to associate a verified item with the verifying party's own warehousing records for the record-keeping purpose Hu already discloses.), and when the cloud platform discriminates the first password to be incorrect, the cloud platform sends counterfeit alert message to the current detection terminal (Hu [0017: if the verification password is incorrect, the product "is displayed as suspected counterfeit, and is stored as abnormal-verification record information in the database server, for inspection by the manufacturer and relevant department."]);
Hu may not expressly disclose the following, however, Jiang teaches detecting by the cloud platform whether the detected terminal is bound to a detection terminal, when the detection terminal is connected to the cloud platform with identifying the detected terminal by the preset system (Jiang [0016: reading the anti-counterfeit information in the chip is performed "through Bluetooth" - a device-level preset protocol, as distinct from Jiang's own QR-scan path], see also [0012; 0014][0022-0026: the authentication center receives the authentication information and "matches the authentication information against pre-stored information in the database," determining a pass/fail result.]); Before the effective filing date of the claimed invention, it would have been obvious to a ‘Person of Ordinary Skill In The Art’ (POSITA) to have modified Hu to include Jiang's Bluetooth chip-reading path (a "preset system" protocol, as opposed to Jiang's own alternative QR-scan path) discloses this alternative connection/detection branch; combining it with Hu's password-based scheme is a predictable use of Jiang's own disclosed alternative verification path for the same authenticity-checking purpose – combining known elements according to known methods to yield predictable results.).
Hu may not expressly disclose the following, however, Jiang and Wang teach sending a second password and the verification program to the current detection terminal, when the cloud platform detects that the detected terminal is not bound to a detection terminal, binding the detected terminal to the current detection terminal after successful verification, granting the current detection terminal the ordinary view access to the product information, and notifying the current detection terminal that a product is genuine (Jiang [0018; 0028: when the authentication result passes, the system "updates the pre-stored information matching the authentication information" and sends "update information to the anti-counterfeit chip, so that the anti-counterfeit chip updates the anti-counterfeit information according to the update information."] Jiang [0010; Claim 1: the process concludes with "receiving the authentication result, and prompting the authentication result."][Wang, p. 2 (Step 4): the background system "sends the result of the verification data to the cell-phone client" after comparing the regenerated and received hash values.] Jiang teaches associating (binding) the authenticated item's updated code with the verifying session and synchronously updating both server and chip records and prompting/notifying the result; Wang independently corroborates returning a verification result to the requesting mobile terminal); Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Hu to include the features as taught by Jiang and Wang. A POSITA combining these known result-reporting and record-updating techniques with Hu's base scheme would predictably arrive at binding plus a genuineness notification.).
Hu further teaches determining whether the detection terminal bound to the detected terminal is the current detection terminal, when the cloud platform detects that the detected terminal is bound to the detection terminal; granting the current detection terminal the ordinary view access to the product information, when the cloud platform detects that the bound detection terminal is the current detection terminal; and sending the counterfeit alert message to the current detection terminal, when the cloud platform detects that the bound detection terminal is not the current detection terminal (Hu [0015: the new verification password is "known only to the current verification user" such that "no one else can re-verify this commodity identity code."][0042: once a downstream party verifies, the upstream party "is thereafter completely unable to successfully re-verify" that commodity.][0017: a mismatch is displayed as suspected counterfeit and logged.] Because Hu already conditions successful re-verification on the requesting party possessing the specific password known only to the previously-recognized current possessor - and expressly discloses that any other (e.g., upstream/prior) party is thereafter locked out - a POSITA would understand Hu (as modified by Jiang's binding/update teaching, noted above) to render obvious determining whether the current requester is the previously-bound party and branching to either continued access or a counterfeit alert accordingly.).
A Person of Ordinary Skill In The Art (POSITA) would have had reason to combine Hu, Jiang, and Wang because all three references address the same problem – verifying the authenticity of a physical commodity at the point of sale/resale using a code compared against a remote data store, while preventing re-use of compromised or stale codes – and each reference is drawn from the same field of anti-counterfeiting/product-authentication technology. Combining Jiang's dual entry-path (QR scan vs. Bluetooth chip read) and code-synchronization teachings, and Wang's mobile-terminal notification and hash-based code-regeneration teachings, with Hu's base password hand-off and abnormal-record logging scheme involves nothing more than the combination of known prior-art elements, each performing the same function it was known to perform, to yield the predictable result of a more robust, dual-path verification scheme. KSR, 550 U.S. at 416 ("[W]hen a patent claims a structure already known in the prior art that is altered by the mere substitution of one element for another known in the field, the combination must do more than yield a predictable result." — here it does no more). The combination would also have been motivated by Hu's own single QR/mobile-app verification path not addressing chip-based, preset-protocol identification, which Jiang expressly supplies, providing an explicit, art-based reason (rather than hindsight) to combine.
19/399, 749 – Claim 2. Hu further teaches The method according to claim 1, wherein detecting by the cloud platform whether the detected terminal is bound to the current detection terminal when the current detection terminal is connected to the cloud platform with identifying the detected terminal by the preset system further comprises: sending the second password and the verification program to the current detection terminal (Hu [0008-0010; 0015; 0017; 0020; 0040; 0044; 0045; Steps S1-S3]), when the cloud platform detects that the detected terminal is not bound to the detection terminal, binding the detected terminal to the current detection terminal after successful verification, simultaneously, changing by the cloud platform the second password according to the preset change rule to obtain a changed second password (Hu [0008-0010; 0015; 0017; 0020; 0040; 0044; 0045; Steps S1-S3]), granting by the cloud platform the current detection terminal the ordinary view access to the product information and the exclusive view access to the changed second password; determining whether the bound detection terminal is the current detection terminal (Hu [0008-0010; 0015; 0017; 0020; 0040; 0044; 0045; Steps S1-S3]), when the cloud platform detects that the detected terminal is bound to the detection terminal (Jiang [0018; 0028: "when the authentication result is passed, updating the pre-stored information matching the authentication information," with a synchronous chip-side update via "update information."] Applying Jiang's update-on-success teaching (already relied upon for claim 1's binding branch) to the bound/second-password branch is the same known technique applied a second time for its known purpose — preventing reuse of a previously-verified code.); granting the current detection terminal the ordinary view access to the product information and the exclusive view access to the changed second password, when the cloud platform detects that the bound detection terminal is the current detection terminal (Hu [0015: password "known only to the current verification user"; commodity information displayed "for the verification user to compare."] Same rationale as claim 1's corresponding limitation — the recognized current possessor alone receives continued viewing/exclusive access.); and sending the counterfeit alert message and the verification program to the current detection terminal, when the cloud platform detects that the bound detection terminal is not the current detection terminal (Hu [0008-0010; 0015; 0017; 0020; 0040; 0044; 0045; Steps S1-S3]), and granting the current detection terminal the ordinary view access to the product information when the cloud platform receives the changed second password and successfully verifies the changed second password (Jiang [0022; 0026: authentication center receives and "matches the authentication information against … pre-stored information in the database" to determine pass/fail, each cycle.] Hu [0017: mismatch → counterfeit alert and abnormal-record logging.] Re-verifying a subsequently-presented changed second password against the authentication center's stored record (Jiang) and branching to an alert on mismatch (Hu) is the same matching/branching logic already shown for claim 1, applied to the renewed password value – a predictable, repeated application of known technique.).
19/399, 749 – Claim 3. Hu further teaches The method according to claim 1, wherein a step of discriminating the first password according to the preset comparison rule by the cloud platform comprises (Hu [0008-0010; 0015; 0017; 0020; 0040; 0044; 0045; Steps S1-S3]): retrieving a reference code based on a password storage address number of the detected terminal ([Wang, p. 2 (Step 3): the background database system, upon receipt, looks up the time seed of the corresponding tag based on the product ID — i.e., retrieves a stored reference value keyed to a specific per-product storage location/record identified from information carried by the tag.] It would have been obvious to implement Hu's per-commodity password lookup ([0008-0010], tying each password to a specific commodity identity code) using an indexed, ID-keyed storage-address retrieval scheme as taught by Wang – a routine, conventional database-design technique for retrieving a per-item reference value. ) and comparing the first password with the reference code by the cloud platform, the password storage address number of the detected terminal is contained in verification information of the detected terminal (Hu [0008-0010; 0015; 0017; 0020; 0040; 0044; 0045; Steps S1-S3]); determining the first password to be correct when the first password is consistent with the reference code; and determining the first password to be incorrect when the first password is inconsistent with the reference code (Hu [0009-0010: (comparison against stored value; success = genuine)] Hu [0017: (incorrect = displayed as "suspected counterfeit")] Directly taught by Hu; combined with Wang's ID-keyed retrieval.).
19/399, 749 – Claim 4. Hu further teaches The method according to claim 3, Hu may not expressly disclose the following, however, Wang teaches wherein a step of changing the first password according to the preset change rule comprises: automatically triggering a password generation system to generate encrypted data when the cloud platform discriminates the first password to be correct, setting the encrypted data as the changed first password, and synchronizing the reference code ([Wang, p. 1 (Step 1): on each verification cycle the tag (obtains check data hash by one-way-encrypting data). Wang, p. 2 (Step 3): the background system independently (uses the same encryption algorithm to obtain check data hash0), i.e., automatically (re)generating and synchronizing an encrypted value between the two sides on each cycle.] It would have been obvious to trigger Wang's automatic encrypted-value-(re)generation technique upon Hu's own password-change event on successful verification ([0009-0010]), synchronizing the newly generated value as the server-side reference code, per Wang's own synchronized dual-side computation.); a step of generating the encrypted data by the password generation system comprises randomly generating a Universally Unique Identifier (UUID) as a data source for encryption, and using an MD5 encryption algorithm to encrypt the data source to obtain the encrypted data ([Wang, p. 3: (the time seed in the encryption algorithm is uniquely recorded in the background system, is random, and cannot be copied) - a random per-cycle data source. Wang, Claim 1 / p. 5: the tag's internal encryption algorithm is expressly "a one-way encryption algorithm, which is irreversible" - consistent with MD5's function as a one-way message-digest algorithm. No specific algorithm name (e.g., MD5, SHA) is disclosed by Wang.] UUID generation and the MD5 algorithm are each well-known, publicly available, off-the-shelf building blocks that a POSITA would have recognized as routine, predictable choices for implementing Wang's genus-level "random … data source" and "one-way encryption algorithm" - an obvious species substitution within an art-recognized genus, not a technical advance. KSR, 550 U.S. at 421.).
19/399, 749 – Claim 7. Hu further teaches A variable anti-counterfeiting system for a product sales terminal, comprising a detection terminal and a cloud platform (Hu [0008-0010; 0015; 0017; 0020; 0040; 0044; 0045; Steps S1-S3]), wherein the detection terminal comprises an access module, the cloud platform comprises an identification module, a detection module, a verification module, a determination module, an access grant module, and a notification module; the detection terminal is connected to the cloud platform through the access module by identifying a detected terminal (Hu [0019: (Claim 9 subject matter) a read-write and display device for reading the commodity identity code, communicating with the database server, and modifying the verification password.] Hu [0008: (reader connects to server by reading the code)] Hu's read-write/display device is the structural analog of the claimed "access module" of the detection terminal, performing the identical connecting/identifying function.), the cloud platform identifies a manner in which a current detection terminal is connected to the cloud platform, comprising (Hu [0008-0010; 0015; 0017; 0020; 0040; 0044; 0045; Steps S1-S3]): when the current detection terminal is connected to the cloud platform without identifying the detected terminal through a preset system, the cloud platform sends a verification program to the current detection terminal, the current detection terminal sends a first password to the cloud platform for verification, wherein the first password is provided by a previous seller (Hu [0008; 0045 - (server-side identification of access manner; password obtained "from the seller")] Jiang [0012; 0014: (QR-scan path)] Same combination and rationale as claim 1, with the identifying function attributed to an "identification module" of Hu's server system — a routine software-organization choice. Before the effective filing date of the claimed invention, it would have been obvious to a ‘Person of Ordinary Skill In The Art’ (POSITA) to have modified Hu to include features taught by Jiang - combining known elements according to known methods to yield predictable results.), the cloud platform discriminates the first password according to a preset comparison rule, when the cloud platform discriminates the first password to be correct, the cloud platform changes the first password according to a preset change rule to obtain a changed first password, grants the current detection terminal ordinary view access to product information and exclusive view access to the changed first password (Hu [0009-0010; 0015: (password change on success; exclusive knowledge by current user)]), and simultaneously incorporates the detected terminal into a warehousing system associated with the current detection terminal (Hu [0040: (parent/child warehousing binding)] Hu [0020: (Claim 10 subject matter — manufacturer logistics management)]), and when the cloud platform discriminates the first password to be incorrect, the cloud platform sends counterfeit alert message to the current detection terminal (Hu [0017: (abnormal record on mismatch)] the alerting function attributable to the claimed "notification module"), the cloud platform detects whether the detected terminal is bound to a detection terminal, when the detection terminal is connected to the cloud platform with identifying the detected terminal by the preset system (Jiang [0016: (Bluetooth chip-read path)][0022-0026: (authentication-center matching)] detecting function attributable to the claimed "detection module." Before the effective filing date of the claimed invention, it would have been obvious to a ‘Person of Ordinary Skill In The Art’ (POSITA) to have modified Hu to include features taught by Jiang - combining known elements according to known methods to yield predictable results.), when the cloud platform detects that the detected terminal is not bound to a detection terminal, a second password and the verification program are sent to the current detection terminal by the verification module, the detected terminal is bound to the current detection terminal after successful verification, and the current detection terminal is granted the ordinary view access to the product information (Jiang [0018; 0028; 0010 (update-on-success, chip synchronization, result prompt)][Wang, p. 2 (verification result returned to mobile client)] the sending/binding function attributable to the claimed "verification module." Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Hu to include the features as taught by Jiang and Wang. A POSITA combining these known result-reporting and record-updating techniques with Hu's base scheme would predictably arrive at binding plus a genuineness notification.); the determination module determines whether the detection terminal bound to the detected terminal is the current detection terminal when the cloud platform detects that the detected terminal is bound to the detection terminal (Hu [0015; 0042: (password known only to current/bound possessor; prior party locked out)] the determining function attributable to the claimed "determination module."); the current detection terminal is granted the ordinary view access to the product information by the access grant module, when the cloud platform detects that the bound detection terminal is the current detection terminal; and the notification module sends a counterfeit alert message to the current detection terminal, when the cloud platform detects that the bound detection terminal is not the current detection terminal (Hu [0015: (continued access for the recognized possessor)] Hu [0017: (alert on mismatch)] outcomes attributable to the claimed "access grant module" and "notification module," respectively. Hu [0018: Claim 8 recites various modules]).
19/399, 749 – Claim 8. Hu further teaches An electronic device, comprising a memory and a processor, wherein the memory stores a computer program capable of being loaded and executed by the processor to implement the variable anti-counterfeiting method for a product sales terminal according to claim 1 (Hu's disclosed "native system" server, which performs the reading, comparison, password-changing, and database-update operations of Claim 1, necessarily comprises a processor and a memory storing the executable program logic for those operations; a general-purpose server processor and memory are among the most basic, well-understood, routine, and conventional computing components, of which official notice is taken under MPEP § 2144.03. Applicant's specification confirms the generic, off-the-shelf nature of this hardware, describing the "electronic device" only in terms of a generic "processor," "memory," "network interface," and conventional storage media ("a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM)"). Implementing the Hu/Jiang/Wang combination of claim 1 on such a conventional memory-plus-processor computing platform would have been obvious to a POSITA and is rejected on that basis.).
No Prior-art Rejection / Potentially Allowable
Claims 5 and 6 cannot be rejected with prior-art. Individual claimed features are taught in the prior-art, however, the unique combination of features and elements are not taught by the prior-art without hindsight reasoning. These claims are further rejected to as being dependent upon a rejected base claim but might possibly be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
19/399, 749 – Claim 5. Hu further teaches The method according to claim 1, wherein the detected terminal comprises a package detected terminal and a product detected terminal (Hu [0040: “the manufacturer may set a parent-child relationship via the system's identity-code layer-binding submodule: the large-package identity code is the "parent," and each individual commodity identity code within the package is the "child"; this relationship "can extend upward into multiple layers."] Hu discloses, essentially verbatim, a package-level ("parent"/large-packaging) code and product-level ("child") codes as part of the same identity-code system.), when the cloud platform performs an operation on the package detected terminal, the cloud platform synchronously performs an operation on product detected terminals within the package; when the cloud platform changes the first password of the package detected terminal, the cloud platform synchronously changes first passwords of the product detected terminals within the package; when the cloud platform binds the current detection terminal with the package detected terminal, the cloud platform synchronously binds the current detection terminal with the product detected terminals within the package; when the cloud platform grants the current detection terminal the exclusive view access to the first password of the package detected terminal, the cloud platform synchronously grants the current detection terminal the exclusive view access to the first passwords of the product detected terminals within the package; and when the cloud platform grants the current detection terminal the ordinary view access to the first password of the package detected terminal, the cloud platform synchronously grants the current detection terminal the ordinary view access to commodities of the product detected terminals within the package (Hu [0041: after the manufacturer ships, each distributor need only read/verify the parent ("logistics") code to complete receipt confirmation and password modification; the child-level identity codes attached to that logistics code synchronously complete password modification, and the actual holder of the batch changes to the currently-verifying distributor.] Jiang [0018; 0028: (an independent, cumulative teaching that a passing verification result triggers synchronized update propagation from the authenticating record to an associated record).] Hu [0041: itself expressly teaches that verifying and changing the password of the package-level code causes synchronous password modification of the associated product-level codes, and a synchronous change in the recognized holder (binding) — i.e., nearly the full substance of claim 5's requirement that package-level operations propagate synchronously to product-level terminals. To whatever extent claim 5's separate recitation of synchronized exclusive-view-access and ordinary-view-access grants is not already subsumed in Hu's disclosed synchronized password-modification-and-holder-transfer event, extending that synchronization to the view-access grants that Hu ties to the same password event (see claim 1 mapping above) would have been obvious as the predictable, intended consequence of Hu's own disclosed parent/child code architecture for bulk distribution.]).
19/399, 749 – Claim 6. The method according to claim 1, wherein a step of sending the verification program to the current detection terminal by the cloud platform further comprises: acquiring an identification (ID) code of the current detection terminal by the cloud platform while sending the verification program by the cloud platform to the current detection terminal to obtain the first password, associating the ID code of the current detection terminal with the changed first password when the first password is correct and replaced, and registering an associated relationship between the ID code of the current detection terminal and the changed first password in a traceability table; and matching, when the first password is incorrect, the first password with first passwords in the traceability table by the cloud platform, when the matching is successful, the ID code of the current detection terminal is registered in an exception record table corresponding to the first password, when a number in the exception record table reaches a preset threshold, the first password in the traceability table is marked as abnormal and the cloud platform is triggered to send an infringement alert message and an abnormal data package to a production terminal, and the abnormal data package comprises the first password and the ID code of an associated detection terminal.
Examiner’s Response to Arguments
Per Applicants’ amendments/arguments, the rejections are withdrawn.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Examiner’s Response: Claim Rejections – 35 USC §112
Per Applicants’ amendments/arguments, the rejections are withdrawn.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Examiner’s Response: Claim Rejections – 35 USC §101
Per Applicants’ amendments/arguments, the rejections are withdrawn. See notes above for additional reasoning and rationale for dropping 35 USC 101 rejection including Applicant’s amendments, arguments, lack of abstract idea, and practical integration.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Regarding Claims 1-15, on page(s) 6-12 of Applicant’s Remarks (dated 12/27/2016), Applicants traverse the 35 USC §101 rejections arguing the following:
Examiner’s Response: Claim Rejections – 35 USC § 103
Per Applicants’ amendments/arguments, the rejections are withdrawn. See notes above for additional reasoning and rationale for dropping prior-art rejection including Applicant’s amendments and arguments and unique combination of features and elements not taught by the prior-art without hindsight reasoning.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Regarding Claim X, on page(s) 8-9 of Applicant’s Remarks / After Final Amendments (dated 07/15/2011), Applicant(s) argues that the cited reference(s) (Ellis and Vandermolen) fails to teach, describe, or suggest the amended features. Specifically, Applicant(s) argues that cited reference(s) do not teach, describe, or suggest the following: . With respect, Applicant’s arguments are deemed unpersuasive and the amended feature(s) remain rejected as follows.
With respect, Applicant’s arguments are deemed unpersuasive and the amended feature(s) remain rejected as follows.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
PERTINENT PRIOR ART – Patent Literature
The prior-art made of record and considered pertinent to applicant's disclosure.
The following references were identified during the search for Application No. 19/399,749 (US 2026/0080420 A1), directed to a variable anti-counterfeiting method, system, device, and medium for a product sales terminal.
EP 3690691 B1 (Method for RFID Tag Authentication): Discloses a blockchain-based RFID/NFC tag authentication scheme for supply-chain goods in which tags store trust-provisioning data (unique identifiers, public keys, shared secrets) in a secure element, and “one-side” authentication is performed by a reader without requiring a continuous online connection to a central platform. Authentication events are written to a distributed ledger shared among manufacturer, distributor, and retailer nodes, providing a continuous record of product location and status. Relevant to the general concept of a reader/detection terminal authenticating a tagged article and to multi-party (manufacturer/distributor/retailer) tracking of authentication events, analogous to the warehousing system into which the current detection terminal is incorporated. Does not disclose a cloud platform that discriminates a password against a stored reference code, changes the password upon successful discrimination, or determines whether a detected terminal is “bound” to a particular detection terminal.
US 8,421,593 B2 (Apparatus, Systems and Methods for Authentication of Objects Having Multiple Components): Discloses authenticating multi-component objects using asymmetric encryption: an object identifier encrypted with a manufacturer’s private key encodes component identification and arrangement data, which a reader decrypts (public key) and compares against the physically inspected object and, optionally, a manufacturer database. Each identifier includes randomized, single-use data to defeat replication, and a second, distributor-side encryption layer (an “ownership certificate”) tracks legitimate chain-of-custody. Relevant to the cloud/server-side comparison of received identification data against reference data to discriminate genuine from counterfeit articles, and to the use of single-use/randomized credentials generally analogous to the changed password of the pending claims. Does not disclose a detection-terminal-to-detected-terminal binding step, a two-tier (first/second) password scheme, or differentiated ordinary-view/exclusive-view access grants.
US 10,019,530 B2 (ID Tag Authentication System and Method): Discloses NFC/RFID tags encoded during manufacture with a digitally signed message (a URL, optional serial number, and hardware attributes); a reader (e.g., smartphone) verifies the signature and compares read hardware attributes to detect tag cloning. A web server correlates serial numbers and hardware attributes, tracks verification events, and sends alerts to manufacturers (or the reader) upon detecting cloning or fraudulent activity. Relevant to server-side tracking of verification events and to sending an alert message when discrimination indicates a counterfeit, generally analogous to the cloud platform’s counterfeit alert and to the exception-record/traceability-table logging of the pending claims. Does not disclose discriminating a password against a preset comparison rule, changing the password/credential upon successful verification, or a terminal-binding determination.
US 2018/0205714 A1 (System and Method for Authenticating Electronic Tags): A related disclosure (same general assignee/technology as US 10,019,530 B2) directed to NFC/RFID tags storing a private key that cannot be read out, used to bind a digital signature to both the tag and the key so that cloned tags can be detected when a signature is valid but hardware attributes do not match. A web server database correlates tag identifiers with product records, supports HTTP-query-based verification with redirect functionality, and offers both online and offline verification modes, including geolocation-based analytics to identify likely counterfeiting locations. Relevant to the claimed step of the cloud platform identifying “a manner in which the current detection terminal accesses the cloud platform” (e.g., with or without identifying the detected terminal through a preset system), and to server-side verification generally. Does not disclose the specific first/second password discrimination-and-change sequence, the ordinary-view/exclusive-view access distinction, or the package/product detected-terminal synchronization of the pending claims.
US 2015/0022314 A1 (Method for Authenticating an RFID Tag): Discloses a challenge-response scheme in which a reader transmits a randomized sequence of “correct” and “incorrect” passwords (derived via an identifier and a key using a one-way hash function) to an RFID tag; a genuine tag responds only to the correct password, while a counterfeit or cloned tag responds indiscriminately, revealing itself. Tags found to respond improperly are logged to a blacklist. Closely relevant to the pending claims’ discrimination of a password received from a detection terminal against a reference code to determine whether the password is “correct” or “incorrect,” and to the exception-record-table/blacklist concept triggered by improper password responses. Does not disclose changing the password upon a correct determination, binding a detected terminal to a detection terminal, or differentiated view-access grants.
US 11,398,898 B2 (Secure RFID Communication Method): Discloses mutual (two-way) cryptographic authentication between an RFID reader and transponder via exchange of random numbers, without transmitting an encryption key, for anti-counterfeiting of luxury goods. The transponder operates in locked/unlocked modes, with stored data (including traceability and authenticity information, optionally via a networked authentication platform/database) rendered inaccessible until the reader is authenticated. Relevant to gating access to stored product information on successful authentication, generally analogous to the pending claims’ grant of ordinary-view and exclusive-view access to product information following successful password discrimination or binding verification. Does not disclose a password-versus-reference-code discrimination step, a password-changing mechanism, or a determination of whether a bound detected terminal corresponds to the current detection terminal.
CN 111210229 A (Product Circulation Authenticity Verification Method): Discloses an NFC-tag-based (NTAG424) product verification system using a mobile detection terminal and a cloud server: the mobile terminal reads the tag, obtains a dynamic security authentication number (a rotating password/credential) from the cloud service, and returns encrypted verification data; the cloud server checks the dynamic authentication number, digital signature, and a monotonically increasing read counter (with log-chain analysis of circulation anomalies) to detect copied or replayed tags. This is among the closer references of the group: it discloses a detection terminal communicating with a cloud platform to obtain and submit a dynamically changing password/credential for discrimination, generally analogous to the claimed password discrimination-and-change sequence. It does not, however, disclose the claimed two-password (first/second) structure tied to a binding determination between a detected terminal and a current detection terminal, the differentiated ordinary-view/exclusive-view access grant, or the package-detected-terminal/product-detected-terminal synchronization scheme.
CN 114529313 A (Anti-Counterfeiting Method, Anti-Counterfeiting Verification Method and Anti-Counterfeiting Verification System): Discloses a dual-code anti-counterfeiting architecture using a visible “clear code” (QR code, scanned at logistics sign-in) and a hidden “secret code” (revealed by removing packaging/coating, scanned for verification). Activation requests from successive supply-chain nodes (manufacturer, distributor, retailer) are validated against pre-allocated scan positions, with authenticity determined once the secret code accumulates a required number of valid activations; anomalous-location activations are logged, and compromised codes can be invalidated and reissued mid-distribution. Relevant to the incorporation of a detected/detection terminal into a warehousing or logistics tracking system and to flagging/invalidating credentials in response to anomalous verification activity, loosely analogous to the package-detected-terminal grouping and to the counterfeit-alert logic of the pending claims. Does not disclose the claimed password discrimination against a reference code performed by a cloud platform, the password-changing step, or the binding determination between a detected terminal and a current detection terminal.
Kase 2026/0050935 Abstract: A system and method are disclosed for tracking and verifying authenticity, loss, fraud, or unauthorized use of assets within a supply chain. The method includes scanning a multimodal tag (e.g., QR code and NFC tag) associated with an asset to generate scan data comprising a hash code, asset identifier, and verification URL. The scan data is transmitted to an application server of a parent organization, where a controller retrieves associated location and organization identifiers. The controller determines authorization status, compares the hash code with reference values in a verification database, and performs authenticity checks to classify the asset as genuine, lost, duplicated, or pirated. The system integrates with a CRM platform to register new child organizations using data synchronization objects comprising payloads, callout instructions, and error handling. AI-based analysis may detect route deviations, fraudulent insertions, or asset misuse patterns based on route history and scanning behavior.
PERTINENT PRIOR ART – Non-Patent Literature (NPL)
The NPL prior-art made of record and considered pertinent to applicant's disclosure.
Z. Ru and C. Peng, "Anti counterfeiting traceability system based on microservice architecture," 2022 4th International Conference on Frontiers Technology of Information and Computer (ICFTIC), Qingdao, China, 2022, pp. 706-711, doi: 10.1109/ICFTIC57696.2022.10075148.
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 extension fee 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.
THIS ACTION IS MADE FINAL
Applicant’s amendment necessitated new grounds of rejection and FINAL Rejection.
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 extension fee 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 date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW T. SITTNER whose telephone number is (571) 270-7137 and email: matthew.sittner@uspto.gov. The examiner can normally be reached on Monday-Friday, 8:00am - 5:00pm (Mountain Time Zone). Please schedule interview requests via email: matthew.sittner@uspto.gov
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah M. Monfeldt can be reached on (571) 270-1833.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MATTHEW T SITTNER/
Primary Examiner, Art Unit 3629b
Prosecution Insights