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 .
This communication is in response to the application filed on 04/25/2024. Claims 1-16 are currently pending.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 5-7, 10-12, and 15-16 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US. PGPub. No. 20220366061 to Spivack et al. (hereafter Spivack).
Regarding claim 1, Spivack discloses a system of authentication of assets (abstract, “…embodiments of the present disclosure include a method which can be implemented on a system to verify that a given physical object associated a non-fungible token on a distributed ledger network is an authentic physical object…”), (¶0099, “… The system is also able to administer, track, fingerprint, authenticate, validate the security devices, and therefore also provides capabilities to administer, track, fingerprint, authenticate, validate the association and links between NFTs and physical assets tagged with the security devices….”), comprising:
an asset tracking vehicle attached to an asset (¶0107, “a physical collectible trading card with a security device printed on it can connect that physical collectible trading card with an associated NFT. The security device on the physical collectible trading card can function as the key for control of the associated NFT and/or as title to an already minted NFT, or even to an NFT that is minted on demand and is tied to the physical collectible trading card, or even tied to each scan of the security device the physical collectible trading card…”);
a digital token stored by the asset tracking vehicle, wherein the digital token includes an identifier of the asset (¶0108, “…The door can only be unlocked by someone who is close enough to scan the security device on the door, for example. In the case of NFTs, a scan of the security device on the door and/or of the security device on the user's printed ID card or badge or pass or ticket, can initiate services related to the door, such as unlocking the door for that particular badge holder. Where this can connect to NFTs is that the badge or ID card may be represented by an NFT, and the physical instance of that badge/ID card is an authorized copy or instance of that NFT. A user of the NFT for the badge is verified as having permission to enter that door, when they authenticate the security device on their physical badge/ID as well as the security device on the door with the metadata connected to the NFT for their physical badge/ID and the permissions it grants.”);
one or more databases storing a record of the asset (¶0151, “…The parameters used to authenticate the physical tag 108 can be stored on a repository (e.g., the security device repository 322 and/or the tag identity/property repository 324 and/or the ledger address repository of FIG. 3A and/or the security device repository 122 and/or the tag identity/property repository 124 and/or the ledger address repository 126 and/or the scan log and authentication challenge repository 128 of FIG. 1, and/or the scan log and authentication challenge repository 428 of FIG. 4A)…”) (¶0152, “…The tag configuration options can also include parameters associated with the security device 108. Such parameters include, for example, width, height, text, logos, embedded metadata, etc…”), (¶0110-¶0111, “Successful verification can further enable a participating party or authorized personnel to print out a physical certificate of authenticity for the sneaker that is linked to the security device on the collectible sneaker as well. In this case, one security device on the physical certificate is linked to another security device on the sneaker itself—they are two different security devices that are linked in the database entry for that particular collectible sneaker. For example, in the database entry, the authentication metadata for the two security devices may encode a reference one another (e.g., such as a unique ID of the security device). The database entry can also include a unique identifier for the collectible sneaker (e.g., the sneaker SKU). The Certificate of Authenticity (COA) is then represented by/is embodied in the NFT that is tied to the physical collectible sneaker. Ownership of that NFT therefore also confers ownership of the COA and the ability to generate a new COA at any time for anyone on request…A deed or title printed from an NFT can have a security device on it to verify the authenticity of that item. The printed deed has a security device on it that links it as an authorized certificate of, or instance of, the NFT. The physical instance provides an easy way for other people to verify the authenticity and ownership of the NFT via things in the physical world (e.g. the printed certificate which can be scanned with the phone)…”), a record of one or more entities associated with the asset, and a record of one or more past transactions associated with the asset (¶0283, “… a transaction is recorded (e.g., by the telemetry identifier 332 and/or the time proof engine 334 of the integration engine 330 of the host server 300 shown in the example of FIG. 3A) in the distributed ledger in the decentralized network. The transaction can include a valid response to the authentication prompt and the first block hash…”), see also ¶0143;
a computing device including a software application, wherein the software application is configured (¶0091, “FIG. 10 is a block diagram illustrating an example of a software architecture that may be installed on a machine, in accordance with embodiments of the present disclosure.”), (¶0493 “FIG.10 is a block diagram 1000 illustrating an architecture of software 1002, which can be installed on any one or more of the devices described above. FIG. 10 is a non-limiting example of a software architecture, and it will be appreciated that many other architectures can be implemented to facilitate the functionality described herein….”) to: (¶0497, “Specifically, FIG. 11 shows a diagrammatic representation of the machine 1100 in the example form of a computer system, within which instructions 1016 (e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine 1000 to perform any one or more of the methodologies discussed herein can be executed…”), (¶0238, “…The client device 402 can also include any combination of hardware components and/or software agents for performing one or more of the processes related to administering, reading, generating, implementing/specifying, inspecting, fingerprinting, authenticating, verifying, provisioning, scanning, detecting, decoding, identifying, tracking, deploying security devices and/or retrieving relevant data from security devices.”)
read or communicate with the asset tracking vehicle (¶0238, “…The client device 402 can also include any combination of hardware components and/or software agents for performing one or more of the processes related to administering, reading, generating, implementing/specifying, inspecting, fingerprinting, authenticating, verifying, provisioning, scanning, detecting, decoding, identifying, tracking, deploying security devices and/or retrieving relevant data from security devices”);
determine the identifier of the asset stored by the digital token (¶0110, “…The database entry can also include a unique identifier for the collectible sneaker (e.g., the sneaker SKU). The Certificate of Authenticity (COA) is then represented by/is embodied in the NFT that is tied to the physical collectible sneaker. Ownership of that NFT therefore also confers ownership of the COA and the ability to generate a new COA at any time for anyone on request.”), (¶0213-¶0214, “…The physical asset can include any physical object such as, printed materials, physical advertising and marketing materials, physical currencies/cash or securities instruments, commodities, IDs and badges, physical artworks, collectibles, physical certificates, antique items, wearable items, textiles, furniture, architectural objects or features of such objects (like a door or a wall), vehicles, tools, inventory, containers, packaging, collectible trading cards, beverage containers, consumer electronics products, etc.”), (¶0209, “…The physical instance of the security tag is adapted to be affixed to or attached to or otherwise be physically associated with the physical asset that is to be uniquely associated with a digital asset (e.g., non-fungible asset, non-fungible token).”), (¶0118, “…A security device can also be used to provide a physical certificate or deed for a virtual object. In this use case, the security device on the physical object can be linked to information about the same security device that is embedded and encoded into an associated virtual object (e.g., into an NFT associated with the virtual object). For example, a user can purchase a digital collectible in the form of a virtual object, and within that virtual object is information about authorized physical printed certificates or deeds on other physical items linked to that virtual object. By scanning any printed certificates that has a security device, it can be determined whether those are authorized items for a given NFT. This process can be initiated from a user interacting with the virtual object, or from a user interacting with a physical certificate or deed that is associated with that virtual object.”);
retrieve, through a network connection, from the one or more databases storing the record of the asset, one or more currently authorized entities associated with the asset (¶0015, “…NFTs are created by stringing records of cryptographic hashed onto previous records thereby creating a chain of identifiable data blocks in the distributed ledger. This cryptographic process ensures authenticity by providing a digital signature that is used to track NFT ownership. The unique identity and ownership of an NFT is verifiable via the distributed ledger and ownership of an NFT is often associated with an underlying digital asset.”), (¶0098, “…Any situation requiring authentication of physical objects or performing an operation on (e.g., transacting, exchanging, transferring, etc.) either the physical object or NFT, can be deployed. In such applications, where the unique identity and ownership of a NFT is verifiable via the distributed ledger network on which it is deployed, the link of the physical asset and the NFT can be established by the disclosed system.”); and
determine whether a current holder of the asset is one of the one or more currently authorized entities associated with the asset (¶0202-¶0203, “the system can generate and transmit a query to any user device/scan device that is registered to the security device (including user devices of the current owner, any other registered or authorized users, or any user device that has recently scanned the security device)… the security device can authenticate the physical asset to establish that it is an authorized printout or copy of the associated NFT. Additionally, scanning the security device can be part of a multifactor authentication or security process, for example to prove possession of and/or control of the physical asset and/or the associated NFT of that security device…”).
Regarding claim 2, Spivack discloses the system of claim 1, wherein the digital token is a non-fungible token (NFT) (¶0146, “… Custom tokens can be non-fungible tokens (NFT) which are also cryptographic tokens…”).
Regarding claim 5, Spivack discloses the system of claim 1, wherein the asset tracking vehicle includes a physical token storing the digital token (¶0108, “…Where this can connect to NFTs is that the badge or ID card may be represented by an NFT, and the physical instance of that badge/ID card is an authorized copy or instance of that NFT. A user of the NFT for the badge is verified as having permission to enter that door, when they authenticate the security device on their physical badge/ID as well as the security device on the door with the metadata connected to the NFT for their physical badge/ID and the permissions it grants.”).
Regarding claim 6, Spivack discloses the system of claim 5, wherein the physical token is one of: a Near-Field Communication (NFC) chip, a radio frequency identification (RFID) chip, a QR code, or a barcode (¶0503, “the communication components 1164 can include Radio Frequency Identification (RFID) tag reader components, NFC smart tag detection components, optical reader components (e.g., an optical sensor to detect one-dimensional bar codes such as a Universal Product Code (UPC) bar code, multi-dimensional bar codes such as a Quick Response (QR) code…”).
Regarding claim 7, Spivack discloses a computer implemented method of authenticating ownership of an asset, comprising:
reading, by a computing device, a digital token attached to the asset (¶0203, “…If a physical asset has a security device on it, where the security device is connected to/registered with one or more NFTs, then authentication events on that security device can be used to trigger various operations on and/or manipulations of the associated NFT(s). For example, scanning (e.g., including imaging/reading) the security device can authenticate the physical asset to establish that it is an authorized printout or copy of the associated NFT…”), see also ¶0237, ¶0239.;
determining, by a processor in the computing device, identifier information and holder information of the asset from the digital token (¶0107-¶0108, “…The door can only be unlocked by someone who is close enough to scan the security device on the door, for example. In the case of NFTs, a scan of the security device on the door and/or of the security device on the user's printed ID card or badge or pass or ticket, can initiate services related to the door, such as unlocking the door for that particular badge holder. Where this can connect to NFTs is that the badge or ID card may be represented by an NFT, and the physical instance of that badge/ID card is an authorized copy or instance of that NFT. A user of the NFT for the badge is verified as having permission to enter that door, when they authenticate the security device on their physical badge/ID as well as the security device on the door with the metadata connected to the NFT for their physical badge/ID and the permissions it grants.”), (¶0110, “…The database entry can also include a unique identifier for the collectible sneaker (e.g., the sneaker SKU). The Certificate of Authenticity (COA) is then represented by/is embodied in the NFT that is tied to the physical collectible sneaker. Ownership of that NFT therefore also confers ownership of the COA and the ability to generate a new COA at any time for anyone on request.”);
using an immutable ledger, retrieving from a database, a record of ownership of the asset (¶0015, “…NFTs are created by stringing records of cryptographic hashed onto previous records thereby creating a chain of identifiable data blocks in the distributed ledger. This cryptographic process ensures authenticity by providing a digital signature that is used to track NFT ownership. The unique identity and ownership of an NFT is verifiable via the distributed ledger and ownership of an NFT is often associated with an underlying digital asset.”), (¶0098, “…Any situation requiring authentication of physical objects or performing an operation on (e.g., transacting, exchanging, transferring, etc.) either the physical object or NFT, can be deployed. In such applications, where the unique identity and ownership of a NFT is verifiable via the distributed ledger network on which it is deployed, the link of the physical asset and the NFT can be established by the disclosed system.”), (¶0111, “A deed or title printed from an NFT can have a security device on it to verify the authenticity of that item. The printed deed has a security device on it that links it as an authorized certificate of, or instance of, the NFT. The physical instance provides an easy way for other people to verify the authenticity and ownership of the NFT via things in the physical world (e.g. the printed certificate which can be scanned with the phone). Printed deeds and title are documented with unique security device on them and can also be used as parts of multi-key systems to provide permission to operate or transfer title for an NFT and/or the physical item, where in order to complete an operation the security device is scanned first for perform relevant verification process.”); and
verifying by the processor whether a holder of the asset, is an authenticated, current owner of the asset (¶0114, “A remote user can request authentication of a physical item from the present owner/other authorized agent/broker of a particular NFT. The disclosed system can query a user ID of the present owner of the physical item with the security device. on it, to authenticate the physical item (with an optional expiration date on that request for authentication). If the owner successfully authenticates the security device, for example, within the required time (and even optionally from the right place, and/or with other associated tests that can be required like responding to a two-factor authentication request on another channel as well), then the party who issued the query can be informed that the physical item has been successfully verified by that owner user ID—and from there the parties can interact further to communicate and/or transact with the physical item.”), (¶0146, “….This cryptographic transaction process ensures the authentication of each digital file by providing a digital signature that is used to track NFT ownership and other NFT attributes. The unique identity and ownership of an NFT is verifiable via the distributed ledger networks 140 on which it is deployed.”), (¶0254, “…At the request of the relevant party, the owner (or other authorized operator/agent) is prompted to scan the security device to prove they have the authentic physical object. A positive or negative authentication result is confirmed to requesting party (e.g. a buyer). The requesting party can also request live video inspection and live security device authentication if they wish to, using the application and a live video chat or stream. After a positive authentication result, the process can proceed into the next step to complete the operation of transaction among the parties…”)
Regarding claim 10, Spivack discloses the method of claim 7, further comprising:
in an event the holder is not verified, declining an authentication of the asset (¶0108, “…In the case of NFTs, a scan of the security device on the door and/or of the security device on the user's printed ID card or badge or pass or ticket, can initiate services related to the door, such as unlocking the door for that particular badge holder. Where this can connect to NFTs is that the badge or ID card may be represented by an NFT, and the physical instance of that badge/ID card is an authorized copy or instance of that NFT. A user of the NFT for the badge is verified as having permission to enter that door, when they authenticate the security device on their physical badge/ID as well as the security device on the door with the metadata connected to the NFT for their physical badge/ID and the permissions it grants.”); and
tracking a location of the asset in response to the declination of authentication (¶0458-¶0460, “One embodiment of the present disclosure includes integration of the system with location tracking (e.g., by the integration engine 330 of the host server 300 shown in the example of FIG. 3A). Given a Blocktag with a known latitude and longitude, the authenticated proof-of-presence distance between the Blocktag and a user's scan device can be plotted as a locus of points on a digital map. This features solves the following challenges… A user can mask their physical location and IP address on their computing device using Virtual Private Networks (VPN). Blocktag's proof-of-presence system unmasks users' location even if users are using VPN on the scan devices. This can for instance, enable companies to track employee's remote work physical locations.”)
Regarding claim 11, Spivack discloses the method of claim 7, wherein the digital token is a non-fungible token (NFT) (¶0146, “… Custom tokens can be non-fungible tokens (NFT) which are also cryptographic tokens…”).
Regarding claim 12, Spivack discloses a computer program product (¶0499, “…while embodiments have been described in the context of fully functioning computers and computer systems, those skilled in the art will appreciate that the various embodiments are capable of being distributed as a program product in a variety of forms…”) for authenticating ownership of an asset (abstract, “…embodiments of the present disclosure include a method which can be implemented on a system to verify that a given physical object associated a non-fungible token on a distributed ledger network is an authentic physical object…”), (¶0015, “… This cryptographic process ensures authenticity by providing a digital signature that is used to track NFT ownership. The unique identity and ownership of an NFT is verifiable via the distributed ledger and ownership of an NFT is often associated with an underlying digital asset.”), the computer program product comprising:
one or more non-transitory computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media (¶0497-¶0498, “… The memory/storage 1130 can include a main memory 1132, a static memory 1134, or other memory storage, and a storage unit 1136, both accessible to the processors 1110 such as via the bus 1102. The storage unit 1136 and memory 1132 store the instructions 1116 embodying any one or more of the methodologies or functions described herein. The instructions 1116 can also reside, completely or partially, within the memory 1132, within the storage unit 1136, within at least one of the processors 1110 (e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine 1100. Accordingly, the memory 1132, the storage unit 1136, and the memory of the processors 1110 are examples of machine-readable media…”), the program instructions comprising:
reading, by a computing device, a digital token attached to the asset (¶0203, “…If a physical asset has a security device on it, where the security device is connected to/registered with one or more NFTs, then authentication events on that security device can be used to trigger various operations on and/or manipulations of the associated NFT(s). For example, scanning (e.g., including imaging/reading) the security device can authenticate the physical asset to establish that it is an authorized printout or copy of the associated NFT…”), see also ¶0237, ¶0239;
determining, by a processor in the computing device, identifier information and holder information of the asset from the digital token (¶0107-¶0108, “…The door can only be unlocked by someone who is close enough to scan the security device on the door, for example. In the case of NFTs, a scan of the security device on the door and/or of the security device on the user's printed ID card or badge or pass or ticket, can initiate services related to the door, such as unlocking the door for that particular badge holder. Where this can connect to NFTs is that the badge or ID card may be represented by an NFT, and the physical instance of that badge/ID card is an authorized copy or instance of that NFT. A user of the NFT for the badge is verified as having permission to enter that door, when they authenticate the security device on their physical badge/ID as well as the security device on the door with the metadata connected to the NFT for their physical badge/ID and the permissions it grants.”), (¶0110, “…The database entry can also include a unique identifier for the collectible sneaker (e.g., the sneaker SKU). The Certificate of Authenticity (COA) is then represented by/is embodied in the NFT that is tied to the physical collectible sneaker. Ownership of that NFT therefore also confers ownership of the COA and the ability to generate a new COA at any time for anyone on request.”);
using an immutable ledger, retrieving from a database, a record of ownership of the asset (¶0015, “…NFTs are created by stringing records of cryptographic hashed onto previous records thereby creating a chain of identifiable data blocks in the distributed ledger. This cryptographic process ensures authenticity by providing a digital signature that is used to track NFT ownership. The unique identity and ownership of an NFT is verifiable via the distributed ledger and ownership of an NFT is often associated with an underlying digital asset.”), (¶0098, “…Any situation requiring authentication of physical objects or performing an operation on (e.g., transacting, exchanging, transferring, etc.) either the physical object or NFT, can be deployed. In such applications, where the unique identity and ownership of a NFT is verifiable via the distributed ledger network on which it is deployed, the link of the physical asset and the NFT can be established by the disclosed system.”), (¶0111, “A deed or title printed from an NFT can have a security device on it to verify the authenticity of that item. The printed deed has a security device on it that links it as an authorized certificate of, or instance of, the NFT. The physical instance provides an easy way for other people to verify the authenticity and ownership of the NFT via things in the physical world (e.g. the printed certificate which can be scanned with the phone). Printed deeds and title are documented with unique security device on them and can also be used as parts of multi-key systems to provide permission to operate or transfer title for an NFT and/or the physical item, where in order to complete an operation the security device is scanned first for perform relevant verification process.”); and
verifying by the processor, whether a holder of the asset, is an authenticated, current owner of the asset (¶0114, “A remote user can request authentication of a physical item from the present owner/other authorized agent/broker of a particular NFT. The disclosed system can query a user ID of the present owner of the physical item with the security device. on it, to authenticate the physical item (with an optional expiration date on that request for authentication). If the owner successfully authenticates the security device, for example, within the required time (and even optionally from the right place, and/or with other associated tests that can be required like responding to a two-factor authentication request on another channel as well), then the party who issued the query can be informed that the physical item has been successfully verified by that owner user ID—and from there the parties can interact further to communicate and/or transact with the physical item.”), (¶0146, “….This cryptographic transaction process ensures the authentication of each digital file by providing a digital signature that is used to track NFT ownership and other NFT attributes. The unique identity and ownership of an NFT is verifiable via the distributed ledger networks 140 on which it is deployed.”), (¶0254, “…At the request of the relevant party, the owner (or other authorized operator/agent) is prompted to scan the security device to prove they have the authentic physical object. A positive or negative authentication result is confirmed to requesting party (e.g. a buyer). The requesting party can also request live video inspection and live security device authentication if they wish to, using the application and a live video chat or stream. After a positive authentication result, the process can proceed into the next step to complete the operation of transaction among the parties…”).
Regarding claim 15, Spivack discloses the computer program product of claim 12,
wherein the program instructions further comprise:
in an event the holder is not verified, declining an authentication of the asset (¶0108, “…In the case of NFTs, a scan of the security device on the door and/or of the security device on the user's printed ID card or badge or pass or ticket, can initiate services related to the door, such as unlocking the door for that particular badge holder. Where this can connect to NFTs is that the badge or ID card may be represented by an NFT, and the physical instance of that badge/ID card is an authorized copy or instance of that NFT. A user of the NFT for the badge is verified as having permission to enter that door, when they authenticate the security device on their physical badge/ID as well as the security device on the door with the metadata connected to the NFT for their physical badge/ID and the permissions it grants.”); and
tracking a location of the asset in response to the declination of authentication (¶0458-¶0460, “One embodiment of the present disclosure includes integration of the system with location tracking (e.g., by the integration engine 330 of the host server 300 shown in the example of FIG. 3A). Given a Blocktag with a known latitude and longitude, the authenticated proof-of-presence distance between the Blocktag and a user's scan device can be plotted as a locus of points on a digital map. This features solves the following challenges… A user can mask their physical location and IP address on their computing device using Virtual Private Networks (VPN). Blocktag's proof-of-presence system unmasks users' location even if users are using VPN on the scan devices. This can for instance, enable companies to track employee's remote work physical locations.”)
Regarding claim 16, Spivack discloses the computer program product of claim 12, wherein the digital token is a non-fungible token (NFT) (¶0146, “… Custom tokens can be non-fungible tokens (NFT) which are also cryptographic tokens…”).
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 3-4, 8-9, and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPub. No. 20220366061 to Spivack et al. (hereafter Spivack) in view of US PGPub. No. 20210133713 to WANG et al. (hereinafter WANG).
Regarding claim 3, Spivack discloses the system of claim 1.
However, Spivack does not explicitly disclose wherein the software application is further configured to:
acknowledge a transfer in ownership of the asset; and
authenticate the transfer in ownership through the blockchain.
WANG discloses:
acknowledge a transfer in ownership of the asset (¶0022, “…The system includes an ownership issuing host 120 and a use-right issuing host 130…”), (¶0027, “The transaction module 133 is connected to the issuing module 132. After the owner approves to set the use-right transfer condition, the transaction module 133 can permit the asset smart contract to receive the digital currency as proceeds, and transfer the use-right token from the asset smart contract to a buyer account, and set the user information to the buyer account….”); and
authenticate the transfer in ownership through the blockchain (¶0027, “The transaction module 133 is connected to the issuing module 132. After the owner approves to set the use-right transfer condition, the transaction module 133 can permit the asset smart contract to receive the digital currency as proceeds, and transfer the use-right token from the asset smart contract to a buyer account, and set the user information to the buyer account…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the invention of Spivack to include authenticating transfer of asset ownership as disclosed by WANG and be motivated in doing so in order to change the usage information from the address of the asset smart contract to the buyer account-WANG ¶0027 in parts.
Regarding claim 4, Spivack in view of WANG discloses the system of claim 3.
WANG further discloses the system of claim 3, wherein the software application is further configured to update, via the one or more databases, an ownership status of the asset in response to the transfer of ownership (¶0027, “and when the use right is first transferred, the usage information is changed from the address of the asset smart contract to the buyer account (update)…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the invention of Spivack and WANG to include updating asset ownership transfer as disclosed by WANG and be motivated in doing so in order to ensure legal validity of the asset and facilitate tax benefits and proper estate planning.
Regarding claim 8, Spivack discloses the method of claim 7.
However, Spivack does not explicitly disclose wherein the software application is further configured to:
acknowledging a transfer in ownership of the asset; and
authenticating the transfer in ownership through the blockchain.
WANG discloses:
acknowledge a transfer in ownership of the asset (¶0022, “…The system includes an ownership issuing host 120 and a use-right issuing host 130…”), (¶0027, “The transaction module 133 is connected to the issuing module 132. After the owner approves to set the use-right transfer condition, the transaction module 133 can permit the asset smart contract to receive the digital currency as proceeds, and transfer the use-right token from the asset smart contract to a buyer account, and set the user information to the buyer account….”); and
authenticate the transfer in ownership through the blockchain (¶0027, “The transaction module 133 is connected to the issuing module 132. After the owner approves to set the use-right transfer condition, the transaction module 133 can permit the asset smart contract to receive the digital currency as proceeds, and transfer the use-right token from the asset smart contract to a buyer account, and set the user information to the buyer account…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the invention of Spivack to include authenticating transfer of asset ownership as disclosed by WANG and be motivated in doing so in order to change the usage information from the address of the asset smart contract to the buyer account-WANG ¶0027 in parts.
Regarding claim 9, Spivack in view of WANG discloses the method of claim 8.
WANG further discloses the system of claim 3, wherein the software application is further configured to updating, via the one or more databases, an ownership status of the asset in response to the transfer of ownership (¶0027, “and when the use right is first transferred, the usage information is changed from the address of the asset smart contract to the buyer account (update)…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the invention of Spivack and WANG to include updating asset ownership transfer as disclosed by WANG and be motivated in doing so in order to ensure legal validity of the asset and facilitate tax benefits and proper estate planning.
Regarding claim 8, Spivack discloses the computer program product of claim 12.
However, Spivack does not explicitly disclose wherein the software application is further configured to:
acknowledging a transfer in ownership of the asset; and
authenticating the transfer in ownership through the blockchain.
WANG discloses:
acknowledging a transfer in ownership of the asset (¶0022, “…The system includes an ownership issuing host 120 and a use-right issuing host 130…”), (¶0027, “The transaction module 133 is connected to the issuing module 132. After the owner approves to set the use-right transfer condition, the transaction module 133 can permit the asset smart contract to receive the digital currency as proceeds, and transfer the use-right token from the asset smart contract to a buyer account, and set the user information to the buyer account….”); and
authenticating the transfer in ownership through the blockchain (¶0027, “The transaction module 133 is connected to the issuing module 132. After the owner approves to set the use-right transfer condition, the transaction module 133 can permit the asset smart contract to receive the digital currency as proceeds, and transfer the use-right token from the asset smart contract to a buyer account, and set the user information to the buyer account…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the invention of Spivack to include authenticating transfer of asset ownership as disclosed by WANG and be motivated in doing so in order to change the usage information from the address of the asset smart contract to the buyer account-WANG ¶0027 in parts.
Regarding claim 14, Spivack in view of WANG discloses the computer program product the of claim 13.
WANG further discloses the system of claim 3, wherein the software application is further configured to updating, via the one or more databases, an ownership status of the asset in response to the transfer of ownership (¶0027, “and when the use right is first transferred, the usage information is changed from the address of the asset smart contract to the buyer account (update)…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the invention of Spivack and WANG to include updating asset ownership transfer as disclosed by WANG and be motivated in doing so in order to ensure legal validity of the asset and facilitate tax benefits and proper estate planning.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached at 5712723739. 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.
/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495