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 . In communications filed on 11/26/2025. Claims 1, 4, 7, 12, and 13 are amended. Claims 5-6, and 11 are cancelled. Claims 1-4, 7-10, and 12-13 are pending in this examination.
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. This examination is in response to US Patent Application No. 18/709,977.
Examiner Note
Applicant’s Cancellation of claims 5, and 6 below obviates previously raised claims5, and 6 objections.
Response to Arguments
Applicant's arguments filed 11/26/2025 have been fully considered but they are not persuasive:
Applicant submits on pages 10-12 of remarks filed on 02/22/2021 regarding claims 1, 12 and 13 that Masakazu in view of Tadahiko fails to disclose or suggest the features below.
The Office relies on Masakazu's tamper resistant measurement device as allegedly teaching these limitations. See Office Action at p. 13. In support of this position, the Office merely lists paragraphs [0012]-[0018], [0024], [0033], [0045], [0054]-[0056], [0059]-[0060], [0062], [0064], [0067], [0073], [0075]-[0079], [0081]-[0083], [0089], and [0122]-[0128] without identifying any specific disclosure within those paragraphs that correspond to the above-recited limitations.
Examiner respectfully disagrees with applicant argument for claims 1, 12 and 13 filed on 11/26/2025 on pages 10-12 of remarks. Examiner maintains the rejection.
Masakazu discloses:
in a case of receiving at least one substitute ID for specifying the UID of the product device and product history data of the product device from the SCM device for which the authentication has succeeded, the at least one processor is further configured to execute the instructions to register the product history data in association with the at least one substitute ID; and in the case of receiving the use start request from the product device for which the authentication has succeeded, the at least one processor is further configured to execute the instructions to read the product history data registered in association with the at least one substitute ID for specifying the UID in addition to the product history data registered in association with the UID of the product device.
[¶47] “Device ID” is ID information assigned to each of the devices 7, 7, And for example, a manufacturing serial number can be used. The “device public key” is a device public key corresponding to the device private key stored for each device 7. The device public key is obtained from the device public key certificate transmitted by the CA 3 to the verification server 5], and [¶¶73-75, The CPU 21 stores the generated device secret key in a predetermined area in the EEPROM 25. Then, the CPU 21 reads out device unique information unique to the device 7 such as the device ID and the MAC address of the tamper resistant unit 20 stored in advance in the EEPROM 25 and transmits these to the device registration server 6 together with the device public key (step). 10). The verification server 5 receives a device public key, device unique information, and the like from the device 7 and transmits them to the CA 3 (step 13). The CA 3 receives the device public key and device specific information of the device 7 from the device registration server 6 (step 15). Then, CA3 extracts the device ID from the device unique information. For example, “Device public key XXX is the device public key of device ID XXX. The prover is CA3”, A message including a device ID, a prover, and other certification date and time is generated. Furthermore, CA3 generates a digest from the message and digitally signs it by encrypting it with a CA private key…], and [¶¶82-83, The verification server 5 receives the verification information encrypted from the device 7 and decrypts it with the verification server private key stored in advance. Since the verification server private key has only the verification server 5, the encrypted verification information cannot be decrypted even if the verification information is passed on to others. Next, the verification server 5 searches the device registration database for the device ID included in the verification request information, and acquires the device public key associated with the device ID. Next, the verification server 5 confirms the digital signature using the device public key and confirms the authenticity of the verification information (step 60). More specifically, the verification server 5 generates a digest from the verification request information, decrypts the digital signature with the device public key, restores the digest, and confirms that the verification request information is authentic when the two match. If they do not match, the verification server 5 transmits an error message to the device 7 because the device 7 is not legitimate].
Examiner Note: as mentioned above in various paragraphs the device ID mentioned as : serial number, Device ID, MAC address tamper resistant unit, public key of the device , any of device description can be interchangeably( substituted) for registering the device with device registration server.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 7, 10, and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Uehata Masakazu (JP 2007-215103), hereinafter, “Masakazu” (filed in IDS 05/14/2024), and in view of Miyazawa Tadahiko (JP 2005-333596), hereinafter, “Tadahiko” (filed in IDS 05/14/2024).
Regarding claim 1, Masakazu discloses A product management system comprising at least one memory storing instructions; and at least one processor configured to execute the instructions to [¶¶12-17, Installation of Equipment] FIG. 1 is a block diagram showing an example of the network configuration of the information processing system (equated to product management system) according to the present embodiment. The information processing system 1 is arranged such that the CAs 3 and 3, the verification server 5, the customer servers 4 and 4, the device registration server 6, the devices 7, 7, 7, The parent CA2 is provided above the CA3 and CA3. Hereinafter, regarding a plurality of items such as CA 3, 3, customer server 4, 4, device 7, 7..., They are simply referred to as CA 3, customer server 4, device 7 unless otherwise distinguished…. The reason why a plurality of CAs 3 is provided in the information processing system 1 is that the devices 7 are distributed in large quantities and can be assigned to the CAs 3 by dividing them into, for example, each production lot or each customer who uses the devices 7. It is for doing so. As described above, the certificate trust chain is used for business convenience, and all the devices 7 may be handled by a single CA…. After the verification server 5 verifies that the device 7 is a legitimate product, the customer server 4 connects to the device 7]; and
generate, in case of receiving a certificate issuance request from a product device including [¶¶54-56, Next, the entire configuration of the procedure from pre-shipment processing to installation of the device 7 will be described with reference to FIG. In the figure, the order of the procedures is shown in parentheses, and the description will be made in accordance with this order. The procedure (1) to the procedure (4) are operations performed before the installation of the device 7 (preferably before shipping to the customer). (1) (Generation of Asymmetric Encryption Key Pair of Device Private Key and Device Public Key) When the hardware of the device 7 is completed, the worker in charge operates the device 7 to execute the asymmetric encryption key generation program and 20, the CPU 21 is caused to generate a device private key / device public key pair (asymmetric encryption key generation means). The device 7 stores the generated device secret key in a predetermined area of the EEPROM 25 (secret key storage means). (2) (Transmission of device public key) The device 7 is connected to the device registration server 6 in charge of the device 7 by the person in charge of work, and transmits the generated device public key, device unique information, etc. to the device registration server 6. (Public key providing means). Here, the device unique information includes information unique to the device 7 such as the device ID and the MAC address of the tamper resistant part( equated to HSM). The device registration server 6 receives these pieces of information from the device 7 (public key acquisition means). Then, the device registration server 6 transmits a device public key, device ID, and the like to the CA 3 and requests the CA 3 to issue a device public key certificate (public key certificate issue request means). (3) (Write device certificate) The CA 3 creates a device certificate from the device public key from the device registration server 6. The CA 3 adds the verification server public key certificate of the verification server 5 to the device certificate, creates a device certificate, and transmits the device certificate to the device registration server 6. Upon receiving the device certificate from the CA 3, the device registration server 6 adds verification server connection information to the device certificate and transmits it to the device 7. The device 7 receives the device certificate from the device registration server 6 and stores it in the tamper resistant unit 20. As described above, the device certificate includes a device public key certificate, verification server connection information, a verification server public key certificate, and the like]; and [¶73, The CPU 21 stores the generated device secret key in a predetermined area in the EEPROM 25. Then, the CPU 21 reads out device unique information unique to the device 7 such as the device ID and the MAC address of the tamper resistant unit 20 stored in advance in the EEPROM 25 and transmits these to the device registration server 6 together with the device public key (step). 10). The verification server 5 receives a device public key, device unique information, and the like from the device 7 and transmits them to the CA 3 (step 13)], and [¶¶75-76, The CA 3 creates a device public key certificate from the message and the digital signature (step 20), and then generates a device certificate using the device public key certificate and the verification server public key certificate (step 25). Then, the CA 3 transmits the generated device certificate to the device registration server 6 (step 30). The device registration server 6 receives the device certificate from the CA 3 and sends it to the device 7 with verification server connection information attached thereto (step 33). The verification server connection information may be transmitted separately from the device certificate. The device 7 receives the device certificate and stores it in the EEPROM 25 in the tamper resistant unit 20 (step 35). In the EEPROM 25, the CA public key certificate of CA3 and the root certificate of the parent CA2 are stored in advance, and the device 7 can confirm the legitimacy of the device certificate using these]; and
in case of receiving, from the product device, an authentication request including the public key certificate and authentication data to which the signature for the product device is attached; verify whether the authentication data are signed with the secret key that is paired with the public key by using the public key in the public key certificate included in the authentication request, and [¶¶59-60, The verification server public key certificate is a public key certificate obtained by digitally signing the verification server public key with the CA3 private key. Since the verification server public key certificate includes the verification server public key, the device 7 acquires the verification server public key. The device 7 can verify the legitimacy of the device public key certificate and the verification server public key certificate using a CA public key incorporated in advance. The device registration server 6 according to the present embodiment includes the verification server public key certificate included in the device certificate received from the CA 3 and transmits the device certificate to the device 7. However, the present invention is not limited to this, and the device certificate received from the CA 3 The verification server connection information can be separately transmitted to the device 7. (Registration Request for Device 7) The device registration server 6 can obtain a device public key certificate when the CA 3 issues a device certificate to the device 7. Then, the device registration server 6 creates registration request information including the device public key certificate obtained in this way, device specific information (device ID), and the like, and transmits the registration request information to the verification server 5. Request registration of the device 7 (public key certificate transmission means). The verification server 5 receives the registration request information from the device registration server 6 and updates the device registration database using this information]; and [¶¶77-78, On the other hand, after transmitting the device certificate to the device 7, the device registration server 6 transmits registration request information including a device ID, a device public key certificate, and the like to the verification server 5 to the device registration database of the device 7. Registration request is made (step 40). At this time, the device registration server 6 digitally signs the registration request information with the device registration server private key and transmits it to the verification server 5 so that the verification server 5 can confirm the legitimacy of the verification request information with the device registration server public key. To verify the public key certificate included in the authentication request by using a CA public key that is paired with a CA secret key used for the signature by the certificate authority. In the verification server 5, the device registration server 6 digitally signs the registration request information, and the verification server 5 confirms this to confirm the legitimacy of the registration request information. The verification server 5 confirms the legitimacy of the device public key certificate using the device registration server public key and stores the correspondence between the customer server connection information, the device ID, and the device public key included in the registration request information in the device registration database. Register (step 45)]; and [ ¶64, The verification request information is obtained by digitally signing the device ID, device connection information for connecting from the customer server 4 to the device 7, environment information (information on the network connection environment) with the device private key, and encrypting it with the verification server public key…when the device 7 is connected to the network 10, it acquires its own device connection information (connection information acquisition means) and transmits it to the verification server 5 (connection information transmission means). On the other hand, the verification server 5 includes connection information receiving means for receiving this. The verification request information includes a digital signature obtained by encrypting a digest (predetermined information) with a device secret key, and functions as signature information. Thus, the device 7 has a signature information transmission unit], and [¶¶80-82, Next, with reference to the flowchart of FIG. 7, a procedure until the device 7 is installed at the installation site and connected to the customer server 4 via the network 10 will be described. When the device 7 is shipped to the customer, it is transported to the installation location based on the customer's business plan. The person in charge of installation goes to the site, connects the device 7 to the network 10 and starts the verification request program. Then, the device 7 collects device connection information such as its own IP address on the network 10 and environmental information such as being connected via a router (step 50). Next, the device 7 reads its own device ID from the EEPROM 25 and creates a verification request information by digitally signing the device ID together with the device connection information and environment information collected earlier with the device private key. Then, the device 7 creates the encrypted verification request information by encrypting the verification request information with the verification server public key. Next, the device 7 connects to the verification server 5 using the verification server connection information, transmits the encrypted verification request information to the verification server 5, and requests the verification server 5 for its own verification (step 55).The verification server 5 receives the verification information encrypted from the device 7 and decrypts it with the verification server private key stored in advance. Since the verification server private key has only the verification server 5, the encrypted verification information cannot be decrypted even if the verification information is passed on to others. Next, the verification server 5 searches the device registration database for the device ID included in the verification request information and acquires the device public key associated with the device ID.]; and
determine that authentication has succeeded in a case where the verification of the public key certificate included in the authentication request has succeeded and the verification of the signature attached to the authentication data has succeeded [¶17, The verification server 5 is a server for verifying the legitimacy of the device 7 and preventing unauthorized use of the device 7 such as impersonation when the device 7 is installed in the network 10 and connected to the customer server 4. After the verification server 5 verifies that the device 7 is a legitimate product, the customer server 4 connects to the device 7], and [¶64, The verification request information is obtained by digitally signing the device ID, device connection information for connecting from the customer server 4 to the device 7, environment information (information on the network connection environment) with the device private key, and encrypting it with the verification server public key. It has become. As described above, when the device 7 is connected to the network 10, it acquires its own device connection information (connection information acquisition means) and transmits it to the verification server 5 (connection information transmission means). On the other hand, the verification server 5 includes connection information receiving means for receiving this. The verification request information includes a digital signature obtained by encrypting a digest (predetermined information) with a device secret key, and functions as signature information. Thus, the device 7 has a signature information transmission unit], and [¶81, Next, the device 7 reads its own device ID from the EEPROM 25 and creates a verification request information by digitally signing the device ID together with the device connection information and environment information collected earlier with the device private key. Then, the device 7 creates the encrypted verification request information by encrypting the verification request information with the verification server public key. Next, the device 7 connects to the verification server 5 using the verification server connection information, transmits the encrypted verification request information to the verification server 5, and requests the verification server 5 for its own verification (step 55)]; and
register product history data of the product device in association with the UID of the product device [¶¶73-75, The CPU 21 stores the generated device secret key in a predetermined area in the EEPROM 25. Then, the CPU 21 reads out device unique information unique to the device 7 such as the device ID and the MAC address of the tamper resistant unit 20 stored in advance in the EEPROM 25 and transmits these to the device registration server 6 together with the device public key (step). 10). The verification server 5 receives a device public key, device unique information, and the like from the device 7 and transmits them to the CA 3 (step 13). The CA 3 receives the device public key and device specific information of the device 7 from the device registration server 6 (step 15). Then, CA3 extracts the device ID from the device unique information. For example, “Device public key XXX is the device public key of device ID XXX. The prover is CA3”, A message including a device ID, a prover, and other certification date and time is generated. Furthermore, CA3 generates a digest from the message and digitally signs it by encrypting it with a CA private key…], and [¶¶82-83, The verification server 5 receives the verification information encrypted from the device 7 and decrypts it with the verification server private key stored in advance. Since the verification server private key has only the verification server 5, the encrypted verification information cannot be decrypted even if the verification information is passed on to others. Next, the verification server 5 searches the device registration database for the device ID included in the verification request information, and acquires the device public key associated with the device ID. Next, the verification server 5 confirms the digital signature using the device public key and confirms the authenticity of the verification information (step 60). More specifically, the verification server 5 generates a digest from the verification request information, decrypts the digital signature with the device public key, restores the digest, and confirms that the verification request information is authentic when the two match. If they do not match, the verification server 5 transmits an error message to the device 7 because the device 7 is not legitimate]; and
and read, in case of receiving a use start request from the product device for which the authentication has succeeded, the product history data registered in association with the UID by using at least the UID included in the public key certificate of the product device, and output information regarding the product history data [¶89, Upon receiving the customer server information from the customer server 4, the device 7 verifies the digital signature of the customer server public key certificate using the CA public key, and confirms the legitimacy of the customer server 4. The device 7 stores customer server connection information in the EEPROM 25 and uses it when connecting to the customer server 4. Thereafter, the customer server 4 and the device 7 can communicate (step 95), and the device 7 can transmit the measurement value to the customer server 4. At this time, the device 7 prevents the leakage of the measured value by encrypting the measured value with the customer server public key and transmitting it to the customer server 4], and [¶¶122-128]; and
wherein in a case of receiving a certificate issuance request from a Supply Chain Management (SCM) device related to a supply chain of the product device, the at least one processor is further configured to execute the instructions to generate a public key certificate including at least a public key of the SCM device, and set a secret key that is paired with the public key of the SCM device in an HSM of the SCM device [ ¶¶12-18, ¶¶54-56, [¶¶54-56, Next, the entire configuration of the procedure from pre-shipment processing to installation of the device 7 will be described with reference to FIG. In the figure, the order of the procedures is shown in parentheses, and the description will be made in accordance with this order. The procedure (1) to the procedure (4) are operations performed before the installation of the device 7 (preferably before shipping to the customer). (1) (Generation of Asymmetric Encryption Key Pair of Device Private Key and Device Public Key) When the hardware of the device 7 is completed, the worker in charge operates the device 7 to execute the asymmetric encryption key generation program and 20, the CPU 21 is caused to generate a device private key / device public key pair (asymmetric encryption key generation means). The device 7 stores the generated device secret key in a predetermined area of the EEPROM 25 (secret key storage means). (2) (Transmission of device public key) The device 7 is connected to the device registration server 6 in charge of the device 7 by the person in charge of work, and transmits the generated device public key, device unique information, etc. to the device registration server 6. (Public key providing means). Here, the device unique information includes information unique to the device 7 such as the device ID and the MAC address of the tamper resistant part( equated to HSM). The device registration server 6 receives these pieces of information from the device 7 (public key acquisition means). Then, the device registration server 6 transmits a device public key, device ID, and the like to the CA 3 and requests the CA 3 to issue a device public key certificate (public key certificate issue request means). (3) (Write device certificate) The CA 3 creates a device certificate from the device public key from the device registration server 6. The CA 3 adds the verification server public key certificate of the verification server 5 to the device certificate, creates a device certificate, and transmits the device certificate to the device registration server 6. Upon receiving the device certificate from the CA 3, the device registration server 6 adds verification server connection information to the device certificate and transmits it to the device 7. The device 7 receives the device certificate from the device registration server 6 and stores it in the tamper resistant unit 20. As described above, the device certificate includes a device public key certificate, verification server connection information, a verification server public key certificate, and the like], and [¶73, The CPU 21 stores the generated device secret key in a predetermined area in the EEPROM 25. Then, the CPU 21 reads out device unique information unique to the device 7 such as the device ID and the MAC address of the tamper resistant unit 20 stored in advance in the EEPROM 25 and transmits these to the device registration server 6 together with the device public key (step). 10). The verification server 5 receives a device public key, device unique information, and the like from the device 7 and transmits them to the CA 3 (step 13)], and [¶75]; and
in a case of receiving, from the SCM device, an authentication request including the public key certificate and authentication data to which a signature for the SCM device is attached, the at least one processor is further configured to execute the instructions to; verify the public key certificate included in the authentication request by using the CA public key; verify whether the authentication data is signed with the secret key that is paired with the public key by using the public key in the public key certificate included in the authentication request [¶¶59-60, The verification server public key certificate is a public key certificate obtained by digitally signing the verification server public key with the CA3 private key. Since the verification server public key certificate includes the verification server public key, the device 7 acquires the verification server public key. The device 7 can verify the legitimacy of the device public key certificate and the verification server public key certificate using a CA public key incorporated in advance. The device registration server 6 according to the present embodiment includes the verification server public key certificate included in the device certificate received from the CA 3 and transmits the device certificate to the device 7. However, the present invention is not limited to this, and the device certificate received from the CA 3 The verification server connection information can be separately transmitted to the device 7. (Registration Request for Device 7) The device registration server 6 can obtain a device public key certificate when the CA 3 issues a device certificate to the device 7. Then, the device registration server 6 creates registration request information including the device public key certificate obtained in this way, device specific information (device ID), and the like, and transmits the registration request information to the verification server 5. Request registration of the device 7 (public key certificate transmission means). The verification server 5 receives the registration request information from the device registration server 6 and updates the device registration database using this information]; and [¶¶77-78, On the other hand, after transmitting the device certificate to the device 7, the device registration server 6 transmits registration request information including a device ID, a device public key certificate, and the like to the verification server 5 to the device registration database of the device 7. Registration request is made (step 40). At this time, the device registration server 6 digitally signs the registration request information with the device registration server private key and transmits it to the verification server 5 so that the verification server 5 can confirm the legitimacy of the verification request information with the device registration server public key. To verify the public key certificate included in the authentication request by using a CA public key that is paired with a CA secret key used for the signature by the certificate authority. [¶78, In the verification server 5, the device registration server 6 digitally signs the registration request information, and the verification server 5 confirms this to confirm the legitimacy of the registration request information. The verification server 5 confirms the legitimacy of the device public key certificate using the device registration server public key and stores the correspondence between the customer server connection information, the device ID, and the device public key included in the registration request information in the device registration database. Register (step 45)]]; and [ ¶64, The verification request information is obtained by digitally signing the device ID, device connection information for connecting from the customer server 4 to the device 7, environment information (information on the network connection environment) with the device private key, and encrypting it with the verification server public key…when the device 7 is connected to the network 10, it acquires its own device connection information (connection information acquisition means) and transmits it to the verification server 5 (connection information transmission means). On the other hand, the verification server 5 includes connection information receiving means for receiving this. The verification request information includes a digital signature obtained by encrypting a digest (predetermined information) with a device secret key, and functions as signature information. Thus, the device 7 has a signature information transmission unit], and [¶¶80-82, Next, with reference to the flowchart of FIG. 7, a procedure until the device 7 is installed at the installation site and connected to the customer server 4 via the network 10 will be described. When the device 7 is shipped to the customer, it is transported to the installation location based on the customer's business plan. The person in charge of installation goes to the site, connects the device 7 to the network 10 and starts the verification request program. Then, the device 7 collects device connection information such as its own IP address on the network 10 and environmental information such as being connected via a router (step 50). Next, the device 7 reads its own device ID from the EEPROM 25 and creates a verification request information by digitally signing the device ID together with the device connection information and environment information collected earlier with the device private key. Then, the device 7 creates the encrypted verification request information by encrypting the verification request information with the verification server public key. Next, the device 7 connects to the verification server 5 using the verification server connection information, transmits the encrypted verification request information to the verification server 5, and requests the verification server 5 for its own verification (step 55).The verification server 5 receives the verification information encrypted from the device 7 and decrypts it with the verification server private key stored in advance. Since the verification server private key has only the verification server 5, the encrypted verification information cannot be decrypted even if the verification information is passed on to others. Next, the verification server 5 searches the device registration database for the device ID included in the verification request information and acquires the device public key associated with the device ID.]; and
and determine that authentication has succeeded in a case where the verification of the public key certificate included in the authentication request has succeeded and the verification of the signature attached to the authentication data has succeeded
[0017] The verification server 5 is a server for verifying the legitimacy of the device 7 and preventing unauthorized use of the device 7 such as impersonation when the device 7 is installed in the network 10 and connected to the customer server 4. After the verification server 5 verifies that the device 7 is a legitimate product, the customer server 4 connects to the device 7], and [¶64, The verification request information is obtained by digitally signing the device ID, device connection information for connecting from the customer server 4 to the device 7, environment information (information on the network connection environment) with the device private key, and encrypting it with the verification server public key. It has become. As described above, when the device 7 is connected to the network 10, it acquires its own device connection information (connection information acquisition means) and transmits it to the verification server 5 (connection information transmission means). On the other hand, the verification server 5 includes connection information receiving means for receiving this. The verification request information includes a digital signature obtained by encrypting a digest (predetermined information) with a device secret key, and functions as signature information. Thus, the device 7 has a signature information transmission unit], and [¶81, Next, the device 7 reads its own device ID from the EEPROM 25 and creates a verification request information by digitally signing the device ID together with the device connection information and environment information collected earlier with the device private key. Then, the device 7 creates the encrypted verification request information by encrypting the verification request information with the verification server public key. Next, the device 7 connects to the verification server 5 using the verification server connection information, transmits the encrypted verification request information to the verification server 5, and requests the verification server 5 for its own verification (step 55)].
in a case of receiving at least one substitute ID for specifying the UID of the product device and product history data of the product device from the SCM device for which the authentication has succeeded, the at least one processor is further configured to execute the instructions to register the product history data in association with the at least one substitute ID; and in the case of receiving the use start request from the product device for which the authentication has succeeded, the at least one processor is further configured to execute the instructions to read the product history data registered in association with the at least one substitute ID for specifying the UID in addition to the product history data registered in association with the UID of the product device[¶47] “Device ID” is ID information assigned to each of the devices 7, 7, And for example, a manufacturing serial number can be used. The “device public key” is a device public key corresponding to the device private key stored for each device 7. The device public key is obtained from the device public key certificate transmitted by the CA 3 to the verification server 5], and [¶¶73-75, The CPU 21 stores the generated device secret key in a predetermined area in the EEPROM 25. Then, the CPU 21 reads out device unique information unique to the device 7 such as the device ID and the MAC address of the tamper resistant unit 20 stored in advance in the EEPROM 25 and transmits these to the device registration server 6 together with the device public key (step). 10). The verification server 5 receives a device public key, device unique information, and the like from the device 7 and transmits them to the CA 3 (step 13). The CA 3 receives the device public key and device specific information of the device 7 from the device registration server 6 (step 15). Then, CA3 extracts the device ID from the device unique information. For example, “Device public key XXX is the device public key of device ID XXX. The prover is CA3”, A message including a device ID, a prover, and other certification date and time is generated. Furthermore, CA3 generates a digest from the message and digitally signs it by encrypting it with a CA private key…], and [¶¶82-83, The verification server 5 receives the verification information encrypted from the device 7 and decrypts it with the verification server private key stored in advance. Since the verification server private key has only the verification server 5, the encrypted verification information cannot be decrypted even if the verification information is passed on to others. Next, the verification server 5 searches the device registration database for the device ID included in the verification request information, and acquires the device public key associated with the device ID. Next, the verification server 5 confirms the digital signature using the device public key and confirms the authenticity of the verification information (step 60). More specifically, the verification server 5 generates a digest from the verification request information, decrypts the digital signature with the device public key, restores the digest, and confirms that the verification request information is authentic when the two match. If they do not match, the verification server 5 transmits an error message to the device 7 because the device 7 is not legitimate].
Examiner Note: as mentioned above in various paragraphs the device ID mentioned as : serial number, Device ID, MAC address tamper resistant unit, public key of the device , any of device description can be interchangeably( substituted) for registering the device with device registration server.
Masakazu does not explicitly disclose, however, Tadahiko discloses a hardware security module (HSM) [Moreover, to employ a HSM as anti-tampering hardware, and for an authentication request to include an electronic signature and a public-key certificate [ ¶¶17-21, 33].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Masakazu by incorporating “hardware security module (HSM)”, as taught by Tadahiko. One could have been motivated to do so in order for having tamper resistance (physical attack resistance) and realizes high security performance by physical security having tamper resistance. [ Tadahiko, ¶17].
Regarding claim 2, Masakazu wherein the product history data to be registered contain at least one of inspection data, inventory management data, distribution management data, verification data at a start of operation, maintenance data, and discard data of the product device [ ¶17, after the verification server 5 verifies that the device 7 is a legitimate product, the customer server 4 connects to the device 7], and [¶33, The measurement device unit 34 is a device that performs measurement, and outputs a measurement value to the CPU 29 as digital information when requested by the CPU 29. For example, in addition to measuring the amount of gas, water, and electricity used, the measuring device unit 34 performs temperature measurement, humidity measurement, water quality measurement, and air pollution measurement, and is installed in a vending machine for inventory and sales. Various things, such as what measures a situation etc., are employable].
Regarding claim 3, Masakazu discloses, wherein the at least one processor is further configured to execute the instructions to output a result of verifying whether the read product history data indicate a normal history as the output information [¶24, a pair of a device public key and a device private key is generated, device authentication of the device 7 is performed by communicating with the verification server 5, and information is encrypted / decrypted when communicating with the customer server 4]; and [¶67, (9) (Notification of customer server information) After the customer server 4 receives the verification result from the verification server 5 (verification result receiving means) and confirms that the device 7 is verified as an authentic product, Connect to the device 7 (connecting means) and send the customer server information to the customer server 4. The customer server information includes customer server public key certificate, customer server connection information for the device 7 to connect to the customer server 4 via the network 10, and the like]; and [¶89, Upon receiving the customer server information from the customer server 4, the device 7 verifies the digital signature of the customer server public key certificate using the CA public key, and confirms the legitimacy of the customer server 4. The device 7 stores customer server connection information in the EEPROM 25 and uses it when connecting to the customer server 4. Thereafter, the customer server 4 and the device 7 can communicate (step 95), and the device 7 can transmit the measurement value to the customer server 4. At this time, the device 7 prevents the leakage of the measured value by encrypting the measured value with the customer server public key and transmitting it to the customer server 4], and [¶¶122-128].
Regarding claim 4, Masakazu discloses, wherein in a case where the product history data are received from the product device for which the authentication has succeeded, the at least one processor is further configured to execute the instructions to register the product history data in association with the UID of the product device[ ¶18, The device registration server 6 is a server that mediates between the device 7 and the CA 3 when the device 7 issues a device public key certificate or the like to the CA 3 and registers the device 7 in the verification server 5…]; and [¶45, Next, the device registration database will be described. The device registration database is a database in which devices 7 requiring verification are registered in advance, and an example of a logical configuration thereof is shown in FIG. As shown in the figure, the device registration database includes items such as “customer ID”, “customer server connection information”, “device ID”, “device public key”]; and [¶62, (5) (Shipment) The device 7 is registered with the verification server 5 and then shipped to the customer. The device 7 is under customer control after being shipped]; and [¶¶78-79, In the verification server 5, the device registration server 6 digitally signs the registration request information, and the verification server 5 confirms this to confirm the legitimacy of the registration request information. The verification server 5 confirms the legitimacy of the device public key certificate using the device registration server public key and stores the correspondence between the customer server connection information, the device ID, and the device public key included in the registration request information in the device registration database. Register (step 45). As described above, the pre-shipment processing of the device 7 is completed, and the device 7 in which the device secret key and the verification server connection information are embedded in the tamper resistant unit 20 is shipped to the customer. On the other hand, the verification server 5 stores information about the device 7 in preparation for the verification of the device 7].
Regarding claim 7, Masakazu discloses, wherein the at least one substitute ID includes at least one of a model number, a serial number, and a distribution slip number of the product device, or a combination thereof [¶19, The customer server 4 is operated by the customer who purchased the device 7. Since the sales company has information on the serial number of the device 7 and the customer to whom the device 7 is delivered, the device verification service is provided to the customer by operating the parent CA2, CA3, the verification server 5, and the device registration server 6. Is in a good position to provide]; and
[¶47, “Device ID” is ID information assigned to each of the devices 7, 7..., And for example, a manufacturing serial number can be used. The “device public key” is a device public key corresponding to the device private key stored for each device 7. The device public key is obtained from the device public key certificate transmitted by the CA 3 to the verification server 5], and [ ¶122].
Regarding claim 10, Masakazu discloses, wherein the at least one processor is further configured to execute the instructions to transmit the output information to a terminal used by a user of the product device [¶89, Upon receiving the customer server information from the customer server 4, the device 7 verifies the digital signature of the customer server public key certificate using the CA public key and confirms the legitimacy of the customer server 4. The device 7 stores customer server connection information in the EEPROM 25 and uses it when connecting to the customer server 4. Thereafter, the customer server 4 and the device 7 can communicate (step 95), and the device 7 can transmit the measurement value to the customer server 4. At this time, the device 7 prevents the leakage of the measured value by encrypting the measured value with the customer server public key and transmitting it to the customer server 4], and [¶¶122-128].
Regarding claims 12, and 13, these claims are interpreted and rejected for the same rational set forth in claim 1.
Claims 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Uehata Masakazu (JP 2007-215103), hereinafter, “Masakazu” (filed in IDS 05/14/2024), and in view of Miyazawa Tadahiko (JP 2005-333596), hereinafter, “Tadahiko” (filed in IDS 05/14/2024) and further in view of Stone (US2018/0225651).
Regarding claim 8, Masakazu, and Tadahiko do not explicitly disclose, however, Stone discloses, wherein when registering the product history data, the at least one processor is further configured to execute the instructions to store a hash value of the product history data in a blockchain [ ¶¶56, 60, 62 discloses managing a maintenance record for an aircraft via blockchain].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Masakazu, and Tadahiko by incorporating “blockchain with security module”, as taught by Stone. One could have been motivated to do so in order to verify and seal every block of information transmitted over the network, to ensure that information on the network cannot be changed and is saved in a way that is transparent to all users so that the integrity of the information can be maintained. With the integrity of the information on the network assured, companies can access, use, and distribute information while being sure that the information is authentic and is the same information accessible to all other users [ Stone, ¶36].
Regarding claim 8, Masakazu, and Tadahiko do not explicitly disclose, however, Stone discloses, wherein the at least one processor is further configured to execute the instructions to output the output information in which a result of verifying a block corresponding to the read product history data in the blockchain is included.
[ ¶¶36, 56, 60, 62 discloses managing a maintenance record for an aircraft via blockchain].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Masakazu, and Tadahiko by incorporating “blockchain with security module”, as taught by Stone. One could have been motivated to do so in order to verify and seal every block of information transmitted over the network, to ensure that information on the network cannot be changed and is saved in a way that is transparent to all users so that the integrity of the information can be maintained. With the integrity of the information on the network assured, companies can access, use, and distribute information while being sure that the information is authentic and is the same information accessible to all other users [ Stone, ¶36].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See submitted 892 for more relevant references.
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 SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496