DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
2. The information disclosure statement (IDS) submitted on 07/30/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
3. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
4. Claims 1-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
5. In the instant case, claims 1 and 8 are directed to a “method and one or more non-transitory computer-readable media for authentication avatar activity”.
6. Claim 1 recites “receiving a user’s signature in a payment instrument”. Specifically, claim recites “maintaining a … session comprising the … environment and a bidirectional interaction in the … environment between …controlled by input at a first user … and … controlled by input at a second user …; authenticating … the authentication … based at least in part on a mode of interaction with the first user …; rendering a… version of a financial instrument … for viewing …; rendering a signature … on the … version of the financial instrument, the signature based on input at the first user …; storing a record of the … session …, the record comprising the signature and the mode of interaction with the first user … associated with the signature”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
7. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 1 such as “avatar activity”, “a metaverse environment”, “a processor running a metaverse application”, “a secure metaverse session”, “a first avatar”, “a first user device”, “a second avatar”, “a second user device”, “a digital version of a financial instrument”, “a first user device”, “a second user device”, and “a computer memory” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of receiving a user’s signature in a payment instrument. And, with respect to “storing a record of the metaverse session in a computer memory, the record comprising the signature and the mode of interaction with the first user device associated with the signature” is simply transmitting data “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)).
8. When analyzed under step 2B (MPEP 2106.04 II), as the additional elements do no more than represent the use of a computer, or computer technology, as a tool to perform receiving a user’s signature in a payment instrument and they do not improve computer functionality or provide an improvement to another technology or technological field.
9. Hence, claim 1 is not patent eligible.
10. Claim 8 recites “replacing a user’s signature in a payment instrument”. Claim recites “maintaining a … session comprising … environment; authenticating … in the … environment, the … controlled by input at a user…, the authentication based at least in part on a method of … control at the user…; rendering a … representation of a financial instrument in the … environment for viewing …; rendering a … replacement signature … on the … version of the financial instrument, the signature based on input at the user …; and storing a record of the … session …”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
11. As in the case of claim 1, the judicial exception is not integrated into a practical application because when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 8 such as “one or more non-transitory computer-readable media”, “a processor on a computer system”, “avatar activity”, “a metaverse environment”, “a processor running a metaverse application”, “a secure metaverse session”, “an avatar”, “a user device”, “a virtual representation of a financial instrument”, “a virtual replacement signature”, and “a computer memory” represent the use of a computer as a tool to perform an abstract idea and/or does no more than link the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of replacing a user’s signature in a payment instrument. With respect to “storing a record of the metaverse session in a computer memory” is simply transmitting data “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)).
12. When analyzed under step 2B (MPEP 2106.04 II), as the additional elements do no more than represent the use of a computer, or computer technology, as a tool to perform replacing a user’s signature in a payment instrument and they do not improve computer functionality or provide an improvement to another technology or technological field.
13. Hence, claim 8 is not patent eligible.
14. Dependent claim 2 further describes the abstract idea of receiving a user’s signature in a payment instrument as it recites “wherein the mode of interaction comprises a type of user …”. The additional element such as “user device” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 3 further describes the abstract idea of receiving a user’s signature in a payment instrument as it recites “wherein the mode of interaction comprises a type of input …”. The additional element such as “the user device” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 4 further describes the abstract idea of receiving a user’s signature in a payment instrument as it recites “authenticating … based at least in part on a feature …”. The additional element such as “the avatar” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 5 further describes the abstract idea of receiving a user’s signature in a payment instrument as it recites “preregistering a financial institution account for … interactions”. The additional element such as “metaverse interactions” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 6 further describes the abstract idea of receiving a user’s signature in a payment instrument as it recites “preregistering … interactions regarding the financial institution account”. The additional element such as “a device for metaverse interactions” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 7 further describes the abstract idea of receiving a user’s signature in a payment instrument as it recites “… reproducing the signature on a paper version of the financial instrument”. The additional element such as “a check printing device interfacing with the metaverse application” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 9 further describes the abstract idea of replacing a user’s signature in a payment instrument as it recites “authenticating … based at least in part on a feature …”. The additional element such as “the avatar” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 10 further describes the abstract idea of replacing a user’s signature in a payment instrument as it recites “authenticating … based at least in part on a feature …”. The additional elements such as “the avatar” and “the user device” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 11 further describes the abstract idea of replacing a user’s signature in a payment instrument as it recites “preregistering a financial institution account …”. The additional element such as “metaverse interactions” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 12 further describes the abstract idea of replacing a user’s signature in a payment instrument as it recites “preregistering … interactions regarding the financial institution account”. The additional element such as “a device for metaverse interactions” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 13 further describes the abstract idea of replacing a user’s signature in a payment instrument as it recites “capturing the replacement signature and transmitting the replacement signature …”. The additional element such as “a check printing device interfacing with the metaverse application” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field. With respect to “transmitting the replacement signature to a check printing device interfacing with the metaverse application” is simply transmitting data “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)).
Dependent claim 14 further describes the abstract idea of replacing a user’s signature in a payment instrument as it recites “… reproducing the replacement signature on a paper version of the financial instrument”. The additional element such as “the check printing device” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Conclusion
15. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
16. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 112
17. The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
18. Claims 1-14 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Lack of Algorithm
19. Claim 1 recites “maintaining a secure metaverse session comprising the metaverse environment and bidirectional interaction…”.
Claim 8 recites “maintaining a secure metaverse session comprising a metaverse environment”.
Applicant does not say how the secure metaverse session is maintained. For example, the Applicant’s Specification (para 9) recites “A metaverse application may maintain a secure bidirectional metaverse session”. However, the specification explains the communication is over “http” (see ¶ 70) and not “https” for example which is “secure”. The specification does not sufficiently support the limitation as it neither describes how the security of the session is maintained. he Specification, paragraph 73 is similarly broad. The Specification (para 73) recites “Algorithms may be used to perform the functions of one or more of maintaining a metaverse session… authenticating an avatar…” but not what the specific algorithms are. Finally, claim 15 subsequently recites, “authenticate a first avatar…”. Therefore, avatar authentication is separate and distinct from how a secure metaverse session is maintained and cannot be relied upon to support a broadest reasonable interpretation of the claim. As a result, Applicant has not provided the algorithms or steps/procedures to perform “[maintaining] a secure bidirectional metaverse session” in sufficient detail such that one of ordinary skill in the art would not know applicant had possession of the claimed invention.
22. Claims 2-7 and 9-14 are rejected under the same rationale as claims 1 and 8 because claims 2-7 and 9-14 inherit the deficiencies of claims 1 and 8 respectively due to their dependency.
Claim Rejections - 35 USC § 102
30. 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.
31. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
32. Claims 1-6 and 8-12 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US20230254300A1 to Silverstein et al.
33. As per claim 1:
Silverstein et al. discloses the following limitations:
A method for authenticating avatar activity in a metaverse environment, the method comprising, at a processor running a metaverse application (Abstract “A method for authenticating an avatar for use in a virtual reality/augmented reality (VR/AR) application is provided.”, [0030] “…Application 222 may be a VR/AR application such that a user of client device 110 may participate in an immersive reality experience…”, [0052] “Step 702 includes receiving, from a client device, a request for authenticating the identity of a user of an immersive reality application running in the client device…”)
maintaining a secure metaverse session comprising the metaverse environment and a bidirectional interaction in the metaverse environment ([0013] “FIG. 5 illustrates a social scenario with subject-based avatars interacting in a virtual environment by a virtual reality application…”, [0014] “FIG. 6 illustrates a contractual scenario with subject-based avatars interacting in a virtual environment by a virtual reality application…” [0047] “… subject-based avatars 532A and 532B (hereinafter, collectively referred to as “subject-based avatars 532”) interacting in a virtual environment 551…”, [0048] “Accordingly, virtual reality application 522 may include “report” flags 527A and 527B … in the display for each of users 502…”, [0050] “Accordingly, virtual reality application 622 may include a “legal/administrative” flag 627A and 627B … in the display for each of users 602…”) between a first avatar controlled by input at a first user device and a second avatar controlled by input at a second user device ([0030] “… A user may interact with client device 110 via an input device 214 and an output device 216. Input device 214 may include a mouse, a keyboard, a pointer, a touchscreen, a microphone, and the like… Application 222 may be downloaded by the user from server 130…”, [0047] “…mobile devices 510-1A and 510-1B (hereinafter, collectively referred to as “mobile devices 510-1”) … Users 502A and 502B may be collectively referred, hereinafter, as ‘users 502’.”, [0049] “…mobile devices 610-1A and 610-1B (hereinafter, collectively referred to as ‘mobile devices 610-1’)…”)
authenticating the first avatar in the metaverse environment (Abstract “…The computer-implemented method also includes verifying, in a server, a public key provided by the client device against a private key stored in the server…”, fig.7, item 704, [0053] “Step 704 includes 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…”), the authentication of the first avatar based at least in part on a mode of interaction with the first user device ([0026] “In some embodiments, the user of a client device may attach a hardware key code to the client device. The hardware key code may include a public key used by the blockchain network to authenticate the user when a VR/AR application in the client device requests access to the subject-based avatar.”, [0027] “In some embodiments, a solution to the above technical problem includes other digital authentication paradigms, such as steganography. Accordingly, relevant identifying information may be stored in the least significant bits of a data file associated with a subject-based avatar model stored in a VR/AR server. The identifying information may be hashed or compared with identifying information of a user in a client device attempting to access the VR/AR server…”, [0030] “…Input device 214 may include a mouse, a keyboard, a pointer, a touchscreen, a microphone, and the like. Output device 216 may be a screen display, a touchscreen, a speaker, and the like…”, [0043] “In some embodiments, user 401 may couple a key device 414 including authentication credential 427-1 to client device 410. Key device 414 may include a hardware embedded encrypted code including an authentication credential…”)
rendering a digital version of a financial instrument in the metaverse environment for viewing by the first avatar and the second avatar (Fig.6, item “Legal Announcement 627B; [0012] “FIG. 4 illustrates a server providing a model for a subject avatar based on an individual, and a server hosting a VR application immersing the subject avatar in a virtual reality environment, the application being run in a client device…”, [0023] “In real life, when doing financial and other transactions involving identity verification, the traditional approach is to have notaries, witnesses, and government-issued documents like passports, birth certificates, and drivers licenses to control authenticity…”, [0047] “ FIG. 5 illustrates a social scenario 500 with subject-based avatars 532A and 532B … interacting in a virtual environment 551 by a virtual reality application 522…”, [0048] “Accordingly, virtual reality application 522 may include “report” flags 527A and 527B … in the display for each of users 502…”, [0049] “FIG. 6 illustrates a contractual scenario 600 with subject-based avatars 632A and 632B … interacting in a virtual environment 651 by a virtual reality application 622…”)
rendering a signature from the first avatar on the digital version of the financial instrument, the signature based on input at the first user device ([0030] “… A user may interact with client device 110 via an input device 214 and an output device 216. Input device 214 may include a mouse, a keyboard, a pointer, a touchscreen, a microphone, and the like…”, [0034] “In some embodiments, memory 220-2 may include a blockchain network engine 234. Blockchain network engine 234 includes an encryption tool 246 and a public key validation tool 248. Public key validation tool 248 is configured to validate, authenticate, and verify access from different client devices 110 and servers 130 to database 152…”, [0035] “Data packets 227-1 and 227-2 … may include encryption data and passwords, such as public keys and private keys…”, [0043] “In some embodiments, user 401 may couple a key device 414 including authentication credential 427-1 to client device 410…”, [0045] “Client device 410 receives a data packet 427-2 including avatar model 432 and a public key. Client device 410 recreates a three-dimensional representation 442 of user 401 by providing an input image or video from camera 414 of user 401 to avatar model 432.”)
storing a record of the metaverse session in a computer memory, the record comprising the signature and the mode of interaction with the first user device associated with the signature ([0026] “…the user of a client device may attach a hardware key code to the client device…”, [0031] “Server 130 includes a memory 220-2, a processor 212-2, and communications module 218-2…”, [0034] “In some embodiments, memory 220-2 may include a blockchain network engine 234…”, [0035] “…In some embodiments, data packets 227 may include a “blob” with multiple passwords, each password associated with a time-sensitive value. When a data packet or data update is accessed by a block producer in the blockchain network, it is saved as a signed/verified block 250 in database 252…”, [0046] “In some embodiments, server 430-1 may store, in blockchain database 452, a stack of encrypted blocks including model 432 and each of the different VR/AR transactions where model 432 has been used. This blockchain may be used by server 430-1 to update model 432 with new video footage of user 401 provided by client device 410 …”, [0055] “Step 708 includes 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.”)
34. As per claim 2:
Silverstein et al. discloses the following limitations:
wherein the mode of interaction comprises a type of user device ([0029] “Servers 130 may include any device having an appropriate processor, memory, and communications capability for hosting the avatar model engine or the blockchain engine…Client devices 110 can be, for example, desktop computers, mobile computers, tablet computers (e.g., including e-book readers), mobile devices (e.g., a smartphone or PDA)… client device 110 is a VR/AR headset, running a VR/AR application for the user…”, [0043] “… user 401 may couple a key device 414 including authentication credential 427-1 to client device 410. Key device 414 may include a hardware embedded encrypted code…”, [0047] “Network server 530, mobile devices 510-1A and 510-1B (hereinafter, collectively referred to as “mobile devices 510-1”), VR headsets 510-2A and 510-2B… Mobile devices 510-1 and headsets 510-2 will be referred to, collectively, as ‘client devices 510’”)
35. As per claim 3:
Silverstein et al. discloses the following limitations:
wherein the mode of interaction comprises a type of input at the user device ([0030] “… A user may interact with client device 110 via an input device 214 and an output device 216. Input device 214 may include a mouse, a keyboard, a pointer, a touchscreen, a microphone, and the like. Output device 216 may be a screen display, a touchscreen, a speaker, and the like…”, [0043] “… Key device 414 may include a hardware embedded encrypted code including an authentication credential…”, [0045] “… Client device 410 recreates a three-dimensional representation 442 of user 401 by providing an input image or video from camera 414…”, [0072] “… Input/output module 1010 can be any input/output module. Exemplary input/output modules 1010 include data ports such as USB ports… Exemplary input devices 1014 include a keyboard and a pointing device, e.g., a mouse or a trackball, by which a user can provide input to the computer system 1000.… For example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, tactile, or brain wave input…”)
36. As per claims 4 and 9:
Silverstein et al. discloses the following limitations:
authenticating the avatar based at least in part on a feature of the avatar ([0025] “In some embodiments, the blockchain ownership keys for a subject-based avatar model are transferred when the identity issuing organization verifies the identity of a user …”, [0027] “…relevant identifying information may be stored in the least significant bits of a data file associated with a subject-based avatar model…”, [0032] “…avatar model engine 232 may be configured to create, store, update, and maintain a three-dimensional animation model of a subject…”, [0033] “Guide mesh tool 242 determines facial expression parameters (z) based on input images, upon a classification scheme that is learned by training…”, [0036] “…a machine learning model as disclosed herein may include a neural network (NN), a convolutional neural network (CNN)… In some embodiments, database 252 may include a training archive to modify coefficients according to a desired outcome of the machine learning model…”)
37. As per claims 5 and 11:
Silverstein et al. discloses the following limitations:
preregistering a financial institution account for metaverse interactions ([0023] “… Embodiments as disclosed herein provide a technical solution to, automatically and remotely, verify the identity and ownership of a subject-based avatar using a blockchain network…”, [0031] “…Application 222 may be any VR/AR application, including revenue-based applications…or a financial transaction application…”, [0038] “A user 301 of a VR/AR device 310-4 may want to authenticate subject avatar 332 when it appears in a VR/AR application 322 running in VR/AR device 310-4…”, [0040] “ More specifically, user 301 may be an external viewer of avatar 332 through VR/AR device 310-4, and may request validation to a key holder (e.g., individual 302 or some other third party) …” [0052] “…step 702 further includes providing access, to the user, to a personal account in a financial institution. In some embodiments, step 702 includes receiving a request for authenticating a healthcare transaction or a social media transaction including the subject-based avatar.”)
38. As per claims 6 and 12:
Silverstein et al. discloses the following limitations:
preregistering a device for metaverse interactions regarding the financial institution account ([0026] “In some embodiments, the user of a client device may attach a hardware key code to the client device. The hardware key code may include a public key used by the blockchain network to authenticate the user when a VR/AR application in the client device requests access to the subject-based avatar.”, [0043] “In some embodiments, user 401 may couple a key device 414 including authentication credential 427-1 to client device 410… Accordingly, user 401 may carry key device 410 across multiple client devices, and use it to access the individualized avatar model 432 from any device, and any application.”, [0047] “…Network server 530, mobile devices 510-1A and 510-1B … VR headsets 510-2A and 510-2B … Mobile devices 510-1 and headsets 510-2 will be referred to, collectively, as ‘client devices 510’ … Subject-based avatar 532A (532B) is associated with a user 502A (502B), and the association may be verified via the authentication mechanisms and credentials described in this disclosure.”, [0052] “… step 702 further includes providing access, to the user, to a personal account in a financial institution…”)
39. As per claim 8:
Silverstein et al. discloses the following limitations:
One or more non-transitory computer-readable media storing computer-executable instructions which, when executed by a processor on a computer system, perform a method for authenticating avatar activity in a metaverse environment, the method comprising (Abstract “A method for authenticating an avatar for use in a virtual reality/augmented reality (VR/AR) application is provided.” [0006] “…a non-transitory, computer-readable medium stores instructions which, when executed by a processor, cause a computer to perform a method. The method includes receiving, in a server, an authentication credential from a first user via a client device, the authentication credential encrypted with a public key provided by the client device, and validating the authentication credential with a private key associated with the public key…”)
at a processor running a metaverse application ([0052] “Step 702 includes … an immersive reality application running in the client device…”)
maintaining a secure metaverse session comprising a metaverse environment ([0013] “FIG. 5 illustrates a social scenario with subject-based avatars interacting in a virtual environment by a virtual reality application…”, [0048] “Accordingly, virtual reality application 522 may include “report” flags 527A and 527B … in the display for each of users 502…”, [0050] “Accordingly, virtual reality application 622 may include a “legal/administrative” flag 627A and 627B … in the display for each of users 602…”)
authenticating an avatar in the metaverse environment, the avatar controlled by input at a user device, the authentication based at least in part on a method of avatar control at the user device (Abstract “…The computer-implemented method also includes verifying, in a server, a public key provided by the client device against a private key stored in the server…”, ([0030] “… A user may interact with client device 110 via an input device 214 and an output device 216. Input device 214 may include a mouse, a keyboard, a pointer, a touchscreen, a microphone, and the like… Application 222 may be downloaded by the user from server 130…”, [0047] “…mobile devices 510-1A and 510-1B (hereinafter, collectively referred to as “mobile devices 510-1”) … Users 502A and 502B may be collectively referred, hereinafter, as ‘users 502’.”, [0049] “…mobile devices 610-1A and 610-1B (hereinafter, collectively referred to as ‘mobile devices 610-1’) …”), fig.7, item 704, [0053] “Step 704 includes 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…”)
rendering a virtual representation of a financial instrument in the metaverse environment for viewing by the avatar (Fig.6, item “Legal Announcement 627B; [0012] “FIG. 4 illustrates a server providing a model for a subject avatar based on an individual, and a server hosting a VR application immersing the subject avatar in a virtual reality environment, the application being run in a client device…”, [0023] “In real life, when doing financial and other transactions involving identity verification, the traditional approach is to have notaries, witnesses, and government-issued documents like passports, birth certificates, and drivers licenses to control authenticity…”, [0049] “FIG. 6 illustrates a contractual scenario 600 with subject-based avatars 632A and 632B … interacting in a virtual environment 651 by a virtual reality application 622…”)
rendering a virtual replacement signature from the avatar on the virtual version of the financial instrument, the signature based on input at the user device ([0030] “… A user may interact with client device 110 via an input device 214 and an output device 216. Input device 214 may include a mouse, a keyboard, a pointer, a touchscreen, a microphone, and the like…”, [0034] “In some embodiments, memory 220-2 may include a blockchain network engine 234. Blockchain network engine 234 includes an encryption tool 246 and a public key validation tool 248. Public key validation tool 248 is configured to validate, authenticate, and verify access from different client devices 110 and servers 130 to database 152…”, [0035] “Data packets 227-1 and 227-2 … may include encryption data and passwords, such as public keys and private keys…”, [0043] “In some embodiments, user 401 may couple a key device 414 including authentication credential 427-1 to client device 410…”, [0045] “Client device 410 receives a data packet 427-2 including avatar model 432 and a public key. Client device 410 recreates a three-dimensional representation 442 of user 401 by providing an input image or video from camera 414 of user 401 to avatar model 432.”)
storing a record of the metaverse session in a computer memory [0031] “Server 130 includes a memory 220-2, a processor 212-2, and communications module 218-2…”, [0046] “In some embodiments, server 430-1 may store, in blockchain database 452, a stack of encrypted blocks including model 432 and each of the different VR/AR transactions where model 432 has been used. This blockchain may be used by server 430-1 to update model 432 with new video footage of user 401 provided by client device 410 …”, [0055] “Step 708 includes 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.”)
40. As per claim 10:
Silverstein et al. discloses the following limitations:
authenticating the avatar based at least in part on a feature of the user device ([0029] “… In some embodiments, client device 110 is a VR/AR headset, running a VR/AR application for the user. Further, in some embodiments, a client device 110 may include a mobile device (e.g., smartphone or tablet) communicatively coupled with the VR/AR headset, and hosting the VR/AR application to control the VR/AR headset…”, [0053] “Step 704 includes 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…”, [0057] “Step 802 includes receiving, in a server, an authentication credential from a first user via a client device, the authentication credential encrypted with a public key provided by the client device…step 802 includes receiving the public key from a second device coupled to the client device, via the client device.”)
Conclusion
41. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20150200950A1 – Meunier et al. – Discloses a computer system manages role-based digital rights by creating a chain of trust that originates with a user who purports to act as a registration authority whose status can be verified to ascertain that the user is licensed to act as the registration authority.
US20100153858A1 – Gausman et al. – Discloses a methodology for creating a uniform virtual environment across disparate devices utilizing a plurality of delivery services, wherein a communication system including at least two graphical display devices and a communication service platform for providing communication.
US20180034642A1 – Kaehler – Discloses systems and methods for securely exchanging cryptographically signed records, wherein in one aspect, after receiving a content request, a sender device can send a record to a receiver device (e.g., an agent device) making the request and the record can be sent via a short range link in a decentralized (e.g., peer-to-peer) manner while the devices may not be in communication with a centralized processing platform.
US20150143487A1 – Nathan et al. – Discloses systems and methods for authenticating an avatar wherein the avatar having an identifier, virtual environments, and a user who uses the avatar in the virtual environments.
42. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/ Examiner, Art Unit 3692
/RYAN D DONLON/ Supervisory Patent Examiner, Art Unit 3692