DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This Office Action is in response Applicant communication filed on 2/26/2026.
Claims
Claims 1, 10, and 16 have been amended.
Claims 7, 13, 18, and 22 have been cancelled.
Claims 1-6, 8-12, 14, and 15 have been withdrawn from consideration as being directed to non-elected subject matter.
Claims 1-6, 8-12, 14-17, 19-21, and 23 are currently pending in the application.
Response to Arguments
103
In Applicant’s arguments with respect to claim 1 have been considered but are moot because new references have been added as necessitated by the applicant’s amendments to the claims.
Rejections under 35 § U.S.C. 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all
obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 16, 17, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over US 20240181987 A1 (“Stefanovski”) and US 20240261692 A1 (“Sliwka”) and US 20240281779 A1 (“Richter”) and US 20190050520 A1 (“Alvarez”).
Per claim 16, Stefanovski discloses:
generate a non-fungible token for the physical vehicle on a blockchain… (e.g. Vehicle management system 102 may include a blockchain 108, which may be used by vehicle management system 102 as a distributed ledger to store permissions for accessing, operating, and/or using various functionalities of vehicle 130. In various embodiments, blockchain 108 may store one or more non-fungible tokens (NFTs) including permissions and other data of vehicle 130, referred to herein as NFT-VIDs. Blockchain 108 may also store one or more NFTs including permissions and other data of various persons linked to or associated with vehicle 130, referred to herein as NFT-DIDs. The various persons linked to or associated with vehicle 130 may include one or more vehicle owners 137 of vehicle 130, and one or more vehicle operators 138 of vehicle 130. The NFT-VIDs and the NFT-DIDs may be written to blockchain 108 and updated as new blocks are added to blockchain 108) (Section [0034]);
receive a request to provide temporary access of the physical vehicle… for a duration of time (e.g. In various embodiments, the new digital key may be created based on information included in the request (e.g., included by default or specified by the new owner). The digital key may be a non-limiting version of digital key 306 of FIG. 3, and may include fields for data of the operator (e.g., operator data 308), and data of the vehicle (e.g., vehicle data 310), which may be extracted from the request. The digital key may include a field for expiration date of the digital key (e.g., expiration data 312), which may include an expiration date and/or terms under which the digital key may be invalidated) (Section [0083]).
Although Stefanovski teaches generating a vehicle NFT on the blockchain and using the NFT to provide temporary access to the physical vehicle for a duration of time, Stefanovski does not specifically disclose:
…the non-fungible token providing a virtual vehicle corresponding to the physical vehicle;
receive a request to provide… access of… the virtual vehicle from an owner to a third party…;
record the third party on the blockchain to transfer ownership of the virtual vehicle to the third party….
However Sliwka, in analogous art of NFTs that represent physical assets, discloses:
…the non-fungible token providing a virtual vehicle corresponding to the physical vehicle (e.g. For example, the user may view an inventory user interface within the game, which may present a listing of blockchain tokens (e.g., NFT representing weapons, clothing, armor, potions, scrolls, etc. for a fantasy game, NFTs representing vehicles for a racing, driving, or piloting game, or any other collectible token that may be used in a game)) (Section [0264], [0289], [0485], [1279], and [1370]);
receive a request to provide… access of… the virtual vehicle from an owner to a third party… (e.g. At 1604, a transaction request is received through a suitable process, such as those described above. At 1606, transaction of the item occurs. In embodiments, ownership data of a specific token corresponding to the virtual representation in the first side chain of blocks is updated to indicate that the transacting user owns the specific token. In embodiments, the transaction of the item includes validating the specific token based on the digital-token identifier and the first chain of blocks, verifying that the different user has a valid account on the tokenization platform based on the public address of the user and the main chain of blocks, and, in response to validating the specific token and verifying the different user, updating the second chain of blocks with a new block. The new block includes ownership data that indicates that the specific token corresponding to the virtual representation is owned by the different user) (Section [0317]-[0319] and [1317]-[1322]);
record the third party on the blockchain to transfer ownership of the virtual vehicle to the third party… (e.g. At 1604, a transaction request is received through a suitable process, such as those described above. At 1606, transaction of the item occurs. In embodiments, ownership data of a specific token corresponding to the virtual representation in the first side chain of blocks is updated to indicate that the transacting user owns the specific token. In embodiments, the transaction of the item includes validating the specific token based on the digital-token identifier and the first chain of blocks, verifying that the different user has a valid account on the tokenization platform based on the public address of the user and the main chain of blocks, and, in response to validating the specific token and verifying the different user, updating the second chain of blocks with a new block. The new block includes ownership data that indicates that the specific token corresponding to the virtual representation is owned by the different user) (Section [0317]-[0319] and [1317]-[1322]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the vehicle NFT generation system of Stefanovski to include NFTs that display virtual and operable renderings of assets that correspond to physical assets and transfer ownership of the NFTs, as taught by Sliwka, in order to achieve the predictable result of increasing sales by providing incentives to the buyer by allowing them to use the purchased NFT in game of a virtual environment.
Although Stefanovski/Sliwka teaches generating a vehicle NFT on the blockchain, using the NFT to provide temporary access to the physical vehicle for a duration of time and recording a third party on the blockchain to transfer ownership of a virtual asset to the third party that can render and operate the virtual asset in a game, Stefanovski/Sliwka does not specifically disclose:
receive a request to provide temporary access of… the virtual vehicle from an owner to a third party for a duration of time;
…transfer ownership of the virtual vehicle to the third party for the duration of time.
However Richter, in analogous art of transferring NFT access, discloses:
receive a request to provide temporary access of… the virtual vehicle from an owner to a third party for a duration of time (e.g. A “reNFT,” as disclosed in this disclosure, is an NFT that may be rented and/or leased from an owner to a renter and/or lessee for a predetermined period of time. In some embodiments, a renter and/or lessee may be required to deposit a collateral in order to temporarily use the owner's NFT. In some embodiments, collateral-free renting may be enabled such that a “wrapped” version of the NFT may be rented out and may be recalled at any moment by the owner) (Section [0035]);
…transfer ownership of the virtual vehicle to the third party for the duration of time (e.g. e.g. A “reNFT,” as disclosed in this disclosure, is an NFT that may be rented and/or leased from an owner to a renter and/or lessee for a predetermined period of time. In some embodiments, a renter and/or lessee may be required to deposit a collateral in order to temporarily use the owner's NFT. In some embodiments, collateral-free renting may be enabled such that a “wrapped” version of the NFT may be rented out and may be recalled at any moment by the owner) (Section [0035] and [0053]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the vehicle NFT transfer system of Stefanovski/Sliwka to include temporary transfers, as taught by Richter, in order to achieve the predictable result of allowing the owner to make money on the virtual/physical asset while maintaining ownership of the asset long term.
Although Stefanovski/Sliwka/Richter teaches generating a virtual NFT vehicle that is a representation of a physical vehicle and operating the virtual vehicle in a virtual environment, Stefanovski/Sliwka/Richter does not specifically disclose:
a vehicle sensor configured to collect vehicle performance data of a physical vehicle and environment data of a surrounding environment of the physical vehicle;
map vehicle performance data to environment conditions, wherein the environment condition is determined based on the environment data;
generate the virtual environment comprising one of the environment conditions;
adjust a virtual vehicle performance attribute of the virtual vehicle based on the vehicle performance data corresponding to the one of environment conditions such that the virtual vehicle has similar performance characteristics in the virtual environment as the physical vehicle in a physical environment;
render, via a display device, the virtual vehicle having the adjusted virtual vehicle performance attribute in the virtual environment.
However Alvarez, in analogous art of virtual vehicle simulations, discloses:
a vehicle sensor configured to collect vehicle performance data of a physical vehicle and environment data of a surrounding environment of the physical vehicle (e.g. The data collection device 110 may be integrated into existing vehicle components, such as the in-vehicle infotainment (IVI) system or the advanced driver assistance system (ADAS), which may be a part of the CAN. The data collection device 110 may be software running on the electronic control unit (ECU) of the IVI, ADAS or similar vehicle computer system. The vehicle 105 is driven to collect data about the performance of the vehicle 105. The vehicle 105 may be driven in a manner of everyday use. The vehicle 105 may be driven in specific scenarios or repeatedly along a predetermined course. The data collection device 110 may be programmed to collect performance data from the vehicle 105 at a range of time intervals, such as every 30 seconds, every 5 minutes, or every hour. The data collection device 110 may collect data based on the actions of the vehicle 105, such as collecting data each time the vehicle 105 is started) and (e.g. Data may be collected for the real world environment of that roadway. A vehicle performance fingerprint is generated for the vehicle during the time it is driven on the roadway. The vehicle performance fingerprint and environmental data may be received by the simulation construction unit 225 to construct a simulation vehicle based on the vehicle performance fingerprint and a simulation environment representing the section of roadway) (Section [0022], [0023], [0034], [0044], [0049], and [0050]);
map vehicle performance data to environment conditions, wherein the environment condition is determined based on the environment data (e.g. The systems and methods herein provide a mechanism to import the vehicle performance fingerprint of a real vehicle by reading controller area network (CAN) messages from a particular car over time and mapping those values to configuration parameters used in a driving simulator. The vehicle performance fingerprint may be used to create vehicle physics models and to customize responses to control interfaces (e.g., acceleration, brakes, or steering) in the driving simulator) (Section [0016] and [0037]);
generate the virtual environment comprising one of the environment conditions (e.g. Data may be collected for the real world environment of that roadway. A vehicle performance fingerprint is generated for the vehicle during the time it is driven on the roadway. The vehicle performance fingerprint and environmental data may be received by the simulation construction unit 225 to construct a simulation vehicle based on the vehicle performance fingerprint and a simulation environment representing the section of roadway) (Section [0034]);
adjust a virtual vehicle performance attribute of the virtual vehicle based on the vehicle performance data corresponding to the one of environment conditions such that the virtual vehicle has similar performance characteristics in the virtual environment as the physical vehicle in a physical environment (e.g. A driving simulator may have multiple vehicle models for the simulator to use as the vehicle being driven or the other vehicles on the road in the simulation. The vehicle models may be modified by the vehicle performance fingerprint. The vehicle models may be loaded into a particular map and terrains and engage in realistic animations vehicle dynamics and traffic. The simulator may have a physics engine to recreate realistically the interactions that may happen in the real world by applying multiple forces, such as friction forces, that have an impact on how vehicles perform upon control inputs. For example, friction forces such as road friction, wind friction, gravity, and drag may be modified. Environmental forces such as light and temperature may be modified) (Section [0016], [0037], and [0038]);
render, via a display device, the virtual vehicle having the adjusted virtual vehicle performance attribute in the virtual environment (e.g. The drive simulator 230 receives the constructed simulation vehicle and simulated environment from the simulation construction unit 225. The simulation construction unit 225 may provide secondary simulated aspects such as additional vehicles on the road. The drive simulator 230 performs the simulated drive using the simulated vehicle and simulated environment to present the simulated experience to a user of the simulator via the display output 235) (Section [0031], [0034], and [0037]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the virtual vehicle and environment of Stefanovski/Sliwka/Richter to include adjustments to the virtual environment and virtual vehicle performance based on real world data collected by real world sensors, as taught by Alvarez, in order to achieve the predictable result of improving the user experience by making the virtual environment more realistic.
Per claim 17, Stefanovski/Sliwka/Richter/Alvarez teaches all of the limitations of claim 16 above. Sliwka further discloses:
wherein the virtual vehicle is a virtual rendering of the physical vehicle (e.g. At 1306, a virtual representation of the collateral item is generated based on the item information. At 1308, one or more tokens are generated based on the virtual representation. At 1310, ownership of the digital token is assigned. Initially, the ownership of the digital token is assigned to the owner of the collateralized item represented by the digital token) (Section [0149], [0311]-[0312], [0351], and [0408]).
The motivation to combine Sliwka with Stefanovski/Richter/Alvarez is disclosed above with reference to claim 16.
Per claim 23, Stefanovski/Sliwka/Richter/Alvarez teaches all of the limitations of claim 16 above. Alvarez further discloses:
wherein the vehicle performance attributes comprise one or more of energy efficiency, maximum speed, acceleration, handling, braking distance, off-read capabilities, torque, horse power, suspension, roll center, weight distribution, rolling resistance, or coefficient of friction (e.g. In an example, the operation 602 may include vehicle performance data that is collected at predetermined intervals of time. For example, the data may be collected based on time such as at monthly or yearly intervals, or the data may be collected based on events, such as at every oil change or every 10,000 miles on the odometer. In an example, the operation 604 may include modifying the simulated driving experience with at least one of road friction, wind friction, gravity, or drag. In an example, the operation 602 may include the vehicle experiencing real world driving conditions is an autonomous vehicle) (Section [0037] and [0049]).
The motivation to combine Alvarez with Stefanovski/Sliwka/Richter is disclosed above with reference to claim 16.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Stefanovski/Sliwka/Richter/Alvarez, as applied to claim 16 above, in further view of US 20240208445 A1 (“Abousenna”).
Per claim 19, Stefanovski further discloses:
upon authentication verification, record the third party on the blockchain to transfer ownership of the virtual vehicle to the third party for the duration of time (e.g. At 610, method 600 includes determining whether the authentication of the operator and/or digital key was successful. If at 610 it is determined that the authentication of the operator and/or digital key was successful, method 600 proceeds to 614. At 614, at the 600 includes sending details of the authentication and/or the digital key to the vehicle. The details of the authentication may include an indication that the authentication was successful. The details of the authentication may also include instructions to the vehicle to grant access to the operator) (Section [0060]- [0062]).
although Stefanovski/Sliwka/Richter/Alvarez teaches authenticating the third party before transferring ownership of the virtual vehicle, Stefanovski/Sliwka/Richter/Alvarez do not specifically disclose:
push an authentication user interface to a display within the physical vehicle;
receive an authentication of the third party from the physical vehicle.
However Abousenna, in analogous art of vehicle NFTS, discloses:
push an authentication user interface to a display within the physical vehicle (e.g. The NFT or preferably just an identifier for the NFT is transmitted to a front-end application (“app”) 14, which is provided in the motor vehicle 10. (The identifier can include an identification number for the NFT, a short name, a hash value, or the like)) (Section [0050]);
receive an authentication of the third party from the physical vehicle (e.g. Via a user interface (display as output device and actuation device), the user can see which identification the NFT or identifier indicates and in particular confirm her own identity and enter actual information. A corresponding query is then transmitted according to the arrow from 14 to 22 to the front-end application 22, the function 22f2 of which is now to legitimize access to the group of control commands (“Config file”). The function 14f2 of the front-end application 14 in the motor vehicle is to ensure the legitimacy of the displayed NFT or the NFT defined by the displayed identifier by querying and receiving a response. The query is passed on to the blockchain by the front-end application 22, so the legitimacy of the user's rights is checked according to 40f, and a corresponding answer is transmitted to the front-end application 14 via the return path via the server 24) (Section [0050]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the third party authentication verification of Stefanovski/Sliwka/Richter/Alvarez to use a display within the physical vehicle to authenticate the third party, as taught by Abousenna, in order to achieve the predictable result of providing convenience to the user by allowing them to use an interface within the vehicle to perform the authentication without needing a separate computing device.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Stefanovski/Sliwka/Richter/Alvarez, as applied to claim 16 above, in further view of US 20230298435 A1 (“Dalmia”).
Per claim 20, although Stefanovski/Sliwka/Richter/Alvarez teaches temporarily providing ownership of a physical and virtual vehicle to a third party, Stefanovski/Sliwka/Richter/Alvarez do not specifically disclose:
wherein the instructions further cause the one or more processors to record the owner of the physical vehicle on the blockchain to transfer ownership of the virtual vehicle back to the owner of the physical vehicle.
However Dalmia, in analogous art of NFTS, discloses:
wherein the instructions further cause the one or more processors to record the owner of the physical vehicle on the blockchain to transfer ownership of the virtual vehicle back to the owner of the physical vehicle (e.g. At 2212, method 2200 includes determining whether the loan value has been repaid. If the value of the loan has been repaid, method 2200 continues at 2212 where one or more transactions are executed to transfer ownership of the NFT back to the original owner. At 2214, method 2200 includes recording one or more transactions on the blockchain relating to repayment of the loan and/or the transfer of ownership back to the original owner) (Section [0492]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the temporary NFT lending system of Stefanovski/Sliwka/Richter/Alvarez to record on the blockchain the transfer of the NFT back to the original owner, as taught by Dalmia, in order to achieve the predictable result of ensuring security and transparency when changing ownership of an NFT.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Stefanovski/Sliwka/Richter/Alvarez, as applied to claim 16 above, in further view of US 12380663 B2 (“Whitman”).
Per claim 21, Sliwka further teaches:
…render the virtual vehicle in the virtual environment (e.g. For example, the user may view an inventory user interface within the game, which may present a listing of blockchain tokens (e.g., NFT representing weapons, clothing, armor, potions, scrolls, etc. for a fantasy game, NFTs representing vehicles for a racing, driving, or piloting game, or any other collectible token that may be used in a game)) (Section [1370]).
The motivation to combine Sliwka with Stefanovski/Richter is disclosed above with reference to claim 16.
although Stefanovski/Sliwka/Richter/Alvarez teaches temporarily providing ownership of a physical and virtual vehicle to a third party and rendering an operable virtual vehicle in a virtual environment, Stefanovski/Sliwka/Richter/Alvarez do not specifically disclose:
the system further comprises the display device, the display device comprising a virtual reality device, an augmented reality device, or a combination thereof;
the non-transitory computer-readable medium storing instructions that further cause the one or more processors to cause the display device to generate a virtual environment….
However Whitman, in analogous art of virtual environments, discloses:
the system further comprises the display device, the display device comprising a virtual reality device, an augmented reality device, or a combination thereof (e.g. In embodiments, the environment 400 includes a network 402 enabling communication between one or more of: a content server 404, one or more virtual reality (VR) systems 406, and one or more location-based sensor networks 408. In implementations, the VR system 406 includes a wearable headset device 410 for displaying virtual content to a user via a display indicated at 411. It should be understood that various VR systems 406 may be configured for use with embodiments of the invention, and the invention is not intended to be limited to a particular type of VR system 406. VR systems 406 for use with the implementations of the invention may include non-immersive VR systems, fully immersive VR systems, semi-immersive VR systems, and augmented or mixed reality VR systems, for example) (Column 10, Ln 32-47).
the non-transitory computer-readable medium storing instructions that further cause the one or more processors to cause the display device to generate a virtual environment… (e.g. At step 507, the VR system 406 displays the virtual content in the virtual environment 414′ to a user (e.g., via the display 411), wherein the virtual content is synchronized with physical stimuli at the physical location 414 for a period of time. In implementations, the virtual world rendering module 423 of the VR system 406 receives the selected virtual content from the synchronization module 422 of the content server 404, or from the synchronization module 422′ of the VR system 406, and renders the virtual environment 414′, including the selected content, for viewing by a user of the VR system 406) (Column 17, Ln 30-40 and Fig. 5)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the virtual gaming environment displayed by Stefanovski/Sliwka/Richter/Alvarez to use a virtual reality environment, as taught by Whitman, in order to achieve the predictable result of improving the experience for the user by creating a more immersive gaming environment.
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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to TIMOTHY SAX whose telephone number is 571-272-2935. The Examiner can normally be reached on M-F 8-4:30. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575.
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.
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.
/TPS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights