DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the application filed on 05/19/2026.
Claims 1-20 are currently pending in this application.
Response to Arguments
Applicant’s argues on pages 8-9 that Braendgaard in view of Doney fails to teach “a PII transmission service of the first virtual asset service provider” as recited in amended claims 1, 12, and 20.
The examiner respectfully disagrees. Braendgaard teaches a PII transmission service of the first virtual asset service provider ([0028], [0039-0040], [0047], [0098]). Braendgaard defines its entities as VASPs, and for each individual VASP, the management platform assigns a dedicated repository to that VASP, stores that VASP’s user PII in the repository assigned to it, provides a dedicated interface coupled to that VASP, and generates a communication channel particular to that VASP through which the PII is exchanged ([0040], [0047], [0098]). One of ordinary skill in the art would recognize that a repository, interface, and channel assigned to and dedicated to the first VASP, and storing that VASP’s user PII, is a PII transmission service of the first VASP. The applicant’s argument that the platform’s relationship to the first VASP is indistinguishable from its relationship to any other entity does not negate this teaching because Braendgaard assigns each VASP its own dedicated repository, interface, and channel ([0040], [0047], [0098]).
The examiner further notes that the limitation “of the first virtual asset service provider” which requires a service dedicated to the first VASP is satisfied by Braendgaard’s repository assigned to the entity and interface coupled to the first entity ([0047], [0098]).
Applicant further argues on pages 9-11 of applicant’s remarks that Braendgaard in view of Doney fails to teach “transmitting an indication of the encrypted PII stored at the database of the PII transmission service and accessible by the second virtual asset service provider” as recited in amended claims 1, 12, and 20.
The examiner respectfully disagrees. Doney teaches transmitting an indication of the encrypted PII accessible by the second virtual asset service provider ([0074], [0080], [0082]). Doney’s issuing VASP issues an AuthToken, contains the DataID pointer and AccessKey ([0074]), to the recipient VASP who will have access to the data when a qualifying transaction occurs ([0080]), and the recipient VASP uses the token to access and decrypt the encrypted data ([0082]). The examiner notes that the applicant’s characterization of Doney’s DataID as merely an internal storage reference that cannot render the encrypted PII accessible by the receiving VASP is not persuasive. Although the DataID is a pointer to the stored encrypted data, Doney does not maintain the DataID solely within the data host, but rather the DataID pointer is incorporated into the AuthToken ([0074]), and the AuthToken is issued to and transmitted to the recipient VASP ([0080]). The recipient VASP then uses the AuthToken, containing the DataID pointer and AccessKey to locate, retrieve, and decrypt the encrypted data ([0082]). Therefore, the DataID is not merely an internal reference as it is transmitted to the second VASP and is the pointer by which the second VASP assesses the encrypted PII, which reads on the claimed indication that renders the encrypted PII accessible by the second virtual asset provider.
The examiner further notes that the applicant’s argument that Doney’s access is “conditional” and “multi-step” is not a distinction over the claims, which recite that the requested blockchain transfer is executed based at least in part on securely transmitting the indication of the encrypted PII. One of ordinary skill in the art would recognize that the claims do not require any particular degree of immediacy or any single-step access, but require only that the transmitted indication render the encrypted PII accessible by the second VASP, which Doney’s AuthToken mechanism provides ([0080], [0082]).
The examiner further notes that the applicant’s argument that the stated motivation to combine “underscores this deficiency” is not persuasive. The applicant's argument is premised on the position that conditional access cannot satisfy the claimed accessibility; however, the limitation requires only that the transmitted indication render the encrypted PII accessible by the second VASP, and do not require that such access be unconditional. One of ordinary skill in the art would recognize that Doney's release of the encrypted PII to the recipient VASP upon a qualifying transaction renders the PII accessible by the second VASP ([0080], [0082]).
Therefore, Braendgaard in view of Doney teaches the limitation of the claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Braendgaard et al. US 20250168149 (using US provisional date) hereinafter referred to as Braendgaard in view of Doney US 20230360042 hereinafter referred to as Doney.
As per claim 1, Braendgaard teaches a method for secure exchange of personally identifiable information (PII), comprising: receiving, from a first virtual asset service provider and at a PII transmission service of the first virtual asset service provider, a request to securely transfer PII of a first user of the first virtual asset service provider to a second virtual asset service provider, wherein the request includes the PII and is received based at least in part on a requested blockchain transfer of an amount of a crypto token from a first blockchain address of the first user and managed by the first virtual asset service provider to a second blockchain address managed by the second virtual asset service provider (Braendgaard [0018], [0028], [0032], [0040], [0047], [0056], [0098], [0135], [0137]: the management platform constitutes a PII transmission service, entities constitute VASPs, and an identifier constitute the PII of the user where it is encrypted and transferred to the second entity as a first encrypted message which contains the PII and transfer of virtual assets – a request to transfer, see e.g., “a management platform—can execute Blocks… to establish communication links with a set of entities… to receive entity information… to generate a secure communication channel between the first entity and the second entity… a first entity e.g., a first VASP, in the set of entities, receives user information e.g., personally identifiable information, a full name, a physical address, a birthdate—associated with a first user in a first set of user… the first entity executes a request—from the first user device associated with the first user—for a transfer of a virtual asset or an amount of the virtual asset from the first blockchain address to a second blockchain address, such as a second blockchain address associated with a second user and hosted by a second entity e.g., a second VASP… management platform generates a communication channel… which a set of transaction information, associated with a transfer of a virtual asset, may be exchanged… for each entity in the set of entities, the management platform can: assign a data repository, in a set of data repositories, to the entity; encrypt entity information associated with the entity as encrypted entity information; and store the encrypted entity information in the data repository assigned to the entity… a first interface… communicatively coupled to the first entity e.g., via the first communication link between the management platform and the first entity… an identifier e.g., a full name, an identification number of a user… store the encrypted identifier in the data repository… first message representing the transaction information, such as: the virtual asset type; the amount of the virtual asset to transfer; the first user identifier of the first user as the originator user… management platform can encrypt the first message as a first encrypted message… management platform can transmit the first encrypted message to the second entity”);
encrypting the PII after receiving the request (Braendgaard [0039], [0056], [0135], [0137]: entities constitute VASPS and the PII is being encrypted and transferred to the second entity with the transfer of an amount of virtual assets, “the management platform… establish or generate communication links with entities in the set of entities… receive an identifier e.g., a full name, an identification number of a user… encrypt the identifier as an encrypted identifier… first message representing the transaction information, such as: the virtual asset type; the amount of the virtual asset to transfer; the first user identifier of the first user as the originator user… the management platform can transmit the first encrypted message to the second entity”);
storing the encrypted PII of the first user at a database associated with the PII transmission service (Braendgaard [0056]: “management platform can… store the encrypted identifier in the data repository”);
and securely transmitting encrypted PII stored at the database of the PII transmission service (Braendgaard [0056], [0135], [0137]: “an identifier e.g., a full name, an identification number of a user… store the encrypted identifier in the data repository… first message representing the transaction information, such as: the virtual asset type; the amount of the virtual asset to transfer; the first user identifier of the first user as the originator user… management platform can encrypt the first message as a first encrypted message… management platform can transmit the first encrypted message to the second entity”).
Braendgaard does not explicitly disclose securely transmitting an indication of the encrypted PII stored at the database of the PII transmission service and accessible by the second virtual asset service provider.
Doney teaches securely transmitting an indication (Doney [0071], [0074]: AuthToken – includes DataID pointer which constitutes an indication) of the encrypted PII stored at the database of the PII transmission service and accessible by the second virtual asset service provider (Doney [0017], [0071-0077], [0080]: encrypted PII is sent to a data store, the data host
generates a pointer that constitutes an indication to the encrypted PII, AuthToken contains the DataID pointer and AccessKey – provides means to decrypt. Issuing VASP issues AuthToken to recipient VASP who will have access to the PII data).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Braendgaard of a management
platform that sends encrypted PII to a second entity with the teachings of Doney to include
substituting the encrypted PII with a DataID pointer that points to the encrypted PII in a
database and sending it to a second VASP in order to use a cryptographic hash pointer to create
a tamper-proof data set (Doney [0078]) and data access tokens to securely and conditionally
manage access to PII by ensuring only authorized parties can view the sensitive data (Doney [0084]).
As per claim 2, Braendgaard in view of Doney teaches the method of claim 1, wherein securely transmitting the indication of the encrypted PII comprises:
establishing, with a second instance of the PII transmission service associated with the second virtual asset service provider, a secure connection (Braendgaard [0046-0047]: management platform operates multiple instances “management platform can: identify entities—in the set of entities—to each other; establish communication channels between these entities… management platform stores entity information for each entity in the set of entities”);
and transferring, via the secure connection, the PII of the first user to the second instance of the PII transmission service associated with the second virtual asset service provider (Braendgaard [0018], [0135], [0137]: encrypted message contains identifier of the user and entities constitute VASPs, see e.g., “management platform —can execute Blocks… to generate a
secure communication channel between the first entity and the second entity… management
platform can transmit the first encrypted message to the second entity”).
As per claim 3, Braendgaard in view of Doney teaches the method of claim 2, wherein
the secure connection is established based at least in part on the first virtual asset service
provider and the second virtual asset service provider being associated with the PII
transmission service (Braendgaard [0018]: “management platform —can execute Blocks… to
generate a secure communication channel between the first entity and the second entity”).
As per claim 4, Braendgaard in view of Doney teaches the method of claim 1, wherein
securely transmitting the indication of the encrypted PII comprises: transmitting, to the first
virtual asset service provider, a link (Doney [0071], [0074]: AuthToken – includes DataID pointer
which constitutes a link) to the encrypted PII stored at the database of the PII transmission
service and accessible by the second virtual asset service provider (Doney [0017], [0071-0077],
[0080]: encrypted PII is sent to a data store, the data host generates a pointer that constitutes a
link to the encrypted PII, AuthToken contains the DataID pointer and AccessKey – provides
means to decrypt. Issuing VASP issues AuthToken to recipient VASP who will have access to the
PII data).
As per claim 6, Braendgaard in view of Doney teaches the method of claim 1, further comprising: receiving, from the first virtual asset service provider and at the PII transmission service, a second request to securely receive second PII from a third virtual asset service provider (Braendgaard [FIG. 1]: shows a third VASP and blockchain addresses corresponding to that VASP), wherein the second request is received based at least in part on a second requested blockchain transfer of a second amount of a second crypto token to a third blockchain address managed by the first virtual asset service provider and from a fourth blockchain address managed by the third virtual asset service provider (Braendgaard [0018], [0028], [0032], [0056], [0135], [0137]: the management platform constitutes a PII transmission service, entities constitute VASPs, and an identifier constitute the PII of the user where it is encrypted and transferred to the second entity as a first encrypted message which contains the PII and transfer of virtual assets – a request to transfer, see e.g., “a management platform—can execute Blocks… to establish communication links with a set of entities… to receive entity information… to generate a secure communication channel between the first entity and the second entity… a first entity e.g., a first VASP, in the set of entities, receives user information e.g., personally identifiable information, a full name, a physical address, a birthdate—associated with a first user in a first set of user… the first entity executes a request—from the first user device associated with the first user—for a transfer of a virtual asset or an amount of the virtual asset from the first blockchain address to a second blockchain address, such as a second blockchain address associated with a second user and hosted by a second entity e.g., a second VASP… an identifier e.g., a full name, an identification number of a user… store the encrypted identifier in the data repository… first message representing the transaction information, such as: the virtual asset type; the amount of the virtual asset to transfer; the first user identifier of the first user as the originator user… management platform can encrypt the first message as a first encrypted message… management platform can transmit the first encrypted message to the second entity”);
and transmitting, to the first virtual asset service provider, a second link (Doney [0071], [0074]: AuthToken – includes DataID pointer which constitutes an indication) to the PII
transmission service and accessible by the third virtual asset service provider to input the
second PII (Braendgaard [FIG. 1]: shows a third VASP; Doney [0017], [0071-0077], [0080]:
encrypted PII is sent to a data store, the data host generates a pointer that constitutes an
indication to the encrypted PII, AuthToken contains the DataID pointer and AccessKey –
provides means to decrypt. Issuing VASP issues AuthToken to recipient VASP who will have
access to the PII data).
As per claim 7, Braendgaard in view of Doney teaches the method of claim 6, further comprising: receiving, after transmitting the second link, the second PII from the third virtual asset service provider (Braendgaard [FIG. 1]: third VASP; Doney [0086]: each VASP gets access to counterparty’s PII, see e.g., “Information in the form of file 1, is transmitted to data host 230 by an Originator VASP and information, in the form of file 2, is transmitted to data host 230 by a
Recipient VASP. Upon a completed transaction… the information is made available to the counterparty VASP);
encrypting the second PII from the third virtual asset service provider after receiving the second PII via the second link (Braendgaard [0056]: encrypts after receiving an identifier, see
e.g., “identifier e.g., a full name, an identification number… encrypt the identifier as an
encrypted identifier”; Doney [0071], [0074]: AuthToken – includes DataID pointer which
constitutes a link);
and storing the encrypted second PII from the third virtual asset service provider
(Braendgaard [FIG. 1]: third VASP) at the database associated with the PII transmission service
(Braendgaard [0056]: “management platform can… store the encrypted identifier in the data
repository”).
As per claim 8, Braendgaard in view of Doney teaches the method of claim 1, wherein the requested blockchain transfer of the amount of the crypto token is executed via a blockchain network based at least in part on securely transmitting the indication of the
encrypted PII (Braendgaard [0032]: “first entity: generates a transaction representing the
transfer of the virtual asset from the first blockchain address to the second blockchain address;
and transmits—via the communication network”; Doney [0071]: encrypted PII is sent to a data
store, the data host generates a pointer to the encrypted PII, AuthToken contains this DataID
pointer and AccessKey – provides means to decrypt. AuthToken is transmitted to recipient
VASP who will have access to the PII data).
As per claim 9, Braendgaard in view of Doney teaches the method of claim 1, wherein
the request to securely transfer the PII is based at least in part on a geographic region of the
first user (Braendgaard [0036]: screening a user for sanctions relates to the location of the first
user “receive a request for a transfer of a virtual asset… screen the request for a sanctioned
user… screen the first user as a possible sanctioned user… execute a transaction representing
the transfer… complying with jurisdictional regulations”).
As per claim 10, Braendgaard in view of Doney teaches the method of claim 1, wherein
the PII comprises information indicative of the first user that is an owner of the first blockchain
address (Braendgaard [0029]: “receiving and verifying the user information, the first entity can: store the user information in a data repository e.g., a first user database; and assign a first
blockchain address or a first set of blockchain addresses to the first user”).
As per claim 11, Braendgaard in view of Doney teaches the method of claim 1, wherein
receiving the request to securely transfer the PII of the first user comprises: receiving, from the
first virtual asset service provider, one or more application programming interface (API) calls
that invoke one or more functions at the PII transmission service configured to encrypt the PII,
store the PII, securely transmit the indication, or any combination thereof (Braendgaard [0047],
[0098], [0116], [0137]: management platform which constitutes a PII transmission service
receives API calls from the first entity which constitutes the first VASP – these API calls the
functions of the management platform which sets up a secure transmission of PII, encrypted by
the management platform and stored in a data repository, to the second entity).
As per claim 12, Braendgaard teaches a method for secure exchange of personally
identifiable information (PII), comprising: receiving, based at least in part on a transfer of an amount of a crypto token from a first blockchain address of a first user and managed by a first virtual asset service provider to a second blockchain address managed by a second virtual asset service provider, a user input indicative of the second virtual asset service provider and the second blockchain address (Braendgaard [0018], [0028], [0032], [0040], [0047], [0056], [0098], [0135], [0137]: the management platform constitutes a PII transmission service, entities constitute VASPs, and an identifier constitute the PII of the user where it is encrypted and transferred to the second entity as a first encrypted message which contains the PII and transfer of virtual assets – a request to transfer, see e.g., “a management platform—can execute Blocks… to establish communication links with a set of entities… to receive entity information… to generate a secure communication channel between the first entity and the second entity… a first entity e.g., a first VASP, in the set of entities, receives user information e.g., personally identifiable information, a full name, a physical address, a birthdate—associated with a first user in a first set of user… the first entity executes a request—from the first user device associated with the first user—for a transfer of a virtual asset or an amount of the virtual asset from the first blockchain address to a second blockchain address, such as a second blockchain address associated with a second user and hosted by a second entity e.g., a second VASP… management platform generates a communication channel… which a set of transaction information, associated with a transfer of a virtual asset, may be exchanged… for each entity in the set of entities, the management platform can: assign a data repository, in a set of data repositories, to the entity; encrypt entity information associated with the entity as encrypted entity information; and store the encrypted entity information in the data repository assigned to the entity… a first interface… communicatively coupled to the first entity e.g., via the first communication link between the management platform and the first entity… an identifier e.g., a full name, an identification number of a user… store the encrypted identifier in the data repository… first message representing the transaction information, such as: the virtual asset type; the amount of the virtual asset to transfer; the first user identifier of the first user as the originator user… management platform can encrypt the first message as a first encrypted message… management platform can transmit the first encrypted message to the second entity”);
transmitting, to a PII transmission service of the first virtual asset service provider and after receiving the user input, a request to securely transfer PII of the first user of the first virtual asset service provider to the second virtual asset service provider (Braendgaard [0110]: sanctions screening is a process of checking PII, see e.g., “execute a sanctions screening of a first user in response to receiving a user request for a transfer of a virtual asset from a blockchain address of the first user to another blockchain address; and transmit—to the management platform—a transaction request representing the transfer of the virtual asset and indicating a sanctions screening status (e.g., passed) of the first user”);
Braendgaard does not explicitly teach receiving, from the PII transmission service, a link
to access encrypted PII stored at a database of the PII transmission service and accessible by
the second virtual asset service provider and transmitting the link to the second virtual asset
service provider.
Doney teaches receiving, from the PII transmission service, a link (Doney [0071], [0074]:
AuthToken – includes DataID pointer which constitutes a link) to access encrypted PII stored at
a database of the PII transmission service and accessible by the second virtual asset service
provider (Doney [0017], [0071-0077], [0080]: encrypted PII is sent to a data store, the data host
generates a pointer that constitutes a link to the encrypted PII, AuthToken contains the DataID
pointer and AccessKey – provides means to decrypt. Issuing VASP issues AuthToken to recipient
VASP who will have access to the PII data);
and transmitting the link (Doney [0071], [0074]: AuthToken – includes DataID pointer
which constitutes a link) to the second virtual asset service provider (Doney [0080]: “issuing one
or more AuthTokens for the recipient VASP(s) who will have access to the data when a
qualifying transaction occurs”).
Thus it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to modify the invention of Braendgaard of a management
platform that sends encrypted PII to a second entity with the teachings of Doney to include
substituting the encrypted PII with a DataID pointer that points to the encrypted PII in a
database and sending it to a second VASP in order to use a cryptographic hash pointer to create
a tamper-proof data set (Doney [0078]) and data access tokens to securely and conditionally manage access to PII by ensuring only authorized parties can view the sensitive data (Doney
[0084]).
As per claim 13, Braendgaard in view of Doney teaches the method of claim 12,
transmitting, to the PII transmission service, a second request to securely receive second PII from a third virtual asset service provider (Braendgaard [FIG. 1]: shows a third VASP and blockchain addresses corresponding to that VASP), wherein the second request is transmitted based at least in part on a second requested blockchain transfer of a second amount of a second crypto token to a third blockchain address managed by the first virtual asset service provider and from a fourth blockchain address managed by the third virtual asset service provider (Braendgaard [0018], [0028], [0032], [0056], [0135], [0137]: the management platform
constitutes a PII transmission service, entities constitute VASPs, and an identifier constitute the
PII of the user where it is encrypted and transferred to the second entity as a first encrypted
message which contains the PII and transfer of virtual assets – a request to transfer, see e.g., “a
management platform—can execute Blocks… to establish communication links with a set of
entities… to receive entity information… to generate a secure communication channel between
the first entity and the second entity… a first entity e.g., a first VASP, in the set of entities,
receives user information e.g., personally identifiable information, a full name, a physical
address, a birthdate—associated with a first user in a first set of user… the first entity executes
a request—from the first user device associated with the first user—for a transfer of a virtual
asset or an amount of the virtual asset from the first blockchain address to a second blockchain
address, such as a second blockchain address associated with a second user and hosted by a
second entity e.g., a second VASP… an identifier e.g., a full name, an identification number of a user… store the encrypted identifier in the data repository… first message representing the
transaction information, such as: the virtual asset type; the amount of the virtual asset to
transfer; the first user identifier of the first user as the originator user… management platform
can encrypt the first message as a first encrypted message… management platform can
transmit the first encrypted message to the second entity”);
receiving, from the PII transmission service, a second link (Doney [0071], [0074]:
AuthToken – includes DataID pointer which constitutes a link) to the PII transmission service
and accessible by the third virtual asset service provider to input the second PII (Braendgaard
[FIG. 1]: third VASP; Doney [0017], [0071-0077], [0080]: encrypted PII is sent to a data store, the
data host generates a pointer that constitutes a link to the encrypted PII, AuthToken contains
the DataID pointer and AccessKey – provides means to decrypt. Issuing VASP issues AuthToken
to recipient VASP who will have access to the PII data);
and transmitting the second link (Doney [0071], [0074]: AuthToken – includes DataID
pointer which constitutes a link) to the third virtual asset service provider (Braendgaard [FIG. 1]:
third VASP; Doney [0080]: “issuing one or more AuthTokens for the recipient VASP(s) who will
have access to the data when a qualifying transaction occurs”).
As per claim 14, Braendgaard in view of Doney teaches the method of claim 13, receiving an indication of the second requested blockchain transfer of the second amount of
the second crypto token to the third blockchain address managed by the first virtual asset
service provider from the fourth blockchain address (Braendgaard [FIG. 1], [0032]: shows a third VASP and blockchain addresses corresponding to that VASP, entities constitute VASPs, see e.g., “the first entity executes a request—from the first user device associated with the first user—for a transfer of a virtual asset or an amount of the virtual asset from the first blockchain
address to a second blockchain address, such as a second blockchain address associated with a
second user and hosted by a second entity”);
and identifying the third virtual asset service provider managing the fourth blockchain
address (Braendgaard [FIG. 1]: shows a third VASP and blockchain addresses corresponding to
that VASP), wherein the second request is transmitted based at least in part on identifying the
third virtual asset service provider (Braendgaard [0104]: “management platform can repeat the
foregoing methods and techniques: to identify additional entities—in the set of entities—as
candidate counterparties to the first entity… transmit notifications identifying these entities as
candidate counterparties to the first entity and specifying the entity information… generate
communication channels between the first entity and each of these entities”).
As per claim 15, Braendgaard in view of Doney teaches the method of claim 12, wherein
the requested blockchain transfer of the amount of the crypto token is executed via a
blockchain network based at least in part on transmitting the link (Braendgaard [0032]: “first
entity: generates a transaction representing the transfer of the virtual asset from the first
blockchain address to the second blockchain address; and transmits—via the communication
network”).
As per claim 16, the claim discloses a method corresponding to the method claim 9
above, and they are rejected, at least for the same reasons.
As per claim 17, the claim discloses a method corresponding to the method claim 10
above, and they are rejected, at least for the same reasons.
As per claim 18, Braendgaard in view of Doney teaches the method of claim 12, wherein
transmitting the request to securely transfer the PII of the first user comprises: transmitting one or more application programming interface (API) calls that invoke one or more functions at the PII transmission service configured to encrypt the PII, store the PII, transmit the link, or any combination thereof (Braendgaard [0047], [0098], [0116], [0137]: management platform which constitutes a PII transmission service receives API calls from the first entity which constitutes the first VASP – these API calls the functions of the management platform which sets up a secure transmission of PII, encrypted by the management platform and stored in a data repository, to the second entity).
As per claim 20, Braendgaard teaches an apparatus for secure exchange of personally
identifiable information (PII), comprising: one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code to cause the apparatus to (Braendgaard [0018]: “Generally, a computer system—including a management platform—can execute Blocks of the method S100: to establish communication links with a set of entities e.g., virtual asset service providers”):
receive, from a first virtual asset service provider and at a PII transmission service
of the first virtual asset service provider, a request to securely transfer PII of a first
user of the first virtual asset service provider to a second virtual asset service provider, wherein
the request includes the PII and is received based at least in part on a requested blockchain
transfer of an amount of a crypto token from a first blockchain address of the first user and
managed by the first virtual asset service provider to a second blockchain address managed by the second virtual asset service provider (Braendgaard [0018], [0028], [0032], [0040], [0047], [0056], [0098], [0135], [0137]: the management platform constitutes a PII transmission service, entities constitute VASPs, and an identifier constitute the PII of the user where it is encrypted and transferred to the second entity as a first encrypted message which contains the PII and transfer of virtual assets – a request to transfer, see e.g., “a management platform—can execute Blocks… to establish communication links with a set of entities… to receive entity information… to generate a secure communication channel between the first entity and the second entity… a first entity e.g., a first VASP, in the set of entities, receives user information e.g., personally identifiable information, a full name, a physical address, a birthdate—associated with a first user in a first set of user… the first entity executes a request—from the first user device associated with the first user—for a transfer of a virtual asset or an amount of the virtual asset from the first blockchain address to a second blockchain address, such as a second blockchain address associated with a second user and hosted by a second entity e.g., a second VASP… management platform generates a communication channel… which a set of transaction information, associated with a transfer of a virtual asset, may be exchanged… for each entity in the set of entities, the management platform can: assign a data repository, in a set of data repositories, to the entity; encrypt entity information associated with the entity as encrypted entity information; and store the encrypted entity information in the data repository assigned to the entity… a first interface… communicatively coupled to the first entity e.g., via the first communication link between the management platform and the first entity… an identifier e.g., a full name, an identification number of a user… store the encrypted identifier in the data repository… first message representing the transaction information, such as: the virtual asset type; the amount of the virtual asset to transfer; the first user identifier of the first user as the originator user… management platform can encrypt the first message as a first encrypted message… management platform can transmit the first encrypted message to the second entity”);
encrypt the PII after receiving the request (Braendgaard [0039], [0056], [0135], [0137]:
entities constitute VASPS and the PII is being encrypted and transferred to the second entity
with the transfer of an amount of virtual assets, “the management platform… establish or generate communication links with entities in the set of entities… receive an identifier e.g., a
full name, an identification number of a user… encrypt the identifier as an encrypted identifier…
first message representing the transaction information, such as: the virtual asset type; the
amount of the virtual asset to transfer; the first user identifier of the first user as the originator
user… the management platform can transmit the first encrypted message to the second
entity”);
store the encrypted PII of the first user at a database associated with the PII
transmission service (Braendgaard [0056]: “management platform can… store the encrypted
identifier in the data repository”);
Braendgaard does not explicitly teach transmit, to the first virtual asset service
provider, a link to the encrypted PII stored at the database of the PII transmission service and
accessible by the second virtual asset service provider.
Doney teaches transmit, to the first virtual asset service provider, a link (Doney
[0071], [0074]: AuthToken – includes DataID pointer which constitutes a link) to the encrypted
PII stored at the database of the PII transmission service and accessible by the second virtual
asset service provider (Doney [0017], [0071-0077], [0080]: encrypted PII is sent to a data store,
the data host generates a pointer that constitutes a link to the encrypted PII, AuthToken
contains the DataID pointer and AccessKey – provides means to decrypt. Issuing VASP issues
AuthToken to recipient VASP who will have access to the PII data).
Thus it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to modify the invention of Braendgaard of a management
platform that sends encrypted PII to a second entity with the teachings of Doney to include substituting the encrypted PII with a DataID pointer that points to the encrypted PII in a
database and sending it to a second VASP in order to use a cryptographic hash pointer to create
a tamper-proof data set (Doney [0078]) and data access tokens to securely and conditionally
manage access to PII by ensuring only authorized parties can view the sensitive data (Doney
[0084]).
Claims 5 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over
Braendgaard in view of Doney, and further in view of Azgad-Tromer et al. US 20240104521
hereinafter referred to as Azgad-Tromer.
As per claim 5, Braendgaard in view of Doney teaches the method of claim 4.
Braendgaard in view of Doney does not explicitly teach wherein the link is transmitted
based at least in part on the second virtual asset service provider not being associated with the
PII transmission service.
Azgad-Tromer teaches wherein the link is transmitted based at least in part on the
second virtual asset service provider not being associated with the PII transmission service
(Azgad-Tromer [0009], [0018], [0019], [0032], [0033] [0135]: SAP a sealed asset platform
defines wallets that pertains to the user which contains the CRAI and the CRAI constitutes a
link/indication to the encrypted PII in a database, the source of the CRAI – user’s wallet
implementation – lacks direct trust relationship with other parties in the system, necessitating
validation and transmission through the first VASP, see e.g., “CRAI may comprise user identities
name, national identifiers, etc… information is protected… CRAI is generated or maintained by
the user's wallet implementation, which is not directly trusted by others, wherein the SAP is
configured to guarantee that each transaction complies with the policy… generate at least partially encrypted compliance relevant auxiliary information (CRAI)… store the associated CRAI
in a storage location accessible… enable a VASP to securely transmit data, i.e., protect the
integrity and availability of the required information to facilitate record-keeping using CRAI”).
Thus it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to modify the invention of Braendgaard in view of Doney of
securely exchanging PII with the teachings of Azgad-Tromer to include transmitting and
receiving a link based at least in part on the second virtual asset service provider not being
associated with the PII transmission service in order to protect against unauthorized disclosure
in line with national privacy and data protection laws (Azgard-Tromer [0136]).
As per claim 19, Braendgaard in view of Doneyteaches the method of claim 12.
Braendgaard in view of Doney does not explicitly teach wherein the link is received
based at least in part on the second virtual asset service provider not being associated with the
PII transmission service.
Azgad-Tromer teaches wherein the link is received based at least in part on the second
virtual asset service provider not being associated with the PII transmission service (Azgad-
Tromer [0009], [0018], [0019], [0032], [0033], [0135-0136]: SAP a sealed asset platform defines
wallets that pertains to the user which contains the CRAI and the CRAI constitutes a
link/indication to the encrypted PII in a database, the source of the CRAI – user’s wallet
implementation – lacks direct trust relationship with other parties in the system, necessitating
validation and transmission through the first VASPs and protect the user of CRAI when received
by second VASP, see e.g., “CRAI may comprise user identities name, national identifiers, etc…
information is protected… CRAI is generated or maintained by the user's wallet implementation, which is not directly trusted by others, wherein the SAP is configured to
guarantee that each transaction complies with the policy… generate at least partially encrypted
compliance relevant auxiliary information (CRAI)… store the associated CRAI in a storage
location accessible… enable a VASP to securely transmit data, i.e., protect the integrity and
availability of the required information to facilitate record-keeping using CRAI… protect the use
of such CRAI by receiving VASPs”).
Thus it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to modify the invention of Braendgaard in view of Doney of
securely exchanging PII with the teachings of Azgad-Tromer to include transmitting and
receiving a link based at least in part on the second virtual asset service provider not being
associated with the PII transmission service in order to protect against unauthorized disclosure
in line with national privacy and data protection laws (Azgard-Tromer [0136]).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CAROLINE HOANG-ANH NGUYEN whose telephone number is (571)272-8309. The examiner can normally be reached Monday-Thursday 7am-5pm.
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 (571) 272-3739. 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.
/C.H.N./Examiner, Art Unit 2495
/HENRY TSANG/Primary Examiner, Art Unit 2495
Prosecution Insights