DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s remarks filed on 09/05/2025 has been fully considered.
Regarding claim[s] 1 – 16 under the various obviousness rejections, applicant’s remarks are not persuasive, therefore, see the examiner’s response to such remarks in the office action below.
The examiner will respond to all other remarks that do not concern the prior art rejections, if any, in the office action below.
Applicant states on page[s] 6 - 7 of the remarks as filed: “
Claim 1, 2, 7-9, 10, 15, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al. (U.S. Patent No. 11,348,152) in view of Hoerstein et al. (U.S. Patent Publication No. 2019/0305943). Claims 3 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Davis in view of Hoerstein, and further in view of Ferenczi et al. (U.S. Patent Publication No. 2023/0034169). Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Davis in view of Hoerstein, and further in view of Hamel et al. (U.S. Patent Publication No. 2018/0062835). Claims 5, 6, 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Davis in view of Hoerstein and Hamel, and further in view of Meyers et al. (U.S. Patent Publication No. 2023/0010172). Applicant requests reconsideration.
A. Independent Claim 1
Claim 1 is patentable over the cited references for at least the reason that the cited references do not teach or suggest:
A computer-implemented method for granting access, the method comprising: receiving, from a computing device, an identifier identifying a physical object, wherein the identifier is obtained by the computing device scanning a physical object and the physical object is linked to a digital asset;
receiving an encrypted message, wherein the encrypted message comprises an encrypted token;
determining the encrypted token satisfies a condition; and
as a result of determining the condition is satisfied, transmitting an unencrypted public key of a wallet and the identifier to an application to use for granting access, wherein access is granted depending on whether the wallet owns the digital asset linked to the physical object.
First, the Office contends that Davis discloses “receiving an encrypted message, wherein the encrypted message comprises an encrypted token; [and] determining the encrypted token satisfies a condition,” citing to FIG. 6 and col. 10, lines 4-12. (See Office Action at pages 9-10). Applicant respectfully disagrees.
Davis discloses “‘an example of using the embedded tag to provide different forms of good authentication in accordance.” (Davis at col. 9, lines 53-55; FIG. 6). A form of authentication “may be provided by encoding embedded tag 602 with a URL and an encrypted message generator that generates a unique message or value each time tag 602 is read.” (Davis at col. 10, lines 4-12). Davis discloses that a “website may verify the unique message, and may verify the authenticity of good 604 based on a successful verification of the unique message or unsuccessful verification of the unique message.” (Davis at col. 10, lines 4-12).
But a disclosure of verifying a unique message is not the same as, equivalent to, or suggestive of “receiving an encrypted message, wherein the encrypted message comprises an encrypted token; [and] determining the encrypted token satisfies a condition,” as required by claim 1.
The cited references, even when considered in combination, fail to teach or suggest “receiving an encrypted message, wherein the encrypted message comprises an encrypted token; [and] determining the encrypted token satisfies a condition,” as required by claim 1.”
In response the examiner isn’t persuaded, the examiner points to the prior art of Davis.
Specifically of Davis, at Davis, Figure # 6, components # 602, 603 and col. 10, lines 4 – 7, A second form of good authentication 603 may be provided by encoding embedded tag 602 with a URL and an encrypted message generator that generates a unique message or value each time tag 602 is read.].
This meets applicant’s argued claim limitation of: “receiving an encrypted message, wherein the encrypted message comprises an encrypted token.”
Then further of Davis, at Figure # 6, components # 604 and col. 10, lines 7 – 12, The unique message may be passed along with a request to access the URL. The website may verify the unique message, and may verify the authenticity of good 604 based on a successful verification of the unique message or unsuccessful verification of the unique message.
This meets applicant’s argued claim limitation of: “determining the encrypted token satisfies a condition.”
***The examiner further notes that applicant’s recited claim limitation of “…the encrypted token satisfies a condition..,” could be any type of decision making process or security/authentication/authorization operations currently used in modern day data processing systems. Therefore, the disclosed teachings of Davis as identified above and in the most recent office action, makes obvious applicant’s argued claim limitation.
***The examiner’s response applies to the same or similar remarks regarding claims 9 and 16 made on page[s] 8 of the remarks as filed.
Applicant states on page[s] 7 - 8 of the remarks as filed: “Second, the Office contends that Hoerstein discloses, “as a result of determining the condition is satisfied, transmitting an unencrypted public key of a wallet and the identifier to an application to use for granting access,” citing to paragraphs 34 and 35. (See Office Action at pages 10-11). Applicant respectfully disagrees.
Hoerstein discloses a method for transferring digital assets. (See Hoerstein at para. [0034]). The method includes generating a root seed, generating a master extended private key and extended public key as a pair, and determining whether to receive digital assets. (See Hoerstein at para. [0034]). Hoerstein discloses that the method further includes making accessible either the master extended public key or the child extended public key to the sender and a sender receiving the extended public key and selects or chooses transaction details. (See Hoerstein at para. [0035]).
But a disclosure of making accessible a public key is not the same as, equivalent to, or suggestive of, “as a result of determining the condition is satisfied, transmitting an unencrypted public key of a wallet and the identifier to an application to use for granting access,” as required by claim 1. The cited references, even when viewed in combination, fail to teach or suggest, “as a result of determining the condition is satisfied, transmitting an unencrypted public key of a wallet and the identifier to an application to use for granting access,” as required by claim.
Accordingly, Applicant submits that claim 1 is patentable over the cited references for at least these reasons.”
In response the examiner isn’t persuaded, the examiner points to the prior art of Hoerstein.
Specifically of Hoerstein, at Figure # 5a, and paragraph: 0034, Referring now to FIG. 5a, a flowchart illustrates an embodiment of a computer implemented method that may be implemented by a computer system of a sender and receiver of digital assets to transfer the digital assets. For example, the steps illustrated in the flow chart may be general steps taken by a sender or receiver of digital assets using a computer application (e.g., a type of deterministic wallet application programmed to implement embodiments of the disclosed system) or other application or program run on sender or receiver computer devices to transfer digital assets in accordance with the disclosed systems. In step 501, a receiver using a computer device generates random entropy or a random number as a root seed, and then in step 502 generates or calculates a master extended private key and extended public key as a pair. At step 502, the receiver's device may store the master extended public key and master private key as a pair in memory and store the root seed in memory. In step 503, the receiver determines whether to receive digital assets at a child extended public key. If yes, 503a, the receiver's device generates a child extended public key from the master extended public key. The child extended public key is capable of being used to generate a plurality of keys and is the key made accessible to the sender. If no, 503b, the receiver uses the master extended public key, which is capable of being used to generate a plurality of keys, and the master extended public key may be made accessible to the sender [i.e. applicant’s “as a result of determining the condition is satisfied, transmitting an unencrypted public key of a wallet……].
Then further of Hoerstein, at paragraph: 0035, In step 505, the receiver transmits or otherwise makes accessible either the master extended public key or the child extended public key (both of which are capable of being used to generate a plurality of keys) to the sender, depending on the decision at step 503. This step 505 may include implementation of a serialization procedure to extract and obtain a copy of the extended public key (e.g., Bitcoin Improvement Proposal 32 provides a serialization procedure for extended public keys used in Bitcoin transactions) and may include a computer implemented process for the transmission of the key to the sender. For example, a receiver's device running an HD wallet application or other application on a computer device may link to a text or email application to securely transmit the extended public key to the sender……In step 506, the sender receives the extended public key and selects or chooses transaction details, such as the settlement date and product identification, as parameters for the purpose of creating an index scheme [i.e. applicant’s……“as a result of determining the condition is satisfied, transmitting an unencrypted public key of a wallet and the identifier to an application to use for granting access,”]. At this step, 506, the sender may use a device running an application (e.g., a type of deterministic wallet application programmed to implement the disclosed system) or other application or program to receive and store the extended public key.
***The examiner further notes that applicant’s recited claim limitation of “…as a result of determining the condition is satisfied..,” could be any type of decision making process or security/authentication/authorization operations currently used in modern day data processing systems. Therefore, the disclosed teaching of Hoerstein, at figure # 5a, steps 503, 503b, where at determination and result of whether the child extended public key or the master public is used and sent to the sender, makes obvious applicant’s argued claim limitation.
***The examiner’s response applies to the same or similar remarks regarding claims 9 and 16 made on page[s] 8 of the remarks as filed.
Response to Amendment
Status of the instant application:
Claim[s] 1 – 17 are pending in the instant application.
Claim[s] 17 is a newly added claim and is addressed in the office action below.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/26/2025 and 07/25/2025, the submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claim(s) 1, 2, 7 - 9, 10, 15 - 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al. [US PAT # 11348152] in view of Hoerstein et al. [US PGPUB # 2019/0305943]
As per claim 1. Davis does teach a computer-implemented method for granting access [Davis, col. 1, lines 52 – 55, Provided are systems and methods for creating apparel, wearable accessories, and/or other physical goods that provide embedded verification of a non-fungible token (“NFT”)], the method comprising:
receiving, from a computing device, an identifier identifying a physical object, wherein the identifier is obtained by the computing device scanning a physical object and the physical object is linked to a digital asset [Davis, Figure # 2, and col. 2, lines 19 – 33, As shown in FIG. 2, a reader, scanner, and/or other device 202 that may read and/or scan tag 104 may be positioned near tag 104. For instance, tag 104 may be embedded under the presentation of artifact 102 on clothing item 100, and device 202 may be positioned next to the presentation of artifact 102 in order to read the value encoded within tag 104. Device 202 may generate (at 201) a magnetic field that supplies power to tag 104. Upon receiving power, tag 104 may wirelessly transmit (at 203) the stored value to device 202. The stored value may correspond to a URL, network address, and/or identifier for accessing website 204 that is populated with information made public by the owner of clothing item 100 and the latest NFT ownership information];
receiving an encrypted message, wherein the encrypted message comprises an encrypted token [Davis, Figure # 6, components # 602, 603 and col. 10, lines 4 – 7, A second form of good authentication 603 may be provided by encoding embedded tag 602 with a URL and an encrypted message generator that generates a unique message or value each time tag 602 is read.];
determining the encrypted token satisfies a condition [Davis, Figure # 6, components # 604 and col. 10, lines 7 – 12, The unique message may be passed along with a request to access the URL. The website may verify the unique message, and may verify the authenticity of good 604 based on a successful verification of the unique message or unsuccessful verification of the unique message.];
While Davis does not clearly teach and
as a result of determining the condition is satisfied, transmitting an unencrypted public key of a wallet and the identifier to an application to use for granting access, wherein access is granted depending on whether the wallet owns the digital asset linked to the physical object.
However, Hoerstein does teach and
as a result of determining the condition is satisfied, transmitting an unencrypted public key of a wallet and the identifier to an application to use for granting access [Figure # 5a, and paragraph: 0034, Referring now to FIG. 5a, a flowchart illustrates an embodiment of a computer implemented method that may be implemented by a computer system of a sender and receiver of digital assets to transfer the digital assets. For example, the steps illustrated in the flow chart may be general steps taken by a sender or receiver of digital assets using a computer application (e.g., a type of deterministic wallet application programmed to implement embodiments of the disclosed system) or other application or program run on sender or receiver computer devices to transfer digital assets in accordance with the disclosed systems. In step 501, a receiver using a computer device generates random entropy or a random number as a root seed, and then in step 502 generates or calculates a master extended private key and extended public key as a pair. At step 502, the receiver's device may store the master extended public key and master private key as a pair in memory and store the root seed in memory. In step 503, the receiver determines whether to receive digital assets at a child extended public key. If yes, 503a, the receiver's device generates a child extended public key from the master extended public key. The child extended public key is capable of being used to generate a plurality of keys and is the key made accessible to the sender. If no, 503b, the receiver uses the master extended public key, which is capable of being used to generate a plurality of keys, and the master extended public key may be made accessible to the sender.
Then further of paragraph: 0035, In step 505, the receiver transmits or otherwise makes accessible either the master extended public key or the child extended public key (both of which are capable of being used to generate a plurality of keys) to the sender, depending on the decision at step 503. This step 505 may include implementation of a serialization procedure to extract and obtain a copy of the extended public key (e.g., Bitcoin Improvement Proposal 32 provides a serialization procedure for extended public keys used in Bitcoin transactions) and may include a computer implemented process for the transmission of the key to the sender. For example, a receiver's device running an HD wallet application or other application on a computer device may link to a text or email application to securely transmit the extended public key to the sender……In step 506, the sender receives the extended public key and selects or chooses transaction details, such as the settlement date and product identification, as parameters for the purpose of creating an index scheme. At this step, 506, the sender may use a device running an application (e.g., a type of deterministic wallet application programmed to implement the disclosed system) or other application or program to receive and store the extended public key.], wherein access is granted depending on whether the wallet owns the digital asset linked to the physical object [Figure # 4, and paragraph: 0031, lines 16 – 26, The key derivation index and the extended private key are inputs by the receiver to a function that generate the private key 432. The private key generated corresponds to the public key generated by the sender 420. The private key may be used by the receiver 410 to subsequently send or confirm receipt of the digital assets sent by the sender 433. The sender 420 and receiver 410 may seamlessly perform repeated transactions using the index scheme 412 and child extended public key (450), wherein each transaction corresponds to a different public key, different address, and different key derivation path index.].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Davis and Hoerstein in order for the authenticating the requesting user who scans the NFC tag for owner information of physical asset thru the NFT cached on the blockchain of Davis to include exchanging owner information securely with a key derivation index of Hoerstein. This would allow for the user and owner to exchange data between parties in a secure and efficient manner thru key derivation and key exchange. See paragraph: 0006 of Hoerstein.
As per clam 2. Davis does teach the computer-implemented method according to claim 1, wherein the physical object includes a near-field communication (NFC) chip and the identifier is obtained by the computing device scanning the NFC chip of the physical object [Davis, Figure # 4, component # 402, 405, and col. 7, lines 25 – 31, An NFC reader may be placed over the embedded tag that is adjacent or underneath NFT artifact 402, and may activate (at 405) the embedded tag to obtain the unique URL encoded in the tag.].
As per computer program product comprising a non – transitory computer readable medium claim 8, that includes the same or similar claim limitations as method claim 1 and is similarly rejected.
***The examiner notes that applicant’s recited: “computer program product,” “non-transitory computer readable medium,” and “instructions,” is taught by the prior art of Davis at col. 11, lines 22 - 36, respectively.
As per claim 7. Davis does teach the computer-implemented method according to claim 1, wherein access is granted depending on ownership of the physical object [Davis, Figure # 3, and col. 6, lines 52 – 67 and col. 7, lines 1 – 12, The link (at 316) created between the particular NFT and the selected good may bestow benefits beyond independent ownership of the selected good and the particular NFT, and/or may provide a combined value that is greater than the separate value of each of the selected good and the particular NFT. In some embodiments, possession of the selected good and ownership of the particular NFT that is associated with the selected good may be used to verify and/or authenticate a user for events, locations, and/or other secured physical or digital experiences. For instance, a ticket to an event may be based on the combination of a user wearing apparel that presents a particular NFT artifact and the apparel being embedded with a tag that evidences the user's ownership of the NFT for the particular NFT artifact. Possession of the apparel without being the verified owner of the associated NFT, or demonstrating ownership of the NFT without possession of the apparel presenting the artifact associated with that NFT may be insufficient to satisfy a two-prong verification and/or authentication that is required for access.].
As per computing device claim 9, that includes the same or similar claim limitations as method claim 1, and is similarly rejected.
***The examiner notes that applicant’s recited: “processing circuitry,” and “memory containing instructions,” is taught by the prior art of Davis at col. 11, lines 32 – 36, respectively.
As per computing device claim 15, that includes the same or similar claim limitations as method claim 7, and is similarly rejected.
As per apparatus claim 16, that includes the same or similar claim limitations as method claim 1, and is similarly rejected.
***The examiner notes that applicant’s recited: “processing circuitry,” and “memory,” is taught by the prior art of Davis at col. 11, lines 22 - 36, respectively.
As per claim 17. Davis does teach the computer-implemented method according to claim 1, wherein access is granted to an in-person physical experience [Davis, col. 2, lines 8 – 13, For instance, the systems and methods may grant and/or provide an individual access to events, locations, and/or other secured physical or digital experiences upon verifying that the individual possesses a good with an embedded tag that is linked to a particular NFT, and the particular NFT identifying that individual as the NFT owner.].
Claim(s) 3, 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al. [US PAT # 11348152] in view of Hoerstein et al. [US PGPUB # 2019/0305943] as applied to claim[s] 1 above, and further in view of Ferenczi et al. [US PGPUB # 20230034169].
As per claim 3. Davis and Hoerstein do teach what is taught in the rejection of claim 1 above.
Davis and Hoerstein do not clearly teach the computer-implemented method according to claim 1, wherein determining the encrypted token satisfies the condition comprises:
determining that the encrypted token is able to be decrypted; or
determining a time identifier associated with the encrypted token has not expired.
However, Ferenczi does teach the computer-implemented method according to claim 1, wherein determining the encrypted token satisfies the condition comprises:
determining that the encrypted token is able to be decrypted [Figure # 1, and paragraph: 0037, For example, the cryptographic challenge is signed by the client application 136 by encrypting the cryptographic challenge using the private key 150. The authentication service 147 determines that the public key 133 included in the token data 130 corresponds to the private key 150 when the cryptographic challenge that is encrypted using the private key 150 is decrypted with the public key 133. In addition, the authentication service 147 verifies that the cryptographic challenge matches the original cryptographic challenge provided to the client application 136. Upon verifying the identity of the user and confirming that the signed challenge is the same challenge that was originally provided, the authentication service 147 authenticates the user and permits the requested access.]; or
determining a time identifier associated with the encrypted token has not expired.
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Davis as modified and Ferenczi in order for the authenticating the requesting user who scans the NFC tag for owner information of physical asset thru the NFT stored on the blockchain of Davis as modified to include a smart contact of Ferenczi. This would allow for the requesting user to analyze irrefutable proof that the owner of the physical asset is the actually owner indicated by the NFT of the ledger when requesting use or purchase of the asset. See paragraph: 0010 of Ferenczi.
As per computing device claim 11, that includes the same or similar claim limitations as method claim 3, and is similarly rejected.
Claim(s) 4, 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al. [US PAT # 11348152] in view of Hoerstein et al. [US PGPUB # 2019/0305943] as applied to claim[s] 1 above, and further in view of Hamel et al. [US PGPUB # 2018/0062835]
As per claim 4. Davis and Hoerstein do teach what is taught in the rejection of claim 1 above.
Davis and Hoerstein do not clearly teach the computer-implemented method according to claim 1, further comprising:
receiving a key message, wherein the key message includes the public key;
encrypting the public key into the encrypted token, wherein the encrypted token comprises a time identifier and an unique identifier key; and
storing an initialization vector of the encrypted token into a memory cache.
However, Hamel does teach the computer-implemented method according to claim 1, further comprising:
receiving a key message, wherein the key message includes the public key [paragraph: 0051, In some embodiments, the request object comprises a certificate with a public key that is used for later processing. Where at paragraph: 0064, In 414, KMS API Gateway retrieves an encrypted tenant service key (Encrypted TSK). In some embodiments, the Encrypted TSK is stored in an audit database. In some embodiments, the audit database comprises KMS Audit DB 229 of FIG. 2A. In some embodiments, the Encrypted TSK is encrypted using a public key and can only be decrypted using the corresponding private key. In various embodiments, the public/private key is the public/private key associated with MU Key 214 of FIG. 2A. In some embodiments, the public key is the public key of the certificate included with the request object received in 402.];
encrypting the public key into the encrypted token, wherein the encrypted token comprises a time identifier and an unique identifier key [Figure # 6, paragraph: 0093, In some embodiments, the key request context of the unlock response comprises the context for the key release and the released key. In some embodiments, the key request context comprises the fields Tenant Master Key ID 651, Encrypted Tenant Master Key With KMS Key 652, Customer ID 653, Response Time 654, In Response To Nonce 655, Response Nonce 656, In Response To Hash 657, and Authorized Key Hash 658. In some embodiments, the key request context contains a tenant master key identifier (e.g., Tenant Master Key ID 651), a tenant master key encrypted with the KMS public key (e.g., Encrypted Tenant Master Key With KMS Key 652), a customer identifier (e.g., Customer ID 653), a response time (e.g., Response Time 654), the nonce from the release request (e.g., In Response To Nonce 655), a newly generated response nonce (e.g., Response Nonce 656), a response to a hash (e.g., In Response To Hash 657), and an authorized key hash (e.g., Authorized Key Hash 658).]; and
storing an initialization vector of the encrypted token into a memory cache [Figure # 2B, component # 268 and paragraph: 0049, In 268, the encrypted tenant service key and the encrypted tenant master key are stored in a key database.].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Davis as modified and Hamel in order for the authenticating the requesting user who scans the NFC tag for owner information of physical asset thru the NFT stored on the blockchain of Davis as modified to include exchanging owner information securely with a key derivation index of Hamel. This would allow for the user and owner to exchange data between parties in a secure and efficient manner thru key derivation and key exchange. See paragraphs: 0027, 0028 of Hamel.
As per computing device claim 12, that includes the same or similar claim limitations as method claim 4, and is similarly rejected.
Claim(s) 5, 6, 13 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al. [US PAT # 11348152] in view of Hoerstein et al. [US PGPUB # 2019/0305943] and Hamel et al. [US PGPUB # 2018/0062835] as applied to claim[s] 4 above, and further in view of Meyers et al. [US PGPUB # 2023/0010172].
As per claim 5. Davis and Hoerstein and Hamel do teach what is taught in the rejection of claim # 5 above.
However, Meyers does teach the computer-implemented method according to claim 4, further comprising:
transmitting the encrypted token to a browser, wherein the encrypted token is displayed to a user as a QR code.
However, Meyers does teach the computer-implemented method according to claim 4, further comprising:
transmitting the encrypted token to a browser, wherein the encrypted token is displayed to a user as a QR code [Figure # 3, components # 302, 304, 202 and paragraph: 0043, In some embodiments, the tag 202 may be in the form of a two – dimensional matrix barcode, such as a Quick Response (QR) code…….In some embodiments, the tag data may be stored in the QR code in an encrypted manner].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Davis as modified and Meyers in order for the authenticating the requesting user who scans the NFC tag for owner information of physical asset thru the NFT stored on the blockchain of Davis as modified to include the user scanning a QR code of Meyers. This would allow for the requesting user to be assured that the QR code isn’t compromised a man in the middle attack. See paragraph: 0043 of Meyers.
As per claim 6. Davis as modified does teach the computer-implemented method according to claim 5, wherein the encrypted message is received as a result of the user scanning the QR code [Meyers, paragraph: 0044, lines 1 – 8, Accordingly, to embodiments, the tag 202 (whether in the QR code form or otherwise) may be configured to be read/scanned only by a corresponding tag reader (i.e. tag reader 138 illustrated in Figure # 1)].
As per computing device claim 13, that includes the same or similar claim limitations as method claim 5, and is similarly rejected.
As per computing device claim 14, that includes the same or similar claim limitations as method claim 6, and is similarly rejected.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANT SHAIFER - HARRIMAN whose telephone number is (571)272-7910. The examiner can normally be reached M - F: 9am to 5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kambiz Zand can be reached at 571- 272- 3811. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DANT B SHAIFER HARRIMAN/ Primary Examiner, Art Unit 2434