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 .
DETAILED ACTION
This action is responsive to the application filed on 10/21/2024. In the application, preliminary amendments for claims filed on 10/21/2024 have been considered. In which
Claims 1, 16 and 32 are independent,
Claims 3, 8-10, 12-15, 18, 23-25, 27-29, 31, 34, 37-41 and 43-47 have been cancelled,
Claims 1-2, 4-7, 11, 16-17, 19-22, 26, 30, 32-33, 35-36 and 42 are pending and being considered.
Claims 1-2, 4-7, 11, 16-17, 19-22, 26, 30, 32-33, 35-36 and 42 are rejected.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/21/2024 and 01/10/2025 were filed on or after the mailing date of the application no.18/858,376 filed on 10/21/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner and an initialed and dated copy of Applicant’s IDS form 1449 filed on 10/21/2024 and 01/10/2025 are attached to the instant office action.
Title of the Invention
The title “PROCESSING” of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed, e.g., “User-specific Data Processing”, “Processing of User-specific Data”, “User Data Processing”, “Data Processing Method, Device and System”, “Method, Device and System to Process User-specific Data”, etc.
Appropriate action is required.
Abstract
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because (1) the abstract should be limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length, and (2) the abstract recites phrases, such as “There can be provided a method that comprise …”, which can be implied and therefore should be avoided. Correction is required. See MPEP § 608.01(b).
Drawings
Drawings, filed on 10/21/2024, are objected to because of the following informalities:
The label for element 22 in Fig. 1a is missing.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claims 5-7, 11 and 22 are objected to because of the following informalities:
Regarding claim 5, the claim in line 1 recites “The method of claim 4, further comprising transmitting...” which should be corrected and read as “The method of claim 4, further comprising: transmitting...”. Appropriate correction is required.
Regarding claim 7, the claim in line 1 recites “The method of claim 6, further comprising providing...” which should be corrected and read as “The method of claim 6, further comprising: providing...”. Appropriate correction is required.
Regarding claims 7 and 22, the claims in lines 1-3 recite “a user” which should be corrected and read as “[[a]] the user”. Appropriate correction is required.
Regarding claim 7, the claim in lines 7 recites limitation “comparing the hash result against a record of known hashed user-IDs;” which lacks antecedent basis, and therefore should be corrected and read as “comparing [[the]] hash result, obtained from the hashing, against a record of known hashed user-IDs;” since claim in the previous step performs “hashing”. Appropriate correction is required.
Regarding claim 11, the claim in line 1 recites “The method of claim 1, further comprising retrieving...” which should be corrected and read as “The method of claim 1, further comprising: retrieving...”. Appropriate correction is required.
Dependent claims that depend-on the above objected claims are likewise objected since they depend on and/or carries the deficiencies of the parent claims. Appropriate correction is required.
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.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
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.
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) or pre-AIA 35 U.S.C. 112, sixth paragraph, 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) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(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) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, 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) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, 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) or pre-AIA 35 U.S.C. 112, sixth paragraph, 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) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “the user device is configured to: collect user-specific data ...; transmit the user specific data...; generate the hashed user ID...; transmit an encrypted copy...; retrieve data...”, in claims 32-33, 35-36 and 42.
Examiner finds that the specification in para. [0026] provides sufficient structure to perform functions by an “user device” element as recited in the claimed limitations “the user device is configured to: collect user-specific data ...; transmit the user specific data...; generate the hashed user ID...; transmit an encrypted copy...; retrieve data...” of claims 32-33, 35-36 and 42. Because these claim limitation(s) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. Therefore, these limitations as recited only invoke 35 U.S.C. 112 (f) or sixth paragraph.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (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) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 7 and 22 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.
Claims 7 and 22 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 pre-AIA the applicant regards as the invention.
Regarding claim 7, the claim recites limitation “decrypting the stored encrypted user-set code...” which is not defined previously and therefore lacks antecedent basis. It is also unclear “how” and “where” the encrypted user-set code is being stored? And/or whether the process requires an additional structure to store the encrypted user-set code? Clarification is required.
For examination purpose, and in view of the specification, Examiner interprets that the encrypted user-set code is being stored in a connectivity platform.
Regarding claim 22, the claim recites similar limitations and therefore are rejected for the same reasons as mentioned above for the method claim 7.
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.
The claimed invention is not directed to patent eligible subject matter. Based upon consideration of all of the relevant factors with respect to the claim as a whole, claims 1, 11, 16 and 26 are determined to be directed to an abstract idea.
Claims 1, 11, 16 and 26 are rejected under 35 USC 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Under the 2019 Revised Patent Subject Matter Eligibility Guidance (“2019 PEG”), effective January 7, 2019, independent claims 1 and 16 are directed to an abstract idea without being significantly more nor being integrated into a practical application. The claims are directed towards data processing.
For instance, the independent claim 1 recites the method steps of “collecting, at a device, user-specific data relating to an aerosol provision device of a user; transmitting the user-specific data to a remote system in association with a hashed user ID for the user of the aerosol provision device, wherein the hashed user ID is not usable to identify the user.”, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind and are broad enough to encompass performance by a human using pen and paper. For example, one ordinary skilled in the art, in the context of the claim, can manually (i.e., by using pen and paper and/or in human mind) collect data from another user/entity, and handover the collected data to a third party/entity that holds the hashed ID of another user/entity. Therefore, the claim limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind and/or includes some additional physical steps such as to encompass performance by a human using pen and paper but for the recitations of generic computer components. That is, other than “a device including a processor and a memory, as disclosed in spec. para. [0026]” nothing in the claim precludes the steps from practically being performed in the mind and/or by utilizing some additional physical steps. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or includes some additional physical steps such as to encompass performance by a human using pen and paper but for the recitation of the generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the claim recites additional element(s), such as devices and remote system. These element(s) in the claim are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element(s) such as “a device” to perform “collecting, at a device, user-specific data relating to an aerosol provision device of a user; transmitting the user-specific data to a remote system in association with a hashed user ID for the user of the aerosol provision device, wherein the hashed user ID is not usable to identify the user.” steps amounts to no more than mere instructions to apply the exception using a generic computer component, see spec [0026], which may include component e.g., a processor, or memory. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Thus, the claim is not patent eligible.
With regards to independent claim 16, the claim is directed towards and recites a user device in the preamble of the claim that is configured to “collect user-specific data relating to an aerosol provision device of a user; transmit the user-specific data to a remote system in association with a hashed user ID for the user of the aerosol provision device, wherein the hashed user ID is not usable to identify the user.”, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind and are broad enough to encompass performance by a human using pen and paper. For example, one ordinary skilled in the art, in the context of the claim, can manually (i.e., by using pen and paper and/or in human mind) collect data from another user/entity, and handover the collected data to a third party/entity that holds the hashed ID of another user/entity. Therefore, the claim limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind and/or includes some additional physical steps such as to encompass performance by a human using pen and paper but for the recitations of generic computer components. That is, other than “a device including a processor and a memory, as disclosed in spec. para. [0026]” nothing in the claim precludes the steps from practically being performed in the mind and/or by utilizing some additional physical steps. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind and/or includes some additional physical steps such as to encompass performance by a human using pen and paper but for the recitation of the generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the claim recites additional element(s), such as devices and remote system. These element(s) in the claim are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element(s) such as “a device” that perform to “collect user-specific data relating to an aerosol provision device of a user; transmit the user-specific data to a remote system in association with a hashed user ID for the user of the aerosol provision device, wherein the hashed user ID is not usable to identify the user.” steps amounts to no more than mere instructions to apply the exception using a generic computer component, see spec [0026], which may include component e.g., a processor, or memory. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Thus, the claim is not patent eligible.
With regards to dependent claims 11 and 26, the claims recite elements which are taken individually do not amount to “significantly more” than just the abstract idea. The claims do not recite a specific technological improvement or a particular machine and no additional element to amount to significantly more. The elements as recited in the claims are generic (such as, sending a query, receiving data, using a hashed ID) and appear well-understood, routine, and conventional. Some of the evidences of “significantly more” are a) improvement to another technology or field; b) applying judicial exception with or by a “particular machine’; c) transforming particular article/data into different state or thing; d) adding unconventional or non-routine steps, producing useful application; and e) other meaningful limitations beyond generic link to particular technological environment.
As a result, the claims 1, 11, 16 and 26 are rejected under 35 U.S.C 101 as being directed to non-statutory subject matter as the claims do not contain any element or combination of elements that is sufficient to ensure that the patent in practice amounts to significantly more than a patent upon the ineligible concept itself. See Alice, 134 S. Ct. at 2360. Under Alice, that is not sufficient "to transform an abstract idea into a patent-eligible invention." See Electric Power group, etc.
Regarding independent claim 16, the claim is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter and does/do not fall within at least one of the four categories of patent eligible subject matter because the claim is directed towards and recites ‘A user device’ in the preamble of the claim without positively reciting a hardware element in the body of the claim. As the body of the claim does not positively recite a hardware element, the claim is directed to non-statutory subject matter. The nominal recitation of the processor with an absence of a hardware element in the body of the claim fails to make the claim statutory under 35 USC 101. See Am. Med. Sys., Inc v. Biolitec, Inc., 618 F.3d 1354, 1358 (Fed. Cir. 2010). See also Ex parte Cohen et al., (Appeal No. 2009-011366) for details.
Examiner respectfully suggests that the claim to be further amended to positively recite at least a hardware element, e.g., hardware processor, computer processor and/or a memory, within the body of the claim to make the claim statutory subject matter under 35 U.S.C. 101.
Dependent claims which depend-on the rejected independent claim 16 are therefore rejected under 35 U.S.C. 101 since they depend-on and carries the deficiencies of the independent claim 16.
Claim Rejections - 35 U.S.C. 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 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 non-obviousness.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 4, 11, 16-17, 19, 26, 30, 32-33, 35 and 42 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson et al. (US 2020/0000143 A1; hereinafter “Anderson”), in view Bettger; David Duane (US 2019/0052467 A1; hereinafter “Bettger”).
Regarding independent claim 1, Anderson teaches A method comprising: collecting, at a device, user-specific data relating to an aerosol provision device of a user (Anderson in para. [0014 and/or 0034] discloses a user device communicatively coupled with the first vaporizer device (hereinafter, an aerosol provision device) and a remote server, as shown in Fig. 3. The process include: receiving a first usage data associated with a first user interacting a first vaporizer device, and as further disclosed in para. [0521] A vaporizer and/or an associated application may gather, receive, log, store, transmit, extrapolate, and/or the like, anonymous or user specific usage data. In some aspects, as disclosed in para. [0492], the user device can be used to capture information about when a user takes an action other than a puff (e.g., detect a user tapping the device twice to record when the user is going to smoke a cigarette, tapping three times when the user has a cig craving, etc.).);
transmitting the user-specific data to a remote system in association with a hashed user ID for the user of the aerosol provision device (Anderson in para. [0025] discloses that the first usage data may be received from a user device coupled with the first vaporizer device. Or see also para. [0034], a user device communicatively coupled with the first vaporizer device and a remote server. The remote server [...] may perform operations that include: receiving, from the user device, a usage data for associated with a first user interacting the first vaporizer device, and as disclosed in para. [0058] the vaporizer device may be linked to the user by at least creating an association between a device identifier of the vaporizer device and a user identifier of the user. Data received from the vaporizer device may be anonymized by at least being associated with the device identifier of the vaporizer device but not the user identifier of the user, and as disclosed in para. [0641], when data is linked to a user account, access/security for the linkage of user and/or usage is extremely secure. For example, hashed user-identifier may be appended to the data.),
Although, the cited reference Anderson discloses that “Data received from the vaporizer device may be anonymized by at least being associated with the device identifier of the vaporizer device but not the user identifier of the user (para. [0058]). Certain identifying characteristics of users may be kept anonymous for safety and/or privacy reasons (para. [0611]). For enhanced user privacy, the data received at the data recorder may be anonymized such that data from a vaporizer device are not associated with the corresponding user's personal identity (para. [0621])”. However, Anderson fails to disclose but Bettger teaches wherein the hashed user ID is not usable to identify the user (Bettger in para. [0100-0101] discloses that the receiver computing device may obtain identity 308 from the sender computing device at a previous time (for example, before the sender is presented with the offer) in a manner such that information that could be used to uniquely identify the sender remains hidden even if data is intercepted by a malicious device. For example, at a previous time (for example, before the sender is presented with the offer), the sender computing device may prompt the sender to provide an input that uniquely represents an identity of the sender (for example, a fingerprint, a vein reading, an iris scan, face recognition, a passcode, a single-use code, a key card, a digital certificate, a digital token, and/or any other item that represents a biological characteristic of the user, something that the user knows, or something that the user has). Once the input is received, the sender computing device may convert the input into a value (for example, an alphanumeric value, a hexadecimal value, etc.) and then generate a hash of the value to form an identity hash code (hereinafter, hashed user ID). The sender computing device may then transmit the identity hash code to the receiver computing device. In an example, the sender computing device may transmit the identity hash code to the receiver computing device instead of, for example, the converted value because it may not be possible to recreate the input(s) to a hash function using a hash code. However, it may be possible to recreate the input(s) using the converted value. Thus, a malicious device that is able to intercept the identity hash code would not be able to recreate the input(s) used to create the identity hash code and that uniquely identify the sender. In other words, data that could be used to steal the sender's identity (such as the sender's fingerprint, vein reading, iris scan, face-recognition, passcode, a single-use code, a key card, digital certificate, digital token, and/or any other item that represents a biological characteristic of the user, something that the user knows, or something that the user has) would be protected even if the identity hash code is intercepted, and as disclosed in para. [0318], the identity hash code generated based on the input(s) that uniquely identify the user (in this example, the identity hash code is not usable to identify the sender, instead the input (such as sender’s fingerprint, IRIS, etc.) is used to uniquely identify the sender)).
Thus, it would have been obvious to one ordinary skilled in the art before the effective filling date of the claimed invention to have modified ‘Anderson’ by incorporating the above features, as taught by Bettger, such modification would provide protection against unauthorized or malicious users/devices which can intercept data that could be used to steal the user’s identity (such as the sender's fingerprint, vein reading, iris scan, face-recognition, and/or any other item that represents a biological characteristic of the user, something that the user knows, or something that the user has), and may further secure the transaction authorization process from unauthorized or malicious users/devices attempting to spoof a user device; Bettger in para. [0101 & 0240].
Regarding claim 2, Anderson as modified by Bettger teaches the method of claim 1, wherein Anderson fails to explicitly disclose but Bettger further teaches the hashed user ID is created from a hash of a customer ID that is usable to identify the user (Bettger in para. [0100-0101] discloses that the receiver computing device may obtain identity 308 from the sender computing device at a previous time (for example, before the sender is presented with the offer) in a manner such that information that could be used to uniquely identify the sender remains hidden even if data is intercepted by a malicious device. For example, at a previous time (for example, before the sender is presented with the offer), the sender computing device may prompt the sender to provide an input that uniquely represents an identity of the sender (for example, a fingerprint, a vein reading, an iris scan, face recognition, a passcode, a single-use code, a key card, a digital certificate, a digital token, and/or any other item that represents a biological characteristic of the user, something that the user knows, or something that the user has). Once the input is received, the sender computing device may convert the input into a value (for example, an alphanumeric value, a hexadecimal value, etc.) and then generate a hash of the value to form an identity hash code (hereinafter, hashed user ID). The sender computing device may then transmit the identity hash code to the receiver computing device, and/or as further disclosed in para. [0318] the identity hash code (e.g., hashed user ID) is generated based on the input(s) that uniquely identify the user).
Thus, it would have been obvious to one ordinary skilled in the art before the effective filling date of the claimed invention to have modified ‘Anderson’ by incorporating the above features, as taught by Bettger, such modification would provide protection against unauthorized or malicious users/devices which can intercept data that could be used to steal the user’s identity (such as the sender's fingerprint, vein reading, iris scan, face-recognition, and/or any other item that represents a biological characteristic of the user, something that the user knows, or something that the user has), and may further secure the transaction authorization process from unauthorized or malicious users/devices attempting to spoof a user device; Bettger in para. [0101 & 0240].
Regarding claim 4, Anderson as modified by Bettger teaches the method of claim 2, wherein Anderson fails to explicitly disclose but Bettger further teaches creating the hashed user ID comprises using a salt comprising the customer ID and a user-set code (Bettger in para. [0136] describes to generate an identity hash code (also referred to as a “hash identity code”). In which, the user device 402 may prompt the user to provide one or more inputs that uniquely represent an identity of the user (for example, a multi-factor authentication factor, such as a fingerprint, a vein reading, an iris scan, face-recognition, a passcode, a single-use code, a key card, a digital certificate, a digital token, and/or any other item that represents a biological characteristic of the user, something that the user knows, or something that the user has). The user device 402 may convert the input(s) into one or more values (for example, an alphanumeric value, a hexadecimal value, a string value, etc.) and then apply a hash function to the value(s) to generate an identity hash code (also referred to as a “hash identity code”). In general, if the user device 402 or the document authentication server 440 is attempting to apply a hash function to multiple inputs, the user device 402 or document authentication server 440 can concatenate the inputs into a single string (e.g., salt) and apply a hash function to the single string, where each input may or may not be separated with a divider. In another example, as disclosed in para. [0151 & 0162], the user device 402 can concatenate the first value (e.g., customer ID) and the second value (e.g., user-set code) in any order to form a string value (e.g., salt) and then apply a hash function to the string value to form the first data. Thus, the first data may be a hash code, also referred to herein as an identity hash code (e.g., hashed user ID). In another example, as disclosed in para. [0201], the user device 402 can retrieve the initialization key from the secure location, concatenate the identifier (e.g., customer ID) and the initialization key (e.g., user-set code) in any order to form a string value (e.g., salt), and then apply a hash function to the string value to generate the master key (e.g., hashed user ID).).
Thus, it would have been obvious to one ordinary skilled in the art before the effective filling date of the claimed invention to have modified ‘Anderson’ by incorporating the above features, as taught by Bettger, such modification would provide protection against unauthorized or malicious users/devices which can intercept data that could be used to steal the user’s identity (such as the sender's fingerprint, vein reading, iris scan, face-recognition, and/or any other item that represents a biological characteristic of the user, something that the user knows, or something that the user has), and may further secure the transaction authorization process from unauthorized or malicious users/devices attempting to spoof a user device; Bettger in para. [0101 & 0240].
Regarding claim 11, Anderson as modified by Bettger teaches the method of claim 1, wherein Anderson fails to explicitly disclose but Bettger further teaches further comprising retrieving data from the remote system by: transmitting a query comprising the hashed customer ID; and receiving the transmitted user-specific data (Bettger in para. [0112] discloses a network-based data storage provider that may authorize the transfer and/or retrieval of data based on the identity hash code, and as disclosed in para. [0318] the identity hash code (e.g., hashed user ID) is generated based on the input(s) that uniquely identify the user. In an example, as disclosed in para. [0313], the document authentication server 440 may be requested by a user device 402 at a later time to provide the acceptance hash code (or decline hash code) provided by the user device 402 or another user device 402 at a previous time. The document authentication server 440 can then retrieve the acceptance hash code from the hash data store 448 and provide the retrieved acceptance hash code to the user device 402 to satisfy the request).
Thus, it would have been obvious to one ordinary skilled in the art before the effective filling date of the claimed invention to have modified ‘Anderson’ by incorporating the above features, as taught by Bettger, such modification would provide protection against unauthorized or malicious users/devices which can intercept data that could be used to steal the user’s identity, and may further secure the transaction authorization process from unauthorized or malicious users/devices attempting to spoof a user device; Bettger in para. [0101 & 0240].
Regarding claims 16-17, 19 and 26, the claims are drawn to a device and recite substantially similar subject matter as of method claims 1-2, 4 and 11, respectively. Therefore, claims 16-17, 19 and 26 are rejected for the same reasons of anticipation (obviousness) as used above for the method claims 1-2, 4 and 11, respectively.
Regarding claim 30, Anderson as modified by Bettger teaches the user device of claim 16, wherein Anderson further teaches the user device and the aerosol provision device are integrated into a single device (Anderson in para. [0098] discloses that the computer implemented methods consistent with one or more implementations of the current subject matter can be implemented by one or more data processors residing in a single computing system (in other words, the user device and vaporizer device both can be integrated into a single device) or multiple computing systems.).
Regarding claims 32-33 and 35, the claims are drawn to a system and recite substantially similar subject matter as of method claims 1-2 and 4, respectively. Therefore, claims 32-33 and 35 are rejected for the same reasons of anticipation (obviousness) as used above for the method claims 1-2 and 4, respectively.
Regarding claim 42, Anderson as modified by Bettger teaches the data management system of claim 32, wherein Anderson fails to disclose but Bettger further teaches the user device is further configured to retrieve data from the remote system by: transmitting a query comprising the hashed user ID (Bettger in para. [0112] discloses entities, for example, a network-based data storage provider that may authorize the transfer and/or retrieval of data based on the identity hash code. In an example, as disclosed in para. [0313], the document authentication server 440 may be requested by a user device 402 at a later time to provide the acceptance hash code (or decline hash code) provided by the user device 402 or another user device 402 at a previous time. The document authentication server 440 can then retrieve the acceptance hash code from the hash data store 448 and provide the retrieved acceptance hash code to the user device 402 to satisfy the request); and the connectivity platform is configured to test the hashed user ID against records of hashed user IDs already used to store data, and to provide to the user device stored data corresponding to the hashed user ID (Bettger in para. [0112], discloses entities, for example, a network-based data storage provider that may authorize the transfer and/or retrieval of data based on the identity hash code (hereinafter, hashed user ID). For example, as disclosed in para. [0143], the user identity data store 446 stores identity hash codes (e.g., hashed user IDs) and stores each identity hash code in an entry associated with the user and/or user device 402 (for example, an identifier that identifies the user device 402) that provided the respective identity hash code. The user identity data store 446 may be located internal to the document authentication server 440. In other embodiments, not shown, the user identity data store 446 is located external to the document authentication server 440, such as on a separate system or server. In an example, as disclosed in para. [0310], the hash comparator 445 approves or denies access (or transactions) by comparing and matching the identity hash code generated by the user device 402 with the identity hash code stored in the user identity data store 446 that was previously provided by the user device 402. In another example, as disclosed in para. [0171], the user device 402 may generate the first data and transmit the first data to the document authentication server 440. The document authentication server 440 may then store the first data in the user identity data store 446 and retrieve the first data when needed).
Thus, it would have been obvious to one ordinary skilled in the art before the effective filling date of the claimed invention to have modified ‘Anderson’ by incorporating the above features, as taught by Bettger, such modification would provide protection against unauthorized or malicious users/devices which can intercept data that could be used to steal the user’s identity, and may further secure the transaction authorization process from unauthorized or malicious users/devices attempting to spoof a user device; Bettger in para. [0101 & 0240].
Claims 5-6, 20 and 36 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson et al. (US 2020/0000143 A1; hereinafter “Anderson”), in view Bettger; David Duane (US 2019/0052467 A1; hereinafter “Bettger”) and further in view of OAK KYOUNG HWAN (KR 20140099375 A; hereinafter “Oak”).
Regarding claim 5, Anderson as modified by Bettger teaches the method of claim 4, wherein Anderson as modified by Bettger fails to explicitly disclose but Oak teaches further comprising transmitting an encrypted copy of the user-set code to a connectivity platform (Oak in pdf page 2-3 (Fig. 1 and associated paragraphs), discloses a remote management server 100 that plays a role of relaying the security management unit 200 (of a mobile terminal) with the user. The user accesses the remote management server 100 using a PC, a notebook computer, or another smart device, and transmits a remote access request, security information (e.g., user-set code), and control data to the remote management server 100. When the remote management server 100 receives the remote access request from the user, the remote management server 100 performs an authentication process for the connected user based on the received remote access request. When the user authentication is passed, the received security information (e.g., user-set code) is encrypted by a predetermined encryption method. Then, the remote management server 100 delivers the encrypted security information (e.g., encrypted user-set code) and control data to the security management unit 200. In an embodiment of the present invention on pdf page 6-7, Referring to FIG. 5, the SMS including the encrypted security code (e.g., user-set code) and control data is divided into SMS (general SMS) and SMS (SMS) for remote security management. 501 is a header for identifying SMS. 502 is an encrypted security code composed of 40 bytes (Byte), and is encoded by SHA1, a unidirectional encryption method. FIG. 6 is a diagram illustrating an embodiment of an SMS received from the remote management server 100. The SMS including an encrypted security code (e.g., user-set code) and control data in an embodiment of the present invention.).
Thus, it would have been obvious to one ordinary skilled in the art before the effective filling date of the claimed invention to have modified the combination of ‘Anderson-Bettger’ by incorporating the above features, as taught by Oak, such modification would improve security of a remote control process and security processing according to received SMS is performed when the SMS including the encrypted security code and the control data is received according to the setting of the user; Oak in Abstract & pdf page 7.
Regarding claim 6, Anderson as modified by Bettger in view of Oak teaches the method of claim 5, wherein encryption of the user-set code is based upon a user-set security term (Oak in pdf page 7 (3rd paragraph), discloses that the SMS including the encrypted security code (e.g., user-set code) and the control data is received according to the setting of the user (e.g., user-set security term). Or see also pdf 2 and Fig. 1 with associated paragraphs, discloses that the remote management server 100 includes a user authentication unit 110, a user information storage unit 130, and an encryption processing unit 150. The encryption processing unit 150 encrypts the security code received from the user authentication unit 110 based on the terminal information received from the user information storage unit 130. The terminal information of the user includes the encryption method information to encrypt the security code according to the settings of the user. Generating the encrypted control data is not an essential element, and it is possible to omit the encryption process according to the selection of the user or the setting of the system).
Thus, it would have been obvious to one ordinary skilled in the art before the effective filling date of the claimed invention to have modified the combination of ‘Anderson-Bettger’ by incorporating the above features, as taught by Oak, such modification would improve security of a remote control process and security processing according to received SMS is performed when the SMS including the encrypted security code and the control data is received according to the setting of the user; Oak in Abstract & pdf page 7.
Regarding claim 20, the claim is drawn to a user device and recite substantially similar subject matter as of method claim 5. Therefore, claim 20 is rejected for the same reasons of anticipation (obviousness) as used above for the method claim 5.
Regarding claim 36, Anderson as modified by Bettger teaches the data management system of claim 35, wherein Anderson as modified by Bettger fails to disclose but Oak teaches further configured to transmit an encrypted copy of the user-set code to the connectivity platform (Oak in pdf page 2-3 (Fig. 1 and associated paragraphs), discloses a remote management server 100 that plays a role of relaying the security management unit 200 (of a mobile terminal) with the user. The user accesses the remote management server 100 using a PC, a notebook computer, or another smart device, and transmits a remote access request, security information (e.g., user-set code), and control data to the remote management server 100. When the remote management server 100 receives the remote access request from the user, the remote management server 100 performs an authentication process for the connected user based on the received remote access request. When the user authentication is passed, the received security information (e.g., user-set code) is encrypted by a predetermined encryption method. Then, the remote management server 100 delivers the encrypted security information (e.g., encrypted user-set code) and control data to the security management unit 200. In an embodiment of the present invention on pdf page 6-7, Referring to FIG. 5, the SMS including the encrypted security code (e.g., user-set code) and control data is divided into SMS (general SMS) and SMS (SMS) for remote security management. 501 is a header for identifying SMS. 502 is an encrypted security code composed of 40 bytes (Byte), and is encoded by SHA1, a unidirectional encryption method. FIG. 6 is a diagram illustrating an embodiment of an SMS received from the remote management server 100. The SMS including an encrypted security code (e.g., user-set code) and control data in an embodiment of the present invention.), and the connectivity platform is further configured to store the encrypted copy of the user-set code (Oak in pdf page 3 (7th-10th paragraph) discloses that the security management unit 200 includes [...] a storage unit 230 that stores the encrypted security code).
Thus, it would have been obvious to one ordinary skilled in the art before the effective filling date of the claimed invention to have modified the combination of ‘Anderson-Bettger’ by incorporating the above features, as taught by Oak, such modification would improve security of a remote control process and security processing according to received SMS is performed when the SMS including the encrypted security code and the control data is received according to the setting of the user; Oak in Abstract & pdf page 7.
Claim 7 and 22 is rejected under 35 U.S.C. 103 as being unpatentable over Anderson et al. (US 2020/0000143 A1; hereinafter “Anderson”), in view Bettger; David Duane (US 2019/0052467 A1; hereinafter “Bettger”) and further in view of OAK KYOUNG HWAN (KR 20140099375 A; hereinafter “Oak”) and Campagna; Matthew John (US 20170310652 A1; hereinafter “Campagna”).
Regarding claim 7, Anderson as modified by Bettger in view of Oak teaches the method of claim 6, wherein Anderson further teaches inviting a user to enter the user-set security term (Anderson in Para. [0288] discloses that the user device may display a user interface 1032, which may be configured to receive an input setting from the user);
However, Anderson fails to disclose but Bettger further teaches further comprising providing a mechanism for a user to reset the user-set code comprising (Bettger in para. [0281] discloses to instruct the user device 402 to reset the current symmetric key (e.g., the user-set code) by replacing the current symmetric key with a new symmetric key): inviting a user to enter the user-set security term (Bettger in para. [0074] discloses that a user (for example, an offeree) may be prompted (e.g., invited) by a computing device to select whether the user accepts the terms and conditions of the offer 102 and/or the consideration 104. The user may elect to accept the terms and conditions of the offer 102 and/or the consideration 104 (for example, via the selection of a button or a box, via a text input indicating the acceptance, etc.));
transmitting the customer ID to the connectivity platform (Bettger in para. [0209] discloses that an identifier associated with the user may be transmitted by the user device 402);
decrypting the stored encrypted user-set code (Bettger in para. [0144] discloses that the key data store 447 stores [...] symmetric keys and stores each key in an entry associated with a user and/or user device 402 (for example, an identifier that identifies the user device 402). Additional security measures may be applied to the key data store 447 such that components or devices external to the document authentication server 440 may not have access to the key data store 447. For example, the key data store 447 may be encrypted with a key accessible to certain components within the document authentication server 440 and therefore may be decrypted each time the key data store 447 is accessed);
hashing the customer ID using the customer ID and the decrypted user-set code as salt (Bettger in para. [0136] describes to generate an identity hash code (also referred to as a “hash identity code”). In which, the user device 402 may prompt the user to provide one or more inputs that uniquely represent an identity of the user (for example, a multi-factor authentication factor, such as a fingerprint, a vein reading, an iris scan, face-recognition, a passcode, a single-use code, a key card, a digital certificate, a digital token, and/or any other item that represents a biological characteristic of the user, something that the user knows, or something that the user has e.g., a symmetric key). The user device 402 may convert the input(s) into one or more values (for example, an alphanumeric value, a hexadecimal value, a string value, etc.) and then apply a hash function to the value(s) to generate an identity hash code (also referred to as a “hash identity code”). In general, if the user device 402 or the document authentication server 440 is attempting to apply a hash function to multiple inputs, the user device 402 or document authentication server 440 can concatenate the inputs into a single string (e.g., salt) and apply a hash function to the single string, where each input may or may not be separated with a divider. In another example, as disclosed in para. [0151 & 0162], the user device 402 can concatenate the first value (e.g., customer ID) and the second value (e.g., decrypted user-set code) in any order to form a string value (e.g., salt) and then apply a hash function to the string value to form the first data. Thus, the first data may be a hash code, also referred to herein as an identity hash code (e.g., hashed user ID). In another example, as disclosed in para. [0201], the user device 402 can retrieve a key from the secure location, concatenate the identifier (e.g., customer ID) and the key (e.g., user-set code) in any order to form a string value (e.g., salt), and then apply a hash function to the string value to generate the master key (e.g., hashed user ID));
comparing the hash result against a record of known hashed user-IDs (Bettger in para. [0143], discloses that the user identity data store 446 stores identity hash codes (e.g., hashed user IDs) and stores each identity hash code in an entry associated with the user and/or user device 402 (for example, an identifier that identifies the user device 402) that provided the respective identity hash code. The user identity data store 446 may be located internal to the document authentication server 440. In other embodiments, not shown, the user identity data store 446 is located external to the document authentication server 440, such as on a separate system or server. In an example, as disclosed in para. [0310], the hash comparator 445 approves or denies access (or transactions) by comparing and matching the identity hash code generated by the user device 402 with the identity hash code(s) stored in the user identity data store 446 that was previously provided by the user device 402.); and
transmitting to the device a message indicating that a new user-set code can now be created (Bettger in para. [0281] discloses a transaction request that instructs the user device 402 to reset the current symmetric key (e.g., the user-set code) by replacing the current symmetric key with a new symmetric key (e.g., a new user-set code)).
Thus, it would have been obvious to one ordinary skilled in the art before the effective filling date of the claimed invention to have modified ‘Anderson’ by incorporating the above features, as taught by Bettger, such modification would provide protection against unauthorized or malicious users/devices which can intercept data that could be used to steal the user’s identity, and may further secure the transaction authorization process from unauthorized or malicious users/devices attempting to spoof a user device; Bettger in para. [0101 & 0240].
Although, as described above, the combination of Anderson as modified by Bettger teaches “transmitting the customer ID to the connectivity platform; and decrypting the stored encrypted user-set code;”. The combination, however, fails to disclose but Oak further teaches transmitting the user-set security term to the connectivity platform (Oak in pdf page 3 (9th paragraph), discloses that the security management unit (of the mobile terminal) 200 receives the setting of the security code from the user (e.g., the user-set security term));
Thus, it would have been obvious to one ordinary skilled in the art before the effective filling date of the claimed invention to have modified the combination of ‘Anderson-Bettger’ by incorporating the above features, as taught by Oak, such modification would improve security of a remote control process and security processing according to received SMS is performed when the SMS including the encrypted security code and the control data is received according to the setting of the user; Oak in Abstract & pdf page 7.
Although, as described above, Bettger teaches “decrypting the stored encrypted user-set code”. The combination of Anderson as modified by Bettger in view of Oak, however, fails to disclose but Campagna teaches decrypting the encrypted user-set code using user-set security term (Campagna in para. [0079] discloses that the caller-client may use the cryptography service to decrypt the encrypted data key, and the caller-client may also allow other parties to decrypt the encrypted data key, for example, using a security policy (e.g., security term) over the client master key associated with the caller-client, and as disclosed in para. [0081], the data key may be a symmetric key or an asymmetric key. In some embodiments, as disclosed in para. [0034], the client may transmit a request specifying the key identifier to the cryptography service to decrypt the encrypted data key. The cryptography service may select the managed key, decrypt the encrypted data key, and provide the decrypted data key in response to the request. Encryption for the data key may be in accordance with an encryption configuration, such as described above and, generally, in accordance with a policy associated with the managed key. In another embodiment, as disclosed in para. [0072 and 0081], the encrypted data key may include additional information (possibly in plaintext) that indicates how the encrypted data key may be decrypted (e.g., a metadata field may include a key ID usable to decrypt the encrypted data key). The data key may be a symmetric key or an asymmetric key.);
Thus, it would have been obvious to one ordinary skilled in the art before the effective filling date of the claimed invention to have modified the combination of ‘Anderson-Bettger-Oak’ by incorporating the above features, as taught by Campagna, such modification would enable the client to use the decrypted data key to securely decrypt the encrypted data; Campagna in para. [0034].
Regarding claim 22, the claim is drawn to a user device and recite substantially similar subject matter as of method claim 7. Therefore, claim 22 is rejected for the same reasons of anticipation (obviousness) as used above for the method claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See form PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALI CHEEMA, whose contact number is 571-272-1239 and email: ali.cheema@uspto.gov. The examiner can normally be reached on Monday-Friday: 8:00AM – 4:00PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Eleni A. Shiferaw can be reached on 571-272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
/ALI H. CHEEMA/
Primary Examiner, Art Unit 2497