Prosecution Insights
Last updated: October 23, 2026
Application No. 19/169,473

INFORMATION PROCESSING METHOD, INFORMATION PROCESSING DEVICE, AND INFORMATION PROCESSING SYSTEM

Non-Final OA §103
Filed
Apr 03, 2025
Priority
Oct 19, 2022 — provisional 63/417,391 +1 more
Examiner
ZOUBAIR, NOURA
Art Unit
2434
Tech Center
2400 — Computer Networks
Assignee
Panasonic Holdings Corporation
OA Round
1 (Non-Final)
73%
Grant Probability
Favorable
1-2
OA Rounds
1y 1m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 73% — above average
73%
Career Allowance Rate
268 granted / 368 resolved
+14.8% vs TC avg
Strong +62% interview lift
Without
With
+62.3%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
21 currently pending
Career history
393
Total Applications
across all art units

Statute-Specific Performance

§101
8.3%
-31.7% vs TC avg
§103
54.6%
+14.6% vs TC avg
§102
7.2%
-32.8% vs TC avg
§112
18.1%
-21.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 368 resolved cases

Office Action

§103
DETAILED ACTION Claims 1-20 are presented for examination. 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 . Claim Interpretation The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “an obtainer that obtains…..” in claim 19. Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim Rejections - 35 USC § 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. Claims 1-8, 17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Park et al (US Pub.No.2020/0053081). Re Claim 1. Park discloses an information processing method that is performed by a device, the information processing method comprising: obtaining an owner address and first authority information, the owner address being an address of an owner of the device on a distributed ledger (i.e. The user terminal may transmit the unique address value of the user terminal and the address value of the smart contract to the target device by using any one of a wireless communication scheme such as a Quick Response (QR) code, Near Field Communication (NFC), or Bluetooth (Bluetooth). However, the communication scheme is not limited thereto. Here, the unique address value of the user terminal and the address value of the smart contract may be referred to as authentication information) [Park, para.0058], the first authority information including information regarding authority of use by the owner of the device (i.e. the authentication management server may confirm a valid period or an authority based on the attribute value of the token and the propagated transaction, and may perform the user authentication by comparing information on a user having ownership of the token with user information included in the transaction) [Park, para.0061-0062], (i.e. When it is determined that the token is valid, the authentication management server may perform user authentication based on ownership information of the token and the information included in the transaction (S760). When the user authentication is successful, the authentication management server may transmit information on the authentication result to the target device (S770). The user may use the target device for which the information on the authentication result is received after performing the user authentication) [Park, 0092]; and controlling a distributed ledger system to issue a first non-fungible token (NFT) including the first authority information to the owner address (i.e. the token generation unit 410 may determine whether the request conforms to the token policy information of the policy management unit 420 which will be described later, based on the parameters, the authentication information, and the token generation request information included in the token generation request transaction. When the request conforms to the token policy information, a token may be generated. Here, the authentication information may include the unique value of the user terminal or the unique address value of the user wallet……… the policy information may include affiliation information of the user for whom a token is allowed to be generated) [Park, para.0071-0072], (i.e. the authentication management server may specify or determine the smart contract by using the information included in the transaction, and generate a non-fungible token based on a policy of the smart contract) [Park, 0054]. Park does not disclose all the above in one embodiment, however it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the embodiments of Park in order to provide high security [Park, para.0032] and also since such combination is suggested by Park: it should be understood that various changes, substitutions and alterations may be made herein without departing from the scope of the present disclosure [Park, 0097]. This motivation applies to the dependent claims. Re Claim 2. Park discloses the information processing method according to claim 1, further comprising: in controlling one function by the device, obtaining the owner address; obtaining a first storage address that is an address on the distributed ledger at which the first NFT is stored (i.e. The user terminal may transmit the unique address value of the user terminal and the address value of the smart contract to the target device) [Park, para.0058]; determining whether there is a match between the owner address and the first storage address; and when it is determined that there is a match between the owner address and the first storage address, controlling the one function (i.e. the authentication management server may check validity of a token for the smart contract based on the address value of the smart contract included in the transaction, and verify ownership of the token. That is, the authentication management server may confirm a valid period or an authority based on the attribute value of the token and the propagated transaction, and may perform the user authentication by comparing information on a user having ownership of the token with user information included in the transaction………….. When the user authentication is successful, the authentication management server may transmit information on the authentication result to the target device (S770). The user may use the target device for which the information on the authentication result is received after performing the user authentication) [Park, para.0061,0092]. Re Claim 3. Park discloses the information processing method according to claim 1, further comprising: when the owner is to grant a user authority to use the device, obtaining second authority information including information regarding authority of use by the user of the device (i.e. other request transactions such as token verification, token delegation, token ownership sharing, and token ownership transfer may also be propagated to the block chain network) [Park, para.0052, Note: at least token delegation and token sharing teaches granting another user authority to use]; and controlling the distributed ledger system to issue a second NFT including the second authority information to a user address that is an address of the user on the distributed ledger (i.e. when receiving a transaction such as token delegation and token ownership sharing, the token management unit 430 may modify ownership information of the token by reflecting the corresponding information in the token) [Park, para.0073, Note: modifying a token is interpreted as issuing a second token]. Re Claim 4. Park discloses the information processing method according to claim 3, comprising: in controlling one function by the device, obtaining the user address; obtaining a second storage address that is an address on the distributed ledger at which the second NFT is stored; determining whether there is a match between the user address and the second storage address; and when it is determined that there is a match between the user address and the second storage address, controlling the one function (i.e. The user terminal may transmit the unique address value of the user terminal and the address value of the smart contract to the target device) [Park, para.0058], (i.e. the authentication management server may check validity of a token for the smart contract based on the address value of the smart contract included in the transaction, and verify ownership of the token. That is, the authentication management server may confirm a valid period or an authority based on the attribute value of the token and the propagated transaction, and may perform the user authentication by comparing information on a user having ownership of the token with user information included in the transaction………….. When the user authentication is successful, the authentication management server may transmit information on the authentication result to the target device (S770). The user may use the target device for which the information on the authentication result is received after performing the user authentication) [Park, para.0061,0092]. Re Claim 5. Park discloses the information processing method according to claim 3, wherein in the controlling of the distributed ledger system to issue the second NFT, the distributed ledger system is controlled to issue the second NFT according to a smart contract (i.e. The authentication management unit 310 may manage or store parameters and an address value of a smart contract, and may perform token issuance or user authentication by using them together with a unique value of the user terminal or a unique address value of a user wallet which are managed or stored by the wallet management unit 320 to be described later. In addition, the authentication management unit 310 may perform token verification, token delegation, token ownership sharing, token ownership transfer, or the like by using the parameters, the address value of the smart contract, and at least one of the unique value of the user terminal and the unique address value of the user wallet in the wallet management unit) [Park, para.0067]. Re Claims 6-8. These claims recite features similar to those in claims 3-5 with respect to a secondary user and a third token, therefore they are rejected in a similar manner. Although Park does not explicitly disclose delegation or sharing with multiple users, however it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Park to include secondary users since it is an expected result that a user may need to share a device or vehicle with multiple users such as friends or family members. Re Claim 17. Park discloses the information processing method according to claim 1, wherein the address on the distributed ledger is an address calculated in advance using a private key of the owner (i.e. the authentication information may include at least one of an address value of a smart contract used for the user authentication, a unique address value of the user terminal, and user information, but is not limited thereto. Also, the authentication information and the parameters may be previously embedded in the user terminal, or additionally stored for the user authentication… user terminal may store and manage a private key used when creating the transaction) [Park, para.0053]. Re Claim 19. This claim recites features similar to those in Claim 1, therefore it is rejected in a similar manner. Re Claim 20. In a manner similar to the rejection of Claim 1, Park discloses an information processing system comprising: the information processing device according to claim 19; an information processing terminal held by the owner; and the distributed ledger system. Claims 9-12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Park in view of Jarvis et al (US Pub.No.2021/0327189). Re Claim 9. Park discloses the information processing method according to claim 1, Park does not explicitly disclose whereas Jarvis does: further comprising: performing control to store, into the distributed ledger (i.e. The distributed ledger system 14 can interact with the user's wallet as well as third party systems to register users and allow user access to the vehicle or other restricted space) [Jarvis, para.0041] (i.e. The credential-based registration/access system 180 (system 180) also includes a vehicle system 184 including a vehicle wallet 187 and a vehicle application 188 that together with the user device 12a registers and verifies users, e.g., employees of an entity controlling the physical premises or logical structures, by use of the distributed ledger 14 and the distributed network server computers 190) [Jarvis, para.0097], revocation information with which the private key of the owner is revoked (i.e. The user's wallet 13a requests 706 from a wallet 701 in the reader, e.g., application 188, a vehicle certificate, OCSP and vehicle UUID,….. The application has the vehicle certificate, the vehicle UUID, and a revocation status, e.g., such as via the “Online Certificate Status Protocol” (OCSP)…………… the wallet needs to verify that the certificate has not been revoked. The wallet can do this verification a number of ways as discussed above, e.g. directly through an OCSP) [Jarvis, para.0125-0131, Fig.11, Note: the application retrieves the OCSP from the ledger where the registration/revocation status is stored] and to which a digital signature using the private key of the owner has been attached (i.e. Since the mobile wallet knows the company's public key, the mobile wallet can trust that any packets signed by the company are valid and can be trusted. When the mobile wallet 13a accesses a vehicle, the vehicle provides its specific public key to the mobile device 12a (wallet 13a). Authenticity of the vehicle is determined by the wallet 13a through verification 608 of the vehicle's certificate………………….. The generated tokens, as above, are signed by the token producer's private key, so that door app in possession of the producer's public key is able to verify that the token is legitimate) [Jarvis, para.0113-0115], It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Park with Jarvis because the access control system can utilize a distributed ledger to simply retrieve and validate user information. This is beneficial as by utilizing a distributed ledger, the access control system can validate the credentials of a user more efficiently by reducing the number of intermediary information sources (e.g., human resources databases). The reduction of intermediaries reduces the amount of computational resources needed and reduces the complexity of data retrieval [Jarvis, para.0026]. Jarvis does not explicitly teach: when a private key of the owner is leaked, however it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Jarvis to include when a private key of the owner is leaked, because Jarvis teaches maintaining a revocation status and it is expected that, when a key is leaked/compromised, it should be revoked in order to prevent fraudulent use of the key. Re Claim 10. Park in view of Jarvis discloses the information processing method according to claim 9, Park in view of Jarvis discloses: further comprising: in controlling one function by the device, obtaining the owner address; obtaining a first storage address that is an address on the distributed ledger at which the first NFT is stored; determining whether the revocation information for the private key of the owner is stored in the distributed ledger (i.e. The verification process has the wallet 13a determine whether the vehicle certificate was signed by the company. If the certificate was signed by the company, then the wallet 13a verifies that the vehicle certificate and the signature match because the wallet has the company's public key and the wallet can verify the signature. If the signature is valid, then the wallet 13a knows that the vehicle certificate is authentic…………… Although the certificate is authentic, the wallet needs to verify that the certificate has not been revoked) [Jarvis, para.0130-0131], [Park, as in claim 1, teaches NFT]; and when it is determined that the revocation information for the private key of the owner is stored in the distributed ledger, prohibiting controlling the one function even when it is determined that there is a match between the owner address and the first storage address (i.e. the user's wallet 13a verifying the vehicle credentials, e.g., vehicle certificate, a revocation status and vehicle UUID, the user's wallet sends 710 a JWT message to the reader. The JWT message follows the so called JSON Web Token (JWT) format discussed above. The generated tokens, as above, are signed by the token producer's private key, so that door kiosk app in possession of the producer's public key is able to verify that the token is legitimate. The claims are used to pass identity of authenticated users between an identity provider and a service provider. The tokens can be authenticated and encrypted. Upon verification of the JWT message by the servers, the servers cause the reader to send an access status message that is received 712 by the wallet 13a, allowing or denying access) [Jarvis, para.0132, Note: it is implied if status is revoked, the access is denied]. The same motivation to modify with Jarvis, as in claim 9, applies. Re Claim 11. Park discloses the information processing method according to claim 1, Park does not explicitly disclose whereas Jarvis does: wherein the first authority information includes information indicating a limitation imposed by the owner on use of the device (i.e. The IAM system is a specific implementation of a cloud based service that validates the driver's identity and whether the driver is authorized to drive the vehicle. This could be used, as one example, when employees of a company can only use the vehicle during specified hours on specified days and also determines the driver's identity, if the driver has the requisite training to operate the class of vehicle) [Jarvis, para.0049]. The same motivation to modify with Jarvis, as in claim 9, applies. Re Claim 12. Park in view of Jarvis discloses the information processing method according to claim 11, Jarvis discloses: wherein the first authority information includes a validity period of the first NFT (i.e. The JWT also includes an “exp” attribute that sets the expiration time of the token, and a “jti” attribute, i.e., and ID that can be used by the Reader or which can be used by an upstream system to ensure that the token can be used only once during the validity time) [Jarvis, para.0117], [Park, as in claim 1, teaches NFT]. The same motivation to modify with Jarvis, as in claim 9, applies. Re Claim 14. Park in view of Jarvis discloses the information processing method according to claim 11, wherein the first authority information includes function control approval and disapproval information (i.e. configured to determine whether a given user has privileges or authorization to enter and operate the vehicle……………..The application on the vehicle computer receives 19d from the IAM system a decision regarding validation of the received credentials of the driver. If acceptable 19e, the application in one embodiment will engage 19f with the ignition system of the vehicle to allow the driver to start the vehicle (shown as a dashed line). If not acceptable 19g the application will engage with the ignition system of the vehicle to block starting of the vehicle) [Jarvis, para.0048-0050] determined for each device (i.e. The user device 12a and wallet 13a will be registered with the access control system and verified for use with the access control system. The registration allows a specific vehicle to be registered by the mobile credential) [Jarvis, para.0096]. The same motivation to modify with Jarvis, as in claim 9, applies. Claim 13 is rejected under 35 U.S.C.103 as being unpatentable over Park in view of Jarvis in view of Jakobsson (US Pub.No.2023/0086191). Re Claim 13. Park in view of Jarvis discloses the information processing method according to claim 11, Park in view of Jarvis does not explicitly disclose whereas Jakobsson does: wherein the first authority information includes information indicating presence or absence of authority to issue a second NFT including second authority information including information regarding authority of use by a user of the device (i.e. can generate access right tokens that provide users with access to NFTs. In particular, a first user (e.g., user with ownership rights) associated with a particular NFT can indicate that a second user should be given access rights to the particular NFT, and an NFT security platform can generate an access rights token and convey the access right token to the second user. The access right token may be a derived token that references the particular NFT and which associates the second user with an access right to the particular NFT) [Jakobsson, para.0357]. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Park in view of Jarvis with Jakobsson in order to facilitate transactions between users: access right tokens can be generated and provided to users based on transactions between users. In particular, a first user (e.g., owner) of an NFT may enter into a transaction (e.g., sell, license, among others) with a second user, and thus the NFT security platform can generate and provide the second user with an access right token that can provide the second user with access to the particular NFT [Jakobsson, para.0359]. Claims 15-16 and 18 are rejected under 35 U.S.C.103 as being unpatentable over Park in view of Jakobsson (US Pub.No.2023/0086191). Re Claim 15. Park discloses the information processing method according to claim 1, Park does not explicitly disclose whereas Jakobsson does further comprising: in transferring the first NFT by the distributed ledger system, controlling the distributed ledger system to transfer value information as remuneration for the first NFT (i.e. the smart contracts 108 underlying the NFTs can cause payments of residual royalties 116 when users engage in specific transactions involving NFTs (e.g. transfer of ownership of the NFT)) [Park, para.0140]. The same motivation to modify with Jakobsson, as in claim 13, applies. Re Claim 16. Park in view of Jakobsson discloses the information processing method according to claim 15, Jakobsson further discloses: wherein in the controlling of the distributed ledger system to transfer the value information, the distributed ledger system is controlled according to a smart contract to transfer the value information (i.e. confirming that transactions written to one or more of the immutable ledgers are consistent with the smart contracts 108 underlying the NFTs…………smart contracts 108 underlying the NFTs can cause payments of residual royalties) [Park, para.0139-0140]. The same motivation to modify with Jakobsson, as in claim 13, applies. Re Claim 18. Park in view of Jakobsson discloses the information processing method according to claim 15, Park further discloses wherein the distributed ledger system is controlled using the private key as a digital key (i.e. The user terminal may store and manage a private key used when creating the transaction) [Park, 0053], Park does not explicitly disclose: defined by the Car Connectivity Consortium (CCC), however it would have been obvious to a person having ordinary skill in the art to modify Park to include defined by the Car Connectivity Consortium, because Park teaches that the device may be a vehicle (i.e. according to the exemplary embodiments of the present disclosure, through the delegation of the token, a block chain can be applied to authentication of a vehicle key) [Park, para.0032], and therefore it is an expected result to develop a system that complies with a particular car standard such as the CCC. Prior art made of record, however not relied upon, includes: Smith et al (US Pub.No.2020/0403808) describes a method of issuing one or more authorizations in accordance with one embodiment is depicted in FIG. 8 and generally designated 800. The method 800 includes a variety of steps, including Step 801) a user 10 with rights to issue an authorization sending an authorization issue request using a device 110 (with the rights) to a receiving user's account and/or device 110 for a particular SCM 120, Step 802) the receiving user accepting the authorization issue request using their device 110 (e.g., any device 110 associated with their user account, a specific device 110, and Step 803) an owner device 110 for the SCM 120 accepting the change to the ACP 400 resulting from the issued authorization [Smith, para.0217]. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to NOURA ZOUBAIR whose telephone number is (571)270-7285. The examiner can normally be reached Monday - Friday. 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, ALI SHAYANFAR can be reached at 571-270-1050. 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. /NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Read full office action

Prosecution Timeline

Apr 03, 2025
Application Filed
Oct 02, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12771671
SYSTEM AND METHOD FOR DETECTING POTENTIALLY HARMFUL DATA
4y 1m to grant Granted Oct 20, 2026
Patent 12771728
SYSTEMS AND METHODS FOR DETERMINING, MANAGING, AND SECURING DATA IN FEDERATED DATA CHANNELS
2y 7m to grant Granted Oct 20, 2026
Patent 12749126
USER INTERFACE LOG VALIDATION VIA BLOCKCHAIN SYSTEM AND METHODS
2y 0m to grant Granted Sep 29, 2026
Patent 12726333
HARDWARE-BASED KEY GENERATION AND STORAGE FOR CRYPTOGRAPHIC FUNCTION
4y 1m to grant Granted Sep 01, 2026
Patent 12682022
SYSTEM, METHOD, AND COMPUTER PROGRAM PRODUCT FOR WORKSPACE CREATION IN EMBEDDED APPLICATIONS
3y 6m to grant Granted Jul 14, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
73%
Grant Probability
99%
With Interview (+62.3%)
2y 8m (~1y 1m remaining)
Median Time to Grant
Low
PTA Risk
Based on 368 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month