Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This is in response to the amendments filed 08/10/2026. Claims 1, 2, 6,13, 17 and 18 have been amended. Claims 19 and 20 have been added. Claims 1-20 are pending and have been considered below.
Priority
19066505 filed 02/28/2025 is a Continuation of PCT/JP2023/031859, filed 08/31/2023; claims foreign priority to 2022-137904, filed 08/31/2022; claims foreign priority to 2022-190241, filed 11/29/2022.
Drawings
The drawings filed on 05/23/2024 are accepted.
Specification
The specification filed on 02/28/2025 is accepted.
Response to Arguments
Applicant’s arguments, see remarks on page 9, with respect to claims objection to claims 7 and 14 have been fully considered and are persuasive. The objection has been withdrawn.
Applicant's arguments see remarks on pages 9-14, with respect to claims rejection under 103 have been fully considered but they are not persuasive because:
in issuing the identification information,” the identification information issuance system generates a private key corresponding to an issuer identifier that identifies an issuer being an issuing authority of the identification information”(Cheng teaches this limitations. The management web site (issuing authority) uses a private key corresponding to its unique identity (“first account” = issuer identifier) in the act of issuing the passport: “the passport comprises a public key of an avatar account that a user wants to register, a public key of a first account of the management website, and a signature which is made for the passport by the management website using its own private key of the first account.” See [0008], claim 91. The amendment website’s “first account” is the issuer identifier; its private key is the private key corresponding to that issuer identifier. The management website generates or uses this private key during the issuance transaction (Fig.2, steps S10-S13 ). To the extent “generates” requires per-issuance key derivation, Cheng BIP-32/44 HD wallet scheme enables deterministic derivation of new key pairs from a master seed, rendering obvious a per issuance derived signing key). Newy found reference teaches the limitations Sporny et al VC Data Model” the issuer is identified by a DID( the issuer identifier). The issuer uses its private key to create the proof on the verifiable credential.” Applying Sporny et al VC DID key pair architecture to Silverstein see [0082],[0084], [0108]), and a private key corresponding to a holder identifier that indicates the end user and/or the avatar (Cheng teaches the BIP 32/44 HD wallet derivation generates a public private key pair for the avatar account (the holder). The avatar account’s private key is the private key corresponding to the holder identifier: “the avatar account is a BIP 32/44) HD wallet derivation of the disclosable real name account see [0008]-[0012], “ the passport comprises a public key of an avatar account that a user wants to register,”. The holder’s public key in the passport corresponds to the holder’s private key. Silverstein teaches “ the private key associated with the subject-based avatar,” see abstract Holder identifier’s private key. Sporny et al teaches section 4.2 teaches “the holder is identified by a DID (the older identifier) the holder may use their private key to create a verifiable presentation) , and
the identification information is stored in connection with the private key corresponding to the issuer identifier and the private key corresponding to the holder identifier(Cheng teaches this limitations through three independent grounds: a holder side connection: the terminal device (holder) stores the passport and also maintains the avatar account’s private key, both reside in the same device’s storage, operatively connected (the holder signs presentations using that private key); b Issuer side connection: the management website stores issuance records alongside its own first account private key, the signing key used to create the passport constituting storage of identification information in connection with issuer identifier’s private key. Intrinsic key association: the passport itself contains the management website’s public key ( corresponding to issuer’s private key) and the avatar account’s public key (corresponding to holder private key) the passport is intrinsically associated with both private keys through their public key counterparts. Silverstein teaches step 708 stores the certificate in the server’s memory, which also manages the avatar’s private key, the certificate is stored in the same memory in connection with holder’s private key. Sporny et al teaches at section 3.2-3.5 the holder credential repository stores the VC and holder’s private key (holder side). The issuer retains issuance records alongside their signing key (issuer side). Standard W3C VC architecture.).
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-4, 7, 9-11, 14 and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Silverstein et al U.S. 2023/0254300 A1 in view of Cheng U.S. 2022/0318356 A1 in further view of Sporny et al Verifiable Credentials Data Model 1.10.
Claim 1: Silverstein et al teaches an avatar management system (Silverstein et al teaches a system comprising a server (130) connected to client devices (110) over a network, the server including an avatar model engine (232) and a blockchain network engine (234) that collectively manage subject-based avatars for authenticated use in immersive reality applications. See Abstract ("A system includes a memory storing instructions, and a processor configured to execute the instructions to cause the system to perform operations"); FIG. 2 (block diagram of server 130 and client device 110); ¶ [0030] ("the server 130 may include an avatar model engine 232 that creates, stores, updates, and maintains the avatar model"), comprising:
an avatar identification information management unit comprising circuitry (Silverstein et al teaches a server comprising a processor (circuitry) that is "configured to execute the instructions to cause the system to perform operations" relating to avatar identity management. See FIG. 2 (processor 212 within server 130); ¶ [0028] ("memory 220 storing instructions" executed by processor). The avatar model engine (232) and blockchain network engine (234) together constitute the avatar identification information management unit.)
and store the identification information in a memory (Silverstein et al teaches par.55 storing an encrypted version of the certificate of validity in a memory. In some embodiments, step 708 includes storing the encrypted version of the certificate of validity in a blockchain database (Fig.7, step 708,Abstract; Claim 1 equivalent "memory/blockchain database" is the storage unit), wherein the identification information is associated with an avatar authentication identifier issued (Silverstein et al that the certificate of validity and the underlying private key are each uniquely associated with the subject-based avatar: "verifying, in a server, a public key provided by the client device against a private key stored in the server, the private key associated with the subject-based avatar. (Abstract; Claim 1 equivalent.)(¶ [0003], [0007]. [0035], [0053]-[0054].)The private key is unique per avatar (each subject-based avatar has its own public/private key pair). This key pair is the "avatar authentication identifier issued so as to be unique for each avatar." The authentication certificate / certificate of validity is the "identification information associated with" that unique key-pair identifier) and verifies identity as an avatar such that the identification information is unique for the avatar (Silverstein et al teaches (¶[0053], that the certificate of validity verifies the identity of the user as the subject-based avatar: “providing, to the client device, a certificate of validity of the identity of the user when the public key matches the private key." (Abstract; Claim 1 equivalent.) The user's identity is verified as the owner/controller of the subject-based avatar. “Step 704 includes physically verifying a biomarker or an issued documentation certifying an identity of an owner of the subject-based avatar." Identity is verified as the specific avatar.“‘ The server is a third party validating application, and step 702 includes receiving a request, by a second client device running the third party validating application, the request activated on the subject-based avatar by a participant in the immersive reality application) registered and usable in a network service provided to an end user on a network (Silverstein et al teaches that the authenticated subject-based avatar is used across multiple network service applications provided to end users: “the application [222/322/422/522/622] running in the client device" is a VR/AR network application. (¶[0022]–[0026].) Application scenarios include: "educational application," "financial application," "social network application," "personal application," "virtual reality application" — all network services provided to end users. (Figs. 4–6; ¶[0065]–[0085].).
Silverstein et al fails to teach however Cheng in the same field of endeavor teaches
configured to cause an identification information issuance system to issue identification information (Cheng teaches in complete structural detail the process by which a terminal device causes the management website (the identification information issuance system) to issue a passport (identification information):"Sending a passport application request to the management website, wherein the passport application request comprises a public key of the disclosable real-name account, a chain code of the disclosable real-name account, and a derivation path of deriving the avatar account from the disclosable real-name account, and a signature which is made for the passport application request by using a private key of the disclosable real-name account." ([0173],[0233]-]0237],
"Receiving a passport sent by the management website." (Claim 5.)
Steps S10–S13 (FIG. 2): Terminal sends passport application request → management website receives and verifies → management website derives avatar account public key → management website issues and returns passport. Further teaches the full request/response protocol by which the avatar identification information management unit (terminal device) causes the identification information issuance system (management website) to issue identification information (passport). [0154]-[0155].)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Silverstein et al with the additional features of Cheng in order to implement series of mechanisms from the application to the use, concerning the passport and the user card, as suggested by Cheng abstract.
the combined teaching of Silverstein et al in view of Cheng covers most of the limitations on their own Cheng management website “first account” key= issuer identifier key; avatar account BIP 32/42 key = holder identifier key however Sporny et al provide the clearest most direct anticipation structure and further teaches
in issuing the identification information, the identification information issuance system generates a private key corresponding to an issuer identifier that identifies an issuer being an issuing authority of the identification information(section 2, 3.1, issuer holds a DID (issuer idnetifier0 + private key to sign credentials ), and a private key corresponding to a holder identifier that indicates the end user and/or the avatar(section 2, 4.2, holder holds a DID (holder identifier) + private key to sign presentation ), and
the identification information is stored in connection with the private key
corresponding to the issuer identifier and the private key corresponding to the holder identifier(section 2, 4.7, verifiable credential contains issuer’s DID, holder’s DID, and issuer’s digital signature(proof) verifier verifies using the public key from issuer’s DID document credential and DIDs stored in decentralized repositories.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Silverstein et al with the additional features of Sporny et al in order to provide a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable, as suggested by Sporny et al abstract.
Claims 17 and 18: Silverstein et al teaches an avatar management method in an avatar management system, and a non-transitory computer-readable storage medium stored therein a program that when executed by a computer in an avatar management system, executes an avatar management method comprising (130) connected to client devices (110) over a network, the server including an avatar model engine (232) and a blockchain network engine (234) that collectively manage subject-based avatars for authenticated use in immersive reality applications. See Abstract ("A system includes a memory storing instructions, and a processor configured to execute the instructions to cause the system to perform operations"); FIG. 2 (block diagram of server 130 and client device 110); ¶ [0030] ("the server 130 may include an avatar model engine 232 that creates, stores, updates, and maintains the avatar model"), comprising:
store the identification information in a memory (Silverstein et al teaches par.55 storing an encrypted version of the certificate of validity in a memory. In some embodiments, step 708 includes storing the encrypted version of the certificate of validity in a blockchain database (Fig.7, step 708,Abstract; Claim 1 equivalent "memory/blockchain database" is the storage unit), the identification information is associated with an avatar authentication identifier issued and verifies identity as an avatar such that the identification information is unique for the avatar registered and usable in a network service provided to an end user on a network (Silverstein et al that the certificate of validity and the underlying private key are each uniquely associated with the subject-based avatar: "verifying, in a server, a public key provided by the client device against a private key stored in the server, the private key associated with the subject-based avatar. (Abstract; Claim 1 equivalent.)(¶ [0003], [0007]. [0035], [0053]-[0054].)The private key is unique per avatar (each subject-based avatar has its own public/private key pair). This key pair is the "avatar authentication identifier issued so as to be unique for each avatar." The authentication certificate / certificate of validity is the "identification information associated with" that unique key-pair identifier);
Silverstein et al fails to teach however Cheng in the same field of endeavor teaches
causing an identification information issuance system to issue identification information (Cheng teaches in complete structural detail the process by which a terminal device causes the management website (the identification information issuance system) to issue a passport (identification information):"Sending a passport application request to the management website, wherein the passport application request comprises a public key of the disclosable real-name account, a chain code of the disclosable real-name account, and a derivation path of deriving the avatar account from the disclosable real-name account, and a signature which is made for the passport application request by using a private key of the disclosable real-name account." ([0173],[0233]-]0237],
"Receiving a passport sent by the management website." (Claim 5.)
Steps S10–S13 (FIG. 2): Terminal sends passport application request → management website receives and verifies → management website derives avatar account public key → management website issues and returns passport. Further teaches the full request/response protocol by which the avatar identification information management unit (terminal device) causes the identification information issuance system (management website) to issue identification information (passport). [0154]-[0155].)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Silverstein et al with the additional features of Cheng in order to implement series of mechanisms from the application to the use, concerning the passport and the user card, as suggested by Cheng abstract.
the combined teaching of Silverstein et al in view of Cheng covers most of the limitations on their own Cheng management website “first account” key= issuer identifier key; avatar account BIP 32/42 key = holder identifier key however Sporny et al provide the clearest most direct anticipation structure and further teaches
in the causing, the identification information issuance system generates a private key corresponding to an issuer identifier that identifies an issuer being an issuing authority of the identification information(section 2, 3.1, issuer holds a DID (issuer idnetifier0 + private key to sign credentials ), and a private key corresponding to a holder identifier that indicates the end user and/or the avatar(section 2, 4.2, holder holds a DID (holder identifier) + private key to sign presentation ), and
the storing stores the identification information in connection with the private key corresponding to the issuer identifier and the private key corresponding to the holder identifier (section 2, 4.7, verifiable credential contains issuer’s DID, holder’s DID, and issuer’s digital signature(proof) verifier verifies using the public key from issuer’s DID document credential and DIDs stored in decentralized repositories.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Silverstein et al with the additional features of Sporny et al in order to provide a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable, as suggested by Sporny et al abstract.
Claim 2: the combination teaches
wherein the circuitry of the avatar identification information management unit is configured to generate signed identification information with a digital signature with respect to the identification information of the avatar using a private key associated with the avatar authentication identifier of the avatar using at least the private key corresponding to the issuer identifier and the private key corresponding to the holder(Silverstein et al teaches that the server assigns authentication credentials specifically the authentication certificate (327-1) and the private key uniquely to each subject-based avatar at registration: "The identity issuing organization 303 provides the authentication certificate 327-1 for the subject avatar 332 based on the individual 302." (FIG. 3; ¶ [0025], [0003],[0005], [0038], [0040]) Authentication certificate is added to the registered avatar. Sporny et al teaches section the proof of a verifiable credentials created using the user private key Signed identification information (VC with proof) using the private key corresponding to the issuer identifier.), and
transmits the identification information of the avatar to a verifier who performs identification regarding the avatar by decrypting the identification information using a public key corresponding to the private key (Silverstein et al teaches ¶[0053], that server performs an authenticity judgment (verifying the avatar's public/private key match) in response to an authenticity confirmation request from a participant. "Step 704: verifying, in a server, a public key provided by the client device against a private key stored in the server" Sporny et al section 3.5 the verifier receives a verifiable presentation and verifies the proof using issuer’s public key).
The same motivation to modify Silverstein et al in view of Cheng applied to claim 1 above applies here.
Claims 3 and 10: the combination teaches
wherein the identification information issuance system includes a public identification information issuance system that issues public identification information of a public issuer (Cheng teaches ¶[00011], [0013], [0029], [0092]-[0093] embedding unique identifying information within the avatar account credential structure: “A verification root code calculated from the public key of the disclosable real-name account and the total derivation path of the avatar account." This unique code is embedded within the passport an identifier unique to that avatar embedded within its credential data).
The same motivation to modify Silverstein et al in view of Cheng applied to claim 1 above applies here.
Claims 4 and 11: the combination teaches
wherein the identification information issuance system includes a private identification information issuance system that issues private identification information associated with a private issuer (Silverstein et al ¶[0022]-[0025], [0037], Cheng ¶[0162]-[0026], [0035]).
The same motivation to modify Silverstein et al in view of Cheng applied to claim 1 above applies here.
Claims 7 and 14: the combination teaches further comprising:
a use authorization setting unit comprising circuitry configured to set use authorization that uses the avatar that exists in a metaverse to an end user other than a primary authorized user (Silverstein et al ¶[0025]-[0026], [0035]).
Claims 9 and 16: the combination teaches
an authenticity information addition unit comprising circuitry configured to add authenticity certification information to an avatar that is registered (Silverstein et al teaches that the server stores and maintains the avatar model (registration) in the blockchain and makes it available for use in network service applications: the avatar model engine (232) on the server … creates, stores, updates, and maintains the avatar model." (¶ [0030].) The avatar model engine is the avatar registration unit; storing the avatar model is avatar registration. The registered avatar is delivered to network service applications); and
an authenticity confirmation unit comprising circuitry configured to confirm authenticity of the avatar in response to a query of authenticity confirmation being performed by designating the avatar used in the network service (Cheng teaches ¶ [0091]-[0098] "if results of all verification items are 'yes', one resource identifier is allocated to the user, and the public key of the avatar account is bound with the resource identifier." This is avatar account registration: the avatar account (with its identifying public key) is registered and allocated a resource identifier in the application website's system, making it available for use in that network service).
The same motivation to modify Silverstein et al in view of Cheng applied to claim 1 above applies here.
Claim 19:the combination teaches wherein the circuitry of the avatar identification information management unit is configured to
generate, in response to an identification information request from a verifier(Cheng teaches Fig. steps 5, the avatar account holder generates and transmits the signed identification information in direct response to a login/identification request; Sporny et al teaches section 2 a verifier may request a verifiable presentation from a holder. The holder generates the verifiable presentation in response to the request Silverstein et al teaches Fig.8 receiving, in a server, an authentication credential from client device”), encrypted
identification information being the identification information encrypted with at least one of the private key corresponding to the issuer identifier and the private key corresponding to the holder identifier(Cheng teaches claim 3, Fig.2 step 5 the encrypted signed identification information is generated and transmitting in the login request; Sporny et al teaches section 2 ) .
The same motivation to modify Silverstein et al in view of Sporny et al applied to claim 1 above applies here.
Claim 20: the combination teaches
wherein the encrypted identification information is encrypted with the private key corresponding to the issuer identifier and the private key corresponding to the holder identifier(Cheng teaches at claims 91 & 93; Sporny et al teaches section 3.4 teaches a verifiable presentation that includes the verifiable credential is itself signed).
The same motivation to modify Silverstein et al in view of Sporny et al applied to claim 19 above applies here.
Claims 5-6 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Silverstein et al U.S. 2023/0254300 A1 in view of Cheng et al U.S. 2022/0318356 A1in further view of Sporny et al Verifiable Credentials Data Model 1.10. and Makmel et al U.S. 2019/0289013 A1.
Claims 5 and 12: the combination fails to teach, however Makmel et al in the same field of endeavor teaches
a credibility setting unit comprising circuitry configured to set a credit level indicating a degree of credibility of proving identification from the identification information (¶[0005],[0015]-[0023], determining whether the dynamic credibility score for the identity can be validated by consensus by at least a subset of the plurality of distributed verification services, based on whether the dynamic credibility score for the identity is within a range of variance from one or more credibility scores for the identity determined by the subset of the plurality of distributed verification services dynamic credibility score computed from identity actions maps to a credit level associated with avatar’s identification).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Silverstein et al with the additional features of Makmel et al in order to provide the ability to improve security and usability of services they provide over their networks, as suggested by Makmel et al par.2.
Claims 6 and 13: the combination teaches
a credit management unit comprising circuitry configured to evaluate the credibility of an issuer based on credit information indicating credibility of the issuer that causes the identification information issuance system to issue the identification information (Makmel et al, ¶[0005], [0015]-[0023], determining whether the dynamic credibility score for the identity can be validated by consensus by at least a subset of the plurality of distributed verification services, based on whether the dynamic credibility score for the identity is within a range of variance from one or more credibility scores for the identity determined by the subset of the plurality of distributed verification services dynamic credibility score computed from identity actions maps to a credit level associated with avatar’s identification distributed verification service collectivity evaluate and store credibility).
The same motivation to modify Silverstein et al in view of Makmel et al applied to claim 1 above applies here.
Claims 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Silverstein et al U.S. 2023/0254300 A1 in view of Cheng et al U.S. 2022/0318356 A1in further view of Sporny et al Verifiable Credentials Data Model 1.10. and Regev U.S. 2020/0082389 A1.
Claims 8 and 15: the combination teaches The avatar management system according to claim 2, further comprising:
a wallet addition unit comprising circuitry configured to associate an avatar with a wallet available for transaction in a metaverse (¶[0006],[0036]-[0040]), and
a transaction control unit comprising circuitry configured to control transaction between avatars using each of a plurality of wallets associated with each of a plurality of avatars (¶[0005],[0049]-[0051]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Silverstein et al with the additional features of Regev in order to provide an improved electronic reality system that integrates a cryptocurrency wallet for transmitting funds between senders and recipients based on interactions made in the electronic reality system, as suggested by Regev abstract.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 FATOUMATA TRAORE whose telephone number is (571)270-1685. The examiner can normally be reached 6:30-3:00.
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, SHEWAYE GELAGAY can be reached at 5712724219. 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.
Wednesday, October 14, 2026
/FATOUMATA TRAORE/Primary Examiner, Art Unit 2436
Prosecution Insights