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 .
Election/Restrictions
Applicant’s election without traverse of claims 1-20 in the reply filed on 02/17/2026 is acknowledged.
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.
Claim 20 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 20 recites “wherein the first cipher code and the second cipher code are generated in an NFC label that is affixed to a product”. Claim 20 depends from claim 19 which finds its dependency from independent claim 14. Claim 14 recites that the second cipher code is generated at an authentication server. The scope of claim 20 is therefore unclear because the second cipher code cannot reasonably be both generated by the authentication server and generated in the NFC label as claimed. For examination purposes, claim 20 will be interpreted to require that the first cipher code and the third cipher code are generated in the NFC label, because this interpretation corresponds to the tag side cipher codes recited in claim 14.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 4-5, 7, 10, 12, 14, 17 and 19 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hoyer (US 2016/0205549).
As per claim 1, Hoyer discloses a method for authenticating a near field communication (NFC) label, the method comprising:
receiving a first message that includes a label ID and a first cipher code from a mobile device ([0023] In some embodiments, the authentication service receives the TAGID and TAC via a Short Message Service (SMS) message, a Multi-Media Message Service (MMS) message, an email message, DTMF tones, an IVR system, or the like. This may allow the mobile device to transmit the TAGID and TAC to the authentication service directly instead of going through the content server.);
generating a second cipher code in response to receiving the first message ([0086] The authentication service 344 may comprise a TAGID repository 348 along with its own cryptographic engine 352. The cryptographic engine 352 may be similar or identical to the cryptographic engine 328 of the smart tag 308, thereby enabling the authentication service 344 to check TACs generated by the smart tag 308. More specifically, when the authentication service 344 receives a request for authentication of a smart tag interaction in step S306, the authentication service 344 may compare the TAGID received in the request for authentication to one or more TAGIDs contained in the TAGID repository 348 to determine whether the smart tag 308 that provided the response to the mobile device 304 is a valid and known smart tag. Additionally, the authentication service 344 may invoke its cryptographic engine 352 to generate an TAC based on its internally-maintained K and C values, which should match the K and C values of a valid smart tag 308 (step S307). If the TAC generated by the cryptographic engine 352 matches the TAC received in step S306, then the authentication service 344 can verify that the interaction between the smart tag 308 and mobile device 304 was a unique interaction (e.g., there was no replay of a TAC by the mobile device 304);
transmitting an engage again message to the mobile device in response to determining that the first cipher code matches the second cipher code ([0016] determining that a second form of authentication is required; [0017] in response to determining that a second form of authentication is required and only after the authentication service has provided the content server with the message indicating that the one or more web pages can be provided to the mobile device, issuing a second challenge to a user of the mobile device; [0018] receiving a response to the second challenge from the user of the mobile device; determining that the response to the second challenge matches an expected response; and [0019] in response to determining that the response to the second challenge matches the expected response, providing the one or more web pages to the mobile device…[0022] In some embodiments, the TAC is received in response to the content server issuing a request for the TAC to the mobile device after the mobile device requested the one or more web pages from the content server. Moreover, the request for the TAC issued by the content server may be transmitted to the mobile device via a command embedded in a Hyper Text Markup Language (HTML) file in accordance with known Hyper Text Transport Protocol (HTTP) methods…the second challenge/request for additional TAC information corresponds to the claimed engage again message because it causes the mobile device to interact with/read the smart tag again);
receiving a second message that includes a label ID and a third cipher code from the mobile device after the engage again message is transmitted to the mobile device ([0114] Accordingly, the mobile device 304 will receive a second response from the smart tag 308 in the form of a second data object (step 732). The second response may contain the response-specific information, such as an TAC, as well as an optional TAGID of the smart tag 308. The second response may also contain tag data, which may be the same or different from the tag data received in the first response. [0115] The method continues with the mobile device 304 parsing the second data object to separate the URL, TAC, and/or TAGID (step 736). Once separated, the mobile device 304 may provide the TAC and/or TAGID back to the content server 340, perhaps also with the URL again (step 740). This information may be used by the content server 340 to determine if the smart tag 308 is a valid smart tag and if the interaction(s) between the smart tag 308 and mobile device 304 correspond to unique interaction(s).);
generating a fourth cipher code in response to receiving the second message ([0120] Based on the analysis performed in step 816, the authentication service 344 determines whether the TAC was valid or invalid and optionally whether the TAGID is valid or invalid (step 820). Results of this determination are provided back to the content server 340 (step 824). If the authentication service 344 informs the content server 340 that the TAC or TAGID was invalid, then the method ends…[0086] The authentication service 344 may comprise a TAGID repository 348 along with its own cryptographic engine 352. The cryptographic engine 352 may be similar or identical to the cryptographic engine 328 of the smart tag 308, thereby enabling the authentication service 344 to check TACs generated by the smart tag 308. More specifically, when the authentication service 344 receives a request for authentication of a smart tag interaction in step S306, the authentication service 344 may compare the TAGID received in the request for authentication to one or more TAGIDs contained in the TAGID repository 348 to determine whether the smart tag 308 that provided the response to the mobile device 304 is a valid and known smart tag. Additionally, the authentication service 344 may invoke its cryptographic engine 352 to generate an TAC based on its internally-maintained K and C values, which should match the K and C values of a valid smart tag 308 (step S307). If the TAC generated by the cryptographic engine 352 matches the TAC received in step S306, then the authentication service 344 can verify that the interaction between the smart tag 308 and mobile device 304 was a unique interaction (e.g., there was no replay of a TAC by the mobile device 304); and
transmitting an authentication successful message to the mobile device in response to determining that the third cipher code matches the fourth cipher code ([0089] If the authentication service 344 validates both the tag and the interaction, then the content server 340 may continue with providing the requested content (e.g., a web page, HTML document, XML file, etc.) back to the mobile device 304 (step S309)).
As per claim 4, Hoyer discloses comparing the first cipher code to the second cipher code at an authentication server, and comparing the third cipher code to the fourth cipher code at the authentication server ([0086] The authentication service 344 may comprise a TAGID repository 348 along with its own cryptographic engine 352. The cryptographic engine 352 may be similar or identical to the cryptographic engine 328 of the smart tag 308, thereby enabling the authentication service 344 to check TACs generated by the smart tag 308. More specifically, when the authentication service 344 receives a request for authentication of a smart tag interaction in step S306, the authentication service 344 may compare the TAGID received in the request for authentication to one or more TAGIDs contained in the TAGID repository 348 to determine whether the smart tag 308 that provided the response to the mobile device 304 is a valid and known smart tag. Additionally, the authentication service 344 may invoke its cryptographic engine 352 to generate an TAC based on its internally-maintained K and C values, which should match the K and C values of a valid smart tag 308 (step S307). If the TAC generated by the cryptographic engine 352 matches the TAC received in step S306, then the authentication service 344 can verify that the interaction between the smart tag 308 and mobile device 304 was a unique interaction (e.g., there was no replay of a TAC by the mobile device 304).).
As per claim 5, Hoyer discloses wherein the first message includes a URL and the second message includes a URL, wherein the URL in the first message matches the URL in the second message, and further comprising comparing the first cipher code to the second cipher code at an authentication server that is accessed via the URL, and comparing the third cipher code to the fourth cipher code at the authentication server ([0082] Upon receiving the results from the cryptographic engine 328, the NFC applet 316 formats a response for the mobile device 304 that includes the tag data 320 as well as the results received from the cryptographic engine 328 (e.g., the TAC). The NFC applet 316 then prepares the data object 124 to be provided to the mobile device 304 in step S303. More particularly, the TAC may correspond to the response-specific data 128 in the data object 124 whereas the tag data 320 and TAGID 312 may correspond to the non-response-specific data. As a non-limiting example, the message transmitted back to the mobile device 304 may be formatted for transmission via NFC, Bluetooth, or some other proximity-based RF communication protocol. Even more specifically, the message transmitted back to the mobile device 304 in step S303 may comprise one or more NDEF records having the tag data 320, TAGID 312, and TAC. As a specific non-limiting example, the response may be formatted as a URL according to the following: URL=StaticURL+/+TAGID+/+TAC [0083] Where the StaticURL may correspond to the tag data 320 (e.g., a URL written to the smart tag 308 by the tag personalization or content provider 228 which points to a content server 340), the TAGID may correspond to the TAGID 312 of the smart tag 308 (e.g., an identifier that is specific to the smart tag 308), and the TAC may correspond to the TAC that is unique to the current interaction between the smart tag 308 and mobile device 304. As shown above, the tag data 320, TAGID 312, and TAC may be separated by delimiters or some other identifiers that allow the individual components to be separated out of the URL. As can be appreciated, formats other than a URL (e.g., phone number, email address, etc.) may be used without departing from the scope of the present disclosure… Hoyer further teaches the second message aspect because, after the second challenge, the mobile device receives a second NFC object, parses TAC from tag data, and provides the TAC to the authentication service for analysis. Under BRI, the staticURL remains the same URL for the same tag/content server path, while the TAC changes for each interaction. Thus, Hoyer teaches first and second URL containing messages with matching URL/static server address and different dynamic cipher codes. )
As per claim 7, Hoyer discloses wherein the authentication server is configured to generate the second cipher code and the fourth cipher code using an encryption algorithm, which is the same as an encryption algorithm that is used by an NFC IC device that corresponds to the label ID ([0086] The authentication service 344 may comprise a TAGID repository 348 along with its own cryptographic engine 352. The cryptographic engine 352 may be similar or identical to the cryptographic engine 328 of the smart tag 308, thereby enabling the authentication service 344 to check TACs generated by the smart tag 308. More specifically, when the authentication service 344 receives a request for authentication of a smart tag interaction in step S306, the authentication service 344 may compare the TAGID received in the request for authentication to one or more TAGIDs contained in the TAGID repository 348 to determine whether the smart tag 308 that provided the response to the mobile device 304 is a valid and known smart tag. Additionally, the authentication service 344 may invoke its cryptographic engine 352 to generate an TAC based on its internally-maintained K and C values, which should match the K and C values of a valid smart tag 308 (step S307). If the TAC generated by the cryptographic engine 352 matches the TAC received in step S306, then the authentication service 344 can verify that the interaction between the smart tag 308 and mobile device 304 was a unique interaction (e.g., there was no replay of a TAC by the mobile device 304).).
As per claim 10, Hoyer discloses a method for authenticating a near field communication (NFC) label, the method comprising:
receiving a first message that includes a label ID and a first cipher code from a mobile device ([0023] In some embodiments, the authentication service receives the TAGID and TAC via a Short Message Service (SMS) message, a Multi-Media Message Service (MMS) message, an email message, DTMF tones, an IVR system, or the like. This may allow the mobile device to transmit the TAGID and TAC to the authentication service directly instead of going through the content server.);
generating a second cipher code from the first cipher code using the label ID from the first message; determining if the first cipher code matches the second cipher code; ([0086] The authentication service 344 may comprise a TAGID repository 348 along with its own cryptographic engine 352. The cryptographic engine 352 may be similar or identical to the cryptographic engine 328 of the smart tag 308, thereby enabling the authentication service 344 to check TACs generated by the smart tag 308. More specifically, when the authentication service 344 receives a request for authentication of a smart tag interaction in step S306, the authentication service 344 may compare the TAGID received in the request for authentication to one or more TAGIDs contained in the TAGID repository 348 to determine whether the smart tag 308 that provided the response to the mobile device 304 is a valid and known smart tag. Additionally, the authentication service 344 may invoke its cryptographic engine 352 to generate an TAC based on its internally-maintained K and C values, which should match the K and C values of a valid smart tag 308 (step S307). If the TAC generated by the cryptographic engine 352 matches the TAC received in step S306, then the authentication service 344 can verify that the interaction between the smart tag 308 and mobile device 304 was a unique interaction (e.g., there was no replay of a TAC by the mobile device 304);
transmitting an engage again message to the mobile device in response to determining that the first cipher code matches the second cipher code, or an authentication failed message to the mobile device in response to determining that the first cipher code does not match the second cipher code; ([0016] determining that a second form of authentication is required; [0017] in response to determining that a second form of authentication is required and only after the authentication service has provided the content server with the message indicating that the one or more web pages can be provided to the mobile device, issuing a second challenge to a user of the mobile device; [0018] receiving a response to the second challenge from the user of the mobile device; determining that the response to the second challenge matches an expected response; and [0019] in response to determining that the response to the second challenge matches the expected response, providing the one or more web pages to the mobile device…[0022] In some embodiments, the TAC is received in response to the content server issuing a request for the TAC to the mobile device after the mobile device requested the one or more web pages from the content server. Moreover, the request for the TAC issued by the content server may be transmitted to the mobile device via a command embedded in a Hyper Text Markup Language (HTML) file in accordance with known Hyper Text Transport Protocol (HTTP) methods…the second challenge/request for additional TAC information corresponds to the claimed engage again message because it causes the mobile device to interact with/read the smart tag again);
receiving a second message that includes a label ID and a third cipher code from the mobile device after the engage again message is transmitted to the mobile device ([0114] Accordingly, the mobile device 304 will receive a second response from the smart tag 308 in the form of a second data object (step 732). The second response may contain the response-specific information, such as an TAC, as well as an optional TAGID of the smart tag 308. The second response may also contain tag data, which may be the same or different from the tag data received in the first response. [0115] The method continues with the mobile device 304 parsing the second data object to separate the URL, TAC, and/or TAGID (step 736). Once separated, the mobile device 304 may provide the TAC and/or TAGID back to the content server 340, perhaps also with the URL again (step 740). This information may be used by the content server 340 to determine if the smart tag 308 is a valid smart tag and if the interaction(s) between the smart tag 308 and mobile device 304 correspond to unique interaction(s).);
generating a fourth cipher code from the third cipher code using the label ID from the second message; determining if the third cipher code matches the fourth cipher code ([0120] Based on the analysis performed in step 816, the authentication service 344 determines whether the TAC was valid or invalid and optionally whether the TAGID is valid or invalid (step 820). Results of this determination are provided back to the content server 340 (step 824). If the authentication service 344 informs the content server 340 that the TAC or TAGID was invalid, then the method ends…[0086] The authentication service 344 may comprise a TAGID repository 348 along with its own cryptographic engine 352. The cryptographic engine 352 may be similar or identical to the cryptographic engine 328 of the smart tag 308, thereby enabling the authentication service 344 to check TACs generated by the smart tag 308. More specifically, when the authentication service 344 receives a request for authentication of a smart tag interaction in step S306, the authentication service 344 may compare the TAGID received in the request for authentication to one or more TAGIDs contained in the TAGID repository 348 to determine whether the smart tag 308 that provided the response to the mobile device 304 is a valid and known smart tag. Additionally, the authentication service 344 may invoke its cryptographic engine 352 to generate an TAC based on its internally-maintained K and C values, which should match the K and C values of a valid smart tag 308 (step S307). If the TAC generated by the cryptographic engine 352 matches the TAC received in step S306, then the authentication service 344 can verify that the interaction between the smart tag 308 and mobile device 304 was a unique interaction (e.g., there was no replay of a TAC by the mobile device 304); and
transmitting an authentication successful message to the mobile device in response to determining that the third cipher code matches the fourth cipher code, or an authentication failed message to the mobile device in response to determining that the first cipher code does not match the second cipher code ([0089] If the authentication service 344 validates both the tag and the interaction, then the content server 340 may continue with providing the requested content (e.g., a web page, HTML document, XML file, etc.) back to the mobile device 304 (step S309)).
As per claim 12, Hoyer discloses comparing the first cipher code to the second cipher code at an authentication server, and comparing the third cipher code to the fourth cipher code at the authentication server ([0086] The authentication service 344 may comprise a TAGID repository 348 along with its own cryptographic engine 352. The cryptographic engine 352 may be similar or identical to the cryptographic engine 328 of the smart tag 308, thereby enabling the authentication service 344 to check TACs generated by the smart tag 308. More specifically, when the authentication service 344 receives a request for authentication of a smart tag interaction in step S306, the authentication service 344 may compare the TAGID received in the request for authentication to one or more TAGIDs contained in the TAGID repository 348 to determine whether the smart tag 308 that provided the response to the mobile device 304 is a valid and known smart tag. Additionally, the authentication service 344 may invoke its cryptographic engine 352 to generate an TAC based on its internally-maintained K and C values, which should match the K and C values of a valid smart tag 308 (step S307). If the TAC generated by the cryptographic engine 352 matches the TAC received in step S306, then the authentication service 344 can verify that the interaction between the smart tag 308 and mobile device 304 was a unique interaction (e.g., there was no replay of a TAC by the mobile device 304).).
As per claim 14, Hoyer discloses A method for authenticating an NFC label, the method comprising:
at an authentication server; receiving a label ID and a first cipher code from a mobile device ([0023] In some embodiments, the authentication service receives the TAGID and TAC via a Short Message Service (SMS) message, a Multi-Media Message Service (MMS) message, an email message, DTMF tones, an IVR system, or the like. This may allow the mobile device to transmit the TAGID and TAC to the authentication service directly instead of going through the content server.);
generating a second cipher code from the first cipher code using the label ID received with the first cipher code; ([0086] The authentication service 344 may comprise a TAGID repository 348 along with its own cryptographic engine 352. The cryptographic engine 352 may be similar or identical to the cryptographic engine 328 of the smart tag 308, thereby enabling the authentication service 344 to check TACs generated by the smart tag 308. More specifically, when the authentication service 344 receives a request for authentication of a smart tag interaction in step S306, the authentication service 344 may compare the TAGID received in the request for authentication to one or more TAGIDs contained in the TAGID repository 348 to determine whether the smart tag 308 that provided the response to the mobile device 304 is a valid and known smart tag. Additionally, the authentication service 344 may invoke its cryptographic engine 352 to generate an TAC based on its internally-maintained K and C values, which should match the K and C values of a valid smart tag 308 (step S307). If the TAC generated by the cryptographic engine 352 matches the TAC received in step S306, then the authentication service 344 can verify that the interaction between the smart tag 308 and mobile device 304 was a unique interaction (e.g., there was no replay of a TAC by the mobile device 304);
generating an engage again message for transmission to the mobile device in response to determining that the first cipher code matches the second cipher code; ([0016] determining that a second form of authentication is required; [0017] in response to determining that a second form of authentication is required and only after the authentication service has provided the content server with the message indicating that the one or more web pages can be provided to the mobile device, issuing a second challenge to a user of the mobile device; [0018] receiving a response to the second challenge from the user of the mobile device; determining that the response to the second challenge matches an expected response; and [0019] in response to determining that the response to the second challenge matches the expected response, providing the one or more web pages to the mobile device…[0022] In some embodiments, the TAC is received in response to the content server issuing a request for the TAC to the mobile device after the mobile device requested the one or more web pages from the content server. Moreover, the request for the TAC issued by the content server may be transmitted to the mobile device via a command embedded in a Hyper Text Markup Language (HTML) file in accordance with known Hyper Text Transport Protocol (HTTP) methods…the second challenge/request for additional TAC information corresponds to the claimed engage again message because it causes the mobile device to interact with/read the smart tag again);
receiving a label ID and a third cipher code from the mobile device after the engage again message is transmitted to the mobile device; ([0114] Accordingly, the mobile device 304 will receive a second response from the smart tag 308 in the form of a second data object (step 732). The second response may contain the response-specific information, such as an TAC, as well as an optional TAGID of the smart tag 308. The second response may also contain tag data, which may be the same or different from the tag data received in the first response. [0115] The method continues with the mobile device 304 parsing the second data object to separate the URL, TAC, and/or TAGID (step 736). Once separated, the mobile device 304 may provide the TAC and/or TAGID back to the content server 340, perhaps also with the URL again (step 740). This information may be used by the content server 340 to determine if the smart tag 308 is a valid smart tag and if the interaction(s) between the smart tag 308 and mobile device 304 correspond to unique interaction(s).);
generating a fourth cipher code from the third cipher code using the label ID received with the third cipher code ([0120] Based on the analysis performed in step 816, the authentication service 344 determines whether the TAC was valid or invalid and optionally whether the TAGID is valid or invalid (step 820). Results of this determination are provided back to the content server 340 (step 824). If the authentication service 344 informs the content server 340 that the TAC or TAGID was invalid, then the method ends…[0086] The authentication service 344 may comprise a TAGID repository 348 along with its own cryptographic engine 352. The cryptographic engine 352 may be similar or identical to the cryptographic engine 328 of the smart tag 308, thereby enabling the authentication service 344 to check TACs generated by the smart tag 308. More specifically, when the authentication service 344 receives a request for authentication of a smart tag interaction in step S306, the authentication service 344 may compare the TAGID received in the request for authentication to one or more TAGIDs contained in the TAGID repository 348 to determine whether the smart tag 308 that provided the response to the mobile device 304 is a valid and known smart tag. Additionally, the authentication service 344 may invoke its cryptographic engine 352 to generate an TAC based on its internally-maintained K and C values, which should match the K and C values of a valid smart tag 308 (step S307). If the TAC generated by the cryptographic engine 352 matches the TAC received in step S306, then the authentication service 344 can verify that the interaction between the smart tag 308 and mobile device 304 was a unique interaction (e.g., there was no replay of a TAC by the mobile device 304); and
generating an authentication successful message for transmission to the mobile device in response to determining that the third cipher code matches the fourth cipher code ([0089] If the authentication service 344 validates both the tag and the interaction, then the content server 340 may continue with providing the requested content (e.g., a web page, HTML document, XML file, etc.) back to the mobile device 304 (step S309)).
As per claim 17, Hoyer discloses comparing the first cipher code to the second cipher code at an authentication server, and comparing the third cipher code to the fourth cipher code at the authentication server ([0086] The authentication service 344 may comprise a TAGID repository 348 along with its own cryptographic engine 352. The cryptographic engine 352 may be similar or identical to the cryptographic engine 328 of the smart tag 308, thereby enabling the authentication service 344 to check TACs generated by the smart tag 308. More specifically, when the authentication service 344 receives a request for authentication of a smart tag interaction in step S306, the authentication service 344 may compare the TAGID received in the request for authentication to one or more TAGIDs contained in the TAGID repository 348 to determine whether the smart tag 308 that provided the response to the mobile device 304 is a valid and known smart tag. Additionally, the authentication service 344 may invoke its cryptographic engine 352 to generate an TAC based on its internally-maintained K and C values, which should match the K and C values of a valid smart tag 308 (step S307). If the TAC generated by the cryptographic engine 352 matches the TAC received in step S306, then the authentication service 344 can verify that the interaction between the smart tag 308 and mobile device 304 was a unique interaction (e.g., there was no replay of a TAC by the mobile device 304).).
As per claim 19, Hoyer discloses wherein the authentication server is configured to generate the second cipher code and the fourth cipher code using an encryption algorithm that is also used by an NFC IC device that corresponds to the label ID ([0086] The authentication service 344 may comprise a TAGID repository 348 along with its own cryptographic engine 352. The cryptographic engine 352 may be similar or identical to the cryptographic engine 328 of the smart tag 308, thereby enabling the authentication service 344 to check TACs generated by the smart tag 308. More specifically, when the authentication service 344 receives a request for authentication of a smart tag interaction in step S306, the authentication service 344 may compare the TAGID received in the request for authentication to one or more TAGIDs contained in the TAGID repository 348 to determine whether the smart tag 308 that provided the response to the mobile device 304 is a valid and known smart tag. Additionally, the authentication service 344 may invoke its cryptographic engine 352 to generate an TAC based on its internally-maintained K and C values, which should match the K and C values of a valid smart tag 308 (step S307). If the TAC generated by the cryptographic engine 352 matches the TAC received in step S306, then the authentication service 344 can verify that the interaction between the smart tag 308 and mobile device 304 was a unique interaction (e.g., there was no replay of a TAC by the mobile device 304).).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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 nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 2-3, 6, 8, 11, 15-16 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hoyer (US 2016/0205549), as rejected in claim 1/5/10/14/17, in view of Lu (US 2019/0052468).
As per claim 2, the combination of Hoyer in view of Lu discloses the second cipher code is generated from the first cipher code using at least one key that is obtained using the label ID that is received in the first message; and the fourth cipher code is generated from the third cipher code using at least one key that is obtained using the label ID that is received in the second message.
First, as Hoyer discloses receiving the claimed label ID and first cipher code and generating a second cipher code from the first cipher code ([0012] receiving, at an authentication server, a Tag Unique Identifier (TAGID) and a Tag Authentication Cryptogram (TAC) generated by a smart tag in response to being read by the mobile device,). Hoyer also discloses that the authentication service uses the TAGID (label ID) in connection with a repository and generates an expected TAC (first cipher code) using internally maintained cryptographic values ([0086] The authentication service 344 may comprise a TAGID repository 348 along with its own cryptographic engine 352. The cryptographic engine 352 may be similar or identical to the cryptographic engine 328 of the smart tag 308, thereby enabling the authentication service 344 to check TACs generated by the smart tag 308. More specifically, when the authentication service 344 receives a request for authentication of a smart tag interaction in step S306, the authentication service 344 may compare the TAGID received in the request for authentication to one or more TAGIDs contained in the TAGID repository 348 to determine whether the smart tag 308 that provided the response to the mobile device 304 is a valid and known smart tag. Additionally, the authentication service 344 may invoke its cryptographic engine 352 to generate an TAC based on its internally-maintained K and C values, which should match the K and C values of a valid smart tag 308 (step S307). If the TAC generated by the cryptographic engine 352 matches the TAC received in step S306, then the authentication service 344 can verify that the interaction between the smart tag 308 and mobile device 304 was a unique interaction (e.g., there was no replay of a TAC by the mobile device 304).)
However, while Hoyer alone strongly suggests that the server must use the receive TAGID to identify the proper tag specific K/C values before generating the expected TAC, it does not state the key lookup uses the TAGID.
For this reason, Lu supplies the explicit “key associated with corresponding NFC tag” database. It discloses that the authentication server stores shared key material ([0036] Referring now to FIG. 2, the authentication server 28 may include a copy of a shared key 36. The shared key 36 may be stored within a memory of the authentication server 28. The authentication system 20 may also be configured to interact with an asset database that may be stored on the authentication server 28 or securely accessed by the authentication server 28. The asset data base will include a plurality of unique shared keys or shared secrets that are associated with provisioned assets and corresponding NFC tags 24.)
with respect to the fourth cipher code being generated from the third cipher code using at least one key obtained using the label ID received in the second message, Hoyer discloses that after a challenge is received from the content server, the mobile device transmits the challenge to the smart tag, receives a second NFC object from the smart tag, parses the second NFC object to separate TAC from tag data, and provides the TAC to the authentication service for analysis. Thus, Hoyer’s second TAC corresponds to the claimed third cipher code. Hoyer further teaches that the authentication service compares the received TAGID to TAGIDs in a TAGID repository and invokes its cryptographic engine to generate a TAC based on internally maintained K and C values. Thus, Hoyer’s server generated expected TAC for the second received TAC corresponds to the claimed fourth cipher code. Similar to above, Lu further teaches that an asset database includes unique shared keys or shared secrets associated with corresponding NFC tags. Therefore, it would have been obvious to a person of ordinary skill in the art to use the label ID/TAGID received with the second TAC to obtain the corresponding tag specific key and generate the fourth cipher code for comparison with the third cipher code (please see claim 1 rejection for more details).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Lu in the teaching of Hoyer, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 3, Hoyer in view of Lu discloses generating the second cipher code involves decoding the first cipher code using at least one key that is obtained using the label ID that is received in the first message to produce a decoded output and encoding the decoded output using the at least one key to generate the second cipher code; and generating the fourth cipher code involves decoding the third cipher code using at least one key that is obtained using the label ID that is received in the second message to produce a decoded output and encoding the decoded output using the at least one key to generate the fourth cipher code.
As explained in claim 2 rejection above, Hoyer teaches the NFC TAGID/TAC framework because Hoyer’s TAC corresponds to the claimed cipher code, Hoyer’s TAGID corresponds to the claimed label ID, and Hoyer’s authentication service generated expected TAC corresponds to the claimed second cipher code or fourth cipher code. Hoyer teaches that that the authentication service invokes its cryptographic engine to generate an expected TAC based on internally maintained K/C values.
Hoyer also teaches the claimed encoding because the authentication service cryptographically generates an expected TAC using K/C values (paragraph 86, under BRI, encoding the decoded output includes applying cryptographic processing to generate a server side comparison cipher code).
Lu further discloses the claimed decoding because it teaches encrypted output from the NFC tag corresponds to a cipher code (abstract, “When the user device verifies challenge/response messages and the unique identifier, and the ECDSA signature is verified by either the user device or the authentication server, the encrypted output is decrypted and the authentication server compares the decrypted data with the stored shared key to either determine that the asset is authentic or notify a stakeholder associated with the asset that the asset is inauthentic.”). Lu’s decrypted data corresponds to the claimed decoded output, and the shared key corresponds to the claimed at least one key.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Lu in the teaching of Hoyer, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 6, Hoyer discloses an authentication server with TAGID repository that includes TAGID which corresponds to the labelID (paragraph 86). However, Hoyer does not disclose but Lu discloses wherein the authentication server includes a database of keys that are indexed by label ID ([0036] Referring now to FIG. 2, the authentication server 28 may include a copy of a shared key 36. The shared key 36 may be stored within a memory of the authentication server 28. The authentication system 20 may also be configured to interact with an asset database that may be stored on the authentication server 28 or securely accessed by the authentication server 28. The asset data base will include a plurality of unique shared keys or shared secrets that are associated with provisioned assets and corresponding NFC tags 24.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Lu in the teaching of Hoyer, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 8, Hoyer discloses wherein the label ID received in the first message matches the label ID received in the second message (as per claim 1 and 2 rejection, Hoyer teaches the matching label ID because Hoyer’s TAGID corresponds to the claimed label ID, and both the first and second NFC interactions are with the same smart tag. Hoyer teaches that the smart tag generates a data object including TAGID and TAC, and it teaches a second NFC object after the challenge. Because both NFC objects come from the smart tag, the label ID/TAGID matches.).
Hoyer also teaches the second and fourth cipher codes because Hoyer’s authentication service generated expected TACs correspond to the claimed second cipher code and fourth cipher code. Hoyer teaches that the authentication service generates expected TACs using internally maintained K/C values (paragraph 86). However, Hoyer does not disclose but Lu discloses that the key used to for those generated TACs is obtained using the label ID because Lu teaches shared keys/secrets associated with corresponding NFC tags (paragraph 36).
As per claim 11, Hoyer in view of Lu discloses generating the second cipher code involves decoding the first cipher code using at least one key that is obtained using the label ID that is received in the first message to produce a decoded output and encoding the decoded output using the at least one key to generate the second cipher code; and generating the fourth cipher code involves decoding the third cipher code using at least one key that is obtained using the label ID that is received in the second message to produce a decoded output and encoding the decoded output using the at least one key to generate the fourth cipher code.
Hoyer teaches the NFC TAGID/TAC framework because Hoyer’s TAC corresponds to the claimed cipher code, Hoyer’s TAGID corresponds to the claimed label ID, and Hoyer’s authentication service generated expected TAC corresponds to the claimed second cipher code or fourth cipher code. Hoyer teaches that that the authentication service invokes its cryptographic engine to generate an expected TAC based on internally maintained K/C values (paragraph 86).
Hoyer also teaches the claimed encoding because the authentication service cryptographically generates an expected TAC using K/C values (paragraph 86, under BRI, encoding the decoded output includes applying cryptographic processing to generate a server side comparison cipher code).
Lu further discloses the claimed decoding because it teaches encrypted output from the NFC tag corresponds to a cipher code (abstract, “When the user device verifies challenge/response messages and the unique identifier, and the ECDSA signature is verified by either the user device or the authentication server, the encrypted output is decrypted and the authentication server compares the decrypted data with the stored shared key to either determine that the asset is authentic or notify a stakeholder associated with the asset that the asset is inauthentic.”). Lu’s decrypted data corresponds to the claimed decoded output, and the shared key corresponds to the claimed at least one key.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Lu in the teaching of Hoyer, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 15, Hoyer in view of Lu discloses the second cipher code is generated from the first cipher code using at least one key that is obtained using the label ID that is received with the first cipher code; and the fourth cipher code is generated from the third cipher code using at least one key that is obtained using the label ID that is received with the third cipher code.
Hoyer teaches the NFC TAGID/TAC framework because Hoyer’s TAC corresponds to the claimed cipher code, Hoyer’s TAGID corresponds to the claimed label ID, and Hoyer’s authentication service generated expected TAC corresponds to the claimed second cipher code or fourth cipher code. Hoyer teaches that that the authentication service invokes its cryptographic engine to generate an expected TAC based on internally maintained K/C values (paragraph 86).
Lu further discloses that shared keys/secrets are associated with corresponding NFC tag ID ([0036] Referring now to FIG. 2, the authentication server 28 may include a copy of a shared key 36. The shared key 36 may be stored within a memory of the authentication server 28. The authentication system 20 may also be configured to interact with an asset database that may be stored on the authentication server 28 or securely accessed by the authentication server 28. The asset data base will include a plurality of unique shared keys or shared secrets that are associated with provisioned assets and corresponding NFC tags 24.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Lu in the teaching of Hoyer, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 16, Hoyer in view of Lu discloses generating the second cipher code involves decoding the first cipher code using at least one key that is obtained using the label ID that is received in the first message to produce a decoded output and encoding the decoded output using the at least one key to generate the second cipher code; and generating the fourth cipher code involves decoding the third cipher code using at least one key that is obtained using the label ID that is received in the second message to produce a decoded output and encoding the decoded output using the at least one key to generate the fourth cipher code.
Hoyer teaches the NFC TAGID/TAC framework because Hoyer’s TAC corresponds to the claimed cipher code, Hoyer’s TAGID corresponds to the claimed label ID, and Hoyer’s authentication service generated expected TAC corresponds to the claimed second cipher code or fourth cipher code. Hoyer teaches that that the authentication service invokes its cryptographic engine to generate an expected TAC based on internally maintained K/C values (paragraph 86).
Hoyer also teaches the claimed encoding because the authentication service cryptographically generates an expected TAC using K/C values (paragraph 86, under BRI, encoding the decoded output includes applying cryptographic processing to generate a server side comparison cipher code).
Lu further discloses the claimed decoding because it teaches encrypted output from the NFC tag corresponds to a cipher code (abstract, “When the user device verifies challenge/response messages and the unique identifier, and the ECDSA signature is verified by either the user device or the authentication server, the encrypted output is decrypted and the authentication server compares the decrypted data with the stored shared key to either determine that the asset is authentic or notify a stakeholder associated with the asset that the asset is inauthentic.”). Lu’s decrypted data corresponds to the claimed decoded output, and the shared key corresponds to the claimed at least one key.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Lu in the teaching of Hoyer, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 18, Hoyer discloses an authentication server with TAGID repository that includes TAGID which corresponds to the labelID (paragraph 86). However, Hoyer does not disclose but Lu discloses wherein the authentication server includes a database of keys that are indexed by label ID ([0036] Referring now to FIG. 2, the authentication server 28 may include a copy of a shared key 36. The shared key 36 may be stored within a memory of the authentication server 28. The authentication system 20 may also be configured to interact with an asset database that may be stored on the authentication server 28 or securely accessed by the authentication server 28. The asset data base will include a plurality of unique shared keys or shared secrets that are associated with provisioned assets and corresponding NFC tags 24.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Lu in the teaching of Hoyer, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim(s) 9, 13 and 20is/are rejected under 35 U.S.C. 103 as being unpatentable over Hoyer (US 2016/0205549), as rejected in claim 1/12/19, Bulawski (US 2021/0103938).
As per claim 9/13/20, Hoyer discloses wherein the first cipher code and the third cipher code are generated at an NFC label (paragraphs 16-22, 86, Hoyer teaches first and third cipher codes because TAC corresponds to the claimed cipher codes. It also teaches that the smart tag generates TACs in response to read requests. The first TAC generated during the first read corresponds to the first cipher code, and the second TAC generated during the second read corresponds to the third cipher code)
However, Hoyer does not disclose but Bulawski discloses that an NFC label that is affixed to a product and wherein the NFC label receives electromagnetic energy from the mobile device ([0025] The NFC tag 107 may be a sticker tag; removing the sticker from the product destroys the NFC chip. [0026] The NFC tag 107 may be an NFC inlay that is built into the product. As will be understood by those of skill in the art, an NFC tag may consist of an NFC inlay (e.g., all electronic parts, including an NFC chip and an antenna) and a type of packaging (e.g., a card, a sticker, a loop, and so on). For products that are equipped with the NFC tag 107 directly at a time of production, the NFC inlays may be embedded into the product (e.g., within a tongue of a shoe)… An NFC reader 105 transmits electromagnetic waves to induce electric current in an NFC chip 111 of an NFC tag 107. The NFC chip 111 is powered in this way and does not need its own power source. In response to receiving the energy from the NFC reader 105, the NFC tag 107 transmits a string of characters to the NFC reader 105. The string of characters may include, by way of example, a tag URL stored in the NFC tag 107 as described above.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Bulawski in the teaching of Hoyer, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OMAR ZEROUAL whose telephone number is (571)272-7255. The examiner can normally be reached Flex schedule.
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, Kevin Flynn can be reached at 5712703108. 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.
OMAR . ZEROUAL
Examiner
Art Unit 3628
/OMAR ZEROUAL/Primary Examiner, Art Unit 3629
Prosecution Insights