DETAILED ACTION
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 .
Response to Arguments
Applicant’s Appeal filed on 08/18/2025, with respect to the rejection(s) of independent claims 1, 16 and 31 under 35 USC § 103 have been fully considered and was found persuasive. However, a second non-final is being issued herewith based on newly found prior arts, Xiong, US 2012/0066501, and Cona, US 2019/0333054.
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, 16 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over US-PGPUB No. 2020/0145234 A1 to Nishijima, US-PGPUB No. 2012/0066501 A1 to Xiong, US-PGPUB No. 2023/0066711 to Wright et al. (hereinafter “Wright”), and further in view of US-PGPUB No. 2019/0333054 A1 to Cona et al. (hereinafter “Cona”)
Regarding claim 1:
Nishijima discloses:
A method implemented in a data protection broker node (see Fig. 9, Bootstrap Node 110) (¶31: “The bootstrap node 110(1) includes a bootstrap program 112(1) and a client program 116(1).”), the method comprising:
Performing a bootstrap operation between a user (¶33: “An administrator or other user 115(1) …”) and the data protection broker node (¶33: “An administrator or other user 115(1) associated with the first entity 102(1) may execute the client program 116(1) on the bootstrap node 110(1) for interacting with the bootstrap program 112(1).”), to initialize a blockchain (¶15: “… the bootstrap herein may also include generating one or more genesis blocks, which may be configuration blocks that initialize a blockchain …”);
However, Nishijima does not explicitly disclose the following limitation taught by Xiong:
as a result of the bootstrap operation (Xiong, ¶10: “The method includes receiving a request from the device through the terminal; exchanging transaction-related data with the device;”), obtaining a trusted temporary public identifier identifying the user (Xiong, ¶10: “a user device remaining anonymous to a service provider during … transaction of the user device, … generating a one-time anonymous identifier for the device, the one-time anonymous identifier being valid for a predetermined time; and sending the one-time anonymous identifier to the device, …”);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Nishijima to incorporate the functionality of the method to keep a user device anonymous to a service provider during multi-factor and multi-channel ID authentication and transaction of the user device, as disclosed by Xiong, such modification would enable the system to keep consumers anonymous while performing transactions with service providers.
The combination of Nishijima and Xiong does not explicitly disclose the following limitation taught by Wright:
receiving a request for a new transaction associated with the user (Wright, ¶47: “… [Alice] sends the transaction 152 from the client application 105 to one of the one or more forwarding nodes 104F to which she is connected. … When any given node 104 receives a new transaction 152j, it handles it in accordance with the node protocol and its respective role.”) and joining the new transaction to the blockchain (Wright, ¶47: “… the newly received transaction 152j passes the test for being deemed valid (i.e. on condition that it is “validated”), any storage node 104S that receives the transaction 152j will add the new validated transaction 152 to the pool 154 in the copy of the blockchain 150 maintained at that node 104S.”);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima and Xiong to incorporate the functionality of the node 104 to receive a new transaction and add the new transaction to a blockchain after validating the new transaction, as disclosed by Wright, such modification would allow the system to propagate and mine transactions so that they are recorded on a blockchain.
The combination of Nishijima, Xiong and Wright does not explicitly disclose the following limitation taught by Cona:
and authorizing the user to use the trusted temporary public identifier to perform a user transaction to protect a privacy of the user's data (Cona, ¶20: “authorizing the user to engage in the transaction online with the provider; and at least one pseudonymous identifier associated with the credential configured for use in verifying the qualification of the user for authorizing the individual to engage in the transaction online with the provider …”, see also claim 12: “… authorizing the user to engage in a transaction online with a provider using credential data based on at least one qualification of the user that is associated with a credential associated with … at least one pseudonymous identifier associated with the credential;”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima, Xiong and Wright to incorporate the functionality of the method to authorize a user to engage in a transaction using a pseudonymous identifier, as disclosed by Cona, such modification would enable the system to verify an identity of a user associated with a digital identity account maintained with an identity provider and perform a safe transaction without identity leakage.
Regarding claim 16:
Nishijima discloses:
A data protection broker node (see Fig. 9, Bootstrap Node 110) comprising processing circuitry (¶120: “… bootstrap node 110 may include one or more processors 902, … processor(s) 902 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, …”), the processing circuitry configured to cause the data protection broker node to:
In addition to the above limitations, claim 16 recites substantially the same limitations as claim 1 in the form of a protection broker node to realize the corresponding method, therefore it is rejected by the same rationale.
Regarding claim 31:
Nishijima discloses:
A non-transitory, tangible computer-readable storage medium (see Fig. 9, Computer Readable Media 904, ¶121: “… the computer-readable media 904 may be a type of computer-readable storage media and/or may be a tangible non-transitory media …”), having instructions stored thereon (¶122: “The computer-readable media 904 may be used to store … instructions or programs …”), that when executed by processing circuitry (¶120: “… bootstrap node 110 may include one or more processors 902, … processor(s) 902 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, …”) of a data protection broker node(see Fig. 9, Bootstrap Node 110) (¶122: “… that are executable by the processors 902 and that, when executed, specifically configure the one or more processors 902 to perform the actions attributed above to the bootstrap node 110.”), cause the processing circuitry to perform operations comprising:
In addition to the above limitations, claim 16 recites substantially the same limitations as claim 1 in the form of a non-transitory, tangible computer-readable storage medium for storing instructions, therefore it is rejected by the same rationale.
Claims 5 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Nishijima, Xiong, Wright, Cona, US-PGPUB No. 2019/0207760 A1 to Hennebert, and further in view of US-PGPUB No. 2019/0205932 A1 to Ericson
Regarding claim 5:
The combination of Nishijima, Xiong, Wright and Cona discloses the method of Claim 1, but does not explicitly disclose the following limitations taught by Hennebert:
further comprising:
adding a smart contract to the blockchain (Hennebert, ¶28 “… the block containing the smart contract then being mined;”), the smart contract being associated to the trusted temporary public identifier (Hennebert, ¶34: “… the first user forms a first transaction (T.sub.A) containing the first ephemeral public key and sends it to the address of the smart contract, the wallet address of the first user and the first ephemeral public key then being stored in the smart contract, the block containing the smart contract then being mined;”);
using the trusted temporary public identifier to map the smart contract to the user's data (Hennebert, ¶28: “… the first user forms a request in the form of a third transaction and sends it to the address of the smart contract, the second instruction of the third function of the smart contract then returning the second ephemeral public key to it; [0037] (vi) the second user forms a request in the form of a third transaction and sends it to the address of the smart contract, the second instruction of the third function of the smart contract then returning the first ephemeral public key to it;”); and
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima, Xiong, Wright and Cona to incorporate the functionality of the method of exchanging keys between a first user and a second user of a transaction blockchain, the blockchain being designed to store a smart contract, wherein the smart contract stores ephemeral public keys of the users, the smart contract with the ephemeral keys mined to the blockchain, as disclosed by Hennebert, such modification would enable the system to implement functions within the smart contract to monitor transactions associated with the respective ephemeral public keys.
The combination of Nishijima, Xiong, Wright, Cona and Hennebert does not explicitly disclose the following limitation taught by Ericson:
executing the smart contract to control access, by at least one third-party service provider, to at least part of the user's data during the user transaction and according to at least one term of the smart contract (Ericson, ¶50: “… the user device 412 may generate a smart contract … and the smart contract generated by the user device 412 may provide rules to the smart contract 602 that define which service providers may provide the associated user's user information, which service providers can retrieve the user's user information, when the user information is available, the type of user information that is available, and/or other rules or restrictions that allow a user to have control over the privacy of their user information”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima, Xiong, Wright, Cona and Hennebert to incorporate the functionality of the user device to provide rules to the a smart contract that defines which service providers may provide the associated user's user information, which service providers can retrieve the user's user information, when the user information is available, the type of user information that is available, and/or other rules or restrictions that allow a user to have control over the privacy of their user information, as disclosed by Ericson, such modification would allow the system to provide a wide variety of techniques that allow the user to control how that user's information may be gathered and/or shared between service provider devices.
Regarding claim 20:
Claim 20 recites substantially the same limitations as claim 5 in the form of a protection broker node to realize the corresponding method, therefore it is rejected by the same rationale.
Claims 17 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Nishijima, Xiong, Wright, Cona, and further in view of US-PGPUB No. 2019/0020468 A1 to Rosenoer
Regarding claim 17:
The combination of Nishijima, Xiong, Wright and Cona discloses the data protection broker node of claim 16, but does not explicitly disclose the following limitation taught by Rosenoer:
wherein the trusted temporary public identifier is a hashed value (Rosenoer, ¶25: “… The user, … trigger[s] the authentication process to create a one-time identifier, which is converted to a hash and sent to the blockchain VM. … hashes generated in the confirmation process are destroyed after comparisons are performed.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima, Xiong, Wright and Cona to incorporate the functionality of the method to receive a one-time (temporary) identifier and convert it into a hash to send to a blockchain, as disclosed by Rosenoer, such modification would allow the system to provide the expected advantages of hashing a data- efficient use of storage space in the blockchain.
Regarding claim 32:
Claim 32 recites substantially the same limitations as claim 17 in the form of a non-transitory, tangible computer-readable storage medium for storing instructions, therefore it is rejected by the same rationale.
Claims 18-19, 27 and 33 are rejected under 35 U.S.C. 103 as being unpatentable over Nishijima, Xiong, Wright, Cona, and further in view of US-PGPUB No. 2020/0342427 A1 to Kulinna
Regarding claim 18:
The combination of Nishijima, Xiong, Wright and Cona discloses the data protection broker node of claim 16, but does not explicitly disclose the following limitation taught by Kulina:
wherein the processing circuitry is further configured to cause the data protection broker node to:
send the trusted temporary public identifier to the user to anonymously register the user to at least one third-party service provider (Kulinna, ¶28: “… user 106 receives the anonymous identity and that anonymous identity can be used at third party service providers such as third party service provider 104.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima, Xiong, Wright and Cona to incorporate the functionality of the method to settle invoicing and payment for a service outside a distributed ledger wherein the invoice includes anonymous identity of a user, as disclosed by Kulinna, such modification would allow the system to provide the user with anonymous identity, thus hiding the actual identity of the user to protect personal information while providing a secure environment for transaction.
Regarding claim 19:
The combination of Nishijima, Xiong, Wright, Cona and Kulinna discloses:
The data protection broker node of claim 18, wherein the processing circuitry is further configured to cause the data protection broker node to:
receive an identifier from the at least one third-party service provider (Kulinna, ¶46-47: “The invoice may include … the anonymous identity of user 106 … and also the identity of third party service provider 104. … home service provider 102 receives the invoice from third party service provider 104 and creates a purchase order for third party service provider 104 …”);
and when the received identifier matches the trusted temporary public identifier (Kulinna, ¶47: “Home service provider 102 can cross reference the invoice to user 106 to the charges on the invoice received from third party service provider 104 using the anonymous identity.”), record at least one activity of the user transaction involving the user's data in the blockchain (Kulinna, ¶48: “… home service provider 102 can include the single record in the distributed ledger 110 so that the user can verify the outstanding payments and therefore the consumed services at third party service providers.”).
The same motivation which is applied to claim 18 with respect to Kulinna applies to claim 19.
Regarding claim 27:
The combination of Nishijima, Xiong, Wright, Cona and Kulinna discloses:
The data protection broker node of Claim 19, wherein the processing circuitry is further configured to cause the data protection broker node to:
responsive to receiving a request from one of the at least one third-party service provider to verify a purchase amount for the user transaction, use the obtained trusted temporary public identifier to verify the purchase amount with a financial institution associated with the user (Kulinna, ¶20: “ERP system 112 generates a purchase order for third party service provider 104 for the service provided to user 106 (and other users) to settle payment for charges with third party service provider 104 that were incurred by the user (and other users). The settlement is outside distributed ledger 110 to avoid fees associated with using an intermediary or a distributed ledger. The settlement is done based on the anonymous identity of user 106 such that third party service provider 104 does not know the identity of user 106 during the whole process.”).
The same motivation which is applied to claim 18 with respect to Kulinna applies to claim 19.
Regarding claim 33:
Claim 33 recites substantially the same limitations as claim 18 in the form of a non-transitory, tangible computer-readable storage medium for storing instructions, therefore it is rejected by the same rationale.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Nishijima, Xiong, Wright, Cona, Hennebert, Ericson, and further in view of US-PGPUB No. 2020/0327473 A1 to Zur et al. (hereinafter “Zur”)
Regarding claim 21:
The combination of Nishijima, Xiong, Wright, Cona, Hennebert and Ericson discloses the data protection broker node of claim 20, but does not explicitly disclose the following limitation taught by Zur:
wherein the at least one term of the smart contract includes at least one self-executing term to handle delivery of a product ordered during the user transaction to a physical mailing address of the user (Zur, ¶37: “… the smart contract may capture or extract purchase order terms such as but not limited to quantity, account to be charged, shipping addresses, etc., and generate, trigger or otherwise cause the generation of … a sales order for the product using the terms or information obtained from the purchase order.”, ¶27: “… the terms “self-executing code” or “self-executing code segment” and “smart contract” may be used interchangeably.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima, Xiong, Wright, Cona, Hennebert and Ericson to incorporate the functionality of the computing resource of the customer ERP system to generate a purchase order for the product and transmit the purchase order to the smart contract, wherein the smart contract may capture or extract purchase order terms such as shipping addresses, as disclosed by Zur, such modification would allow the system to deliver the product to the user and complete the transaction.
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Nishijima, Xiong, Wright, Cona, Hennebert, Ericson, Zur, and further in view of US-PGPUB No. 2021/0142321 A1 to Kaczmarek et al. (hereinafter “Kaczmarek”)
Regarding claim 22:
The combination of Nishijima, Xiong, Wright, Cona, Hennebert, Ericson and Zur discloses the data protection broker node of claim 21, but does not explicitly disclose the following limitation taught by Kaczmarek:
wherein the at least one self-executing term includes:
when a predetermined destination code (Kaczmarek, ¶78: “… tokenized customer name …”, ¶08: “… a tokenized customer name representing the actual name along with a preferred intermediary address …”) is received from a third-party delivery service provider (Kaczmarek, ¶78: “… the local shipper (a third-party delivery service provider), … scans the tokenized customer name printed on the adhesive shipping label on the package and confirms that it matches the tokenized customer name provided previously to the local shipper.”), provide the third-party delivery service provider with the physical mailing address, the destination code being different from the physical mailing address (Kaczmarek, ¶78: “… the local shipper is then provided with the intended delivery address.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima, Xiong, Wright, Cona, Hennebert, Ericson and Zur to incorporate the functionality of the method for enabling anonymous shipment of a package purchased by a customer from a vendor for delivery to the customer at an address unknown to the vendor, whereby the customer has an actual name and an intended delivery address, as disclosed by Kaczmarek, such modification would allow the system to hide the personal information of a user from third party service providers.
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Nishijima, Xiong, Wright, Cona, Hennebert, Ericson, and further in view of US-PGPUB No. 2019/0188655 A1 to Pandit et al. (hereinafter “Pandit”)
Regarding claim 23:
The combination of Nishijima, Xiong, Wright, Cona, Hennebert and Ericson discloses the data protection broker node of claim 20, but does not explicitly disclose the following limitation taught by Pandit:
wherein the processing circuitry is configured to execute the smart contract by being configured to:
participate in the user transaction by communicating with at least one of at least one third-party service provider on behalf of the user according to the at least one term of the smart contract (Pandit, ¶47: “… executing the blockchain transaction on behalf of the user account via a smart contract and storing the blockchain transaction in a blockchain 530.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima, Xiong, Wright, Cona, Hennebert and Ericson to incorporate the functionality of the method to execute a blockchain transaction on behalf of a user account via a smart contract and storing the blockchain transaction in a blockchain, as disclosed by Pandit, such modification would allow the system to obtain the expected advantages of smart contracts such as speed, accuracy, accuracy, transparency and immutability.
Claims 24-26 are rejected under 35 U.S.C. 103 as being unpatentable over Nishijima, Xiong, Wright, Cona, Hennebert, Ericson, and further in view Kaczmarek
Regarding claim 24:
The combination of Nishijima, Xiong, Wright, Cona, Hennebert and Ericson discloses the data protection broker node of claim 20, but does not explicitly disclose the following limitation taught by Kaczmarek:
wherein the at least one term of the smart contract includes at least one of:
at least one type of personal information (Kaczmarek, ¶09: “… storing personal information associated with the customer … including the actual name and intended delivery address associated with an account maintained by the customer … generating a tokenized customer name representing the actual name along with a preferred intermediary address …”);
at least one third-party service provider; and
at least one rule for electronic access to the at least one type of personal information by the at least one third-party service provider.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima, Xiong, Wright, Cona, Hennebert and Ericson to incorporate the functionality of the method for enabling anonymous shipment of a package purchased by a customer from a vendor for delivery to the customer at an address unknown to the vendor, whereby the customer has an actual name and an intended delivery address, as disclosed by Kaczmarek, such modification would allow the system to hide the personal information of a user from third party service providers.
Regarding claim 25:
The combination of Nishijima, Xiong, Wright, Cona, Hennebert, Ericson and Kaczmarek discloses:
The data protection broker node of claim 24, wherein the at least one rule further comprises:
restricting electronic access to at least one of the at least one type of personal information by one of the at least one third-party service provider (Kaczmarek, ¶38: “… shield the actual name and intended delivery address from the vender …” providing to the vender the tokenized customer name and the preferred intermediary address in place of the actual name and the intended delivery address.); and
permitting electronic access to at least another of the at least one type of personal information by the one of the at least one third-party service provider (Kaczmarek, ¶09: “… providing to the vender the tokenized customer name and the preferred intermediary address in place of the actual name and the intended delivery address.”).
The same motivation which is applied to claim 24 with respect to Kaczmarek applies to claim 25.
Regarding claim 26:
The combination of Nishijima, Xiong, Wright, Cona, Hennebert and Ericson discloses the data protection broker node of claim 20, but does not explicitly disclose the following limitation taught by Kaczmarek:
wherein the at least one term of the smart contract is set by the user to control access to the user's data by the at least one third-party service provider participating in the user transaction (Kaczmarek, ¶65: “The shipper to which the package is sent via, may be selected by the customer …”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima, Xiong, Wright, Cona, Hennebert and Ericson to incorporate the functionality of the method for enabling anonymous shipment of a package purchased by a customer from a vendor for delivery to the customer at an address unknown to the vendor, whereby the customer can select the shipper, as disclosed by Kaczmarek, such modification would allow the system to provide the user to pick a shipper of the user’s preference.
Claim 28 is rejected under 35 U.S.C. 103 as being unpatentable over Nishijima, Xiong, Wright, Cona, Kulinna, and further in view of US-PGPUB No. 2019/0392162 to Stern et al. (hereinafter “Stern”)
Regarding claim 28:
The combination of Nishijima, Xiong, Wright, Cona and Kulinna discloses the data protection broker node of claim19, but does not explicitly disclose the following limitation taught by Stern:
wherein the processing circuitry is further configured to cause the data protection broker node to:
receive, from one of the at least one third-party service provider, a request to receive at least part of the user's data (Stern, ¶28: “… the front-end module 215 receives requests from third-party systems 140 to access personal data associated with a user …”), the request indicating the trusted temporary public identifier that is associated to the user's data (Stern, ¶28: “… the third-party system request includes … an identification of the user, …”);
map the indicated trusted temporary public identifier to the user (Stern, ¶29: “Responsive to receiving a data access request from a third-party system 140 … the front-end module 215 instructs the data request module 220 to query the permissions data store 240 to determine whether any consent verifications govern the disclosure of the user's data (identified by the identification of the user) to the requesting third-party system 140, …”);
determine whether the user consents to providing the at least the requested part of the user's data to the one of the at least one third-party service provider (Stern, ¶29: “… determine whether any consent verifications govern the disclosure of the user's data to the requesting third-party system 140, …”); and
based at least in part on the determination of whether the user consents, one of provide and not provide the at least the requested part of the user's data to the one of the at least one third-party service provider (Stern, ¶42: “… the consent management module 225 … notifies the data request module 220 that the requested disclosure is authorized. the consent management module 220 notifies the data request module 220 that the requested data may not be shared with the third-party system.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima, Xiong, Wright, Cona and Kulinna to incorporate the functionality of the consent management module to query the permissions data store for any consent verifications from the user associated with the requested information and/or the third-party system to determine whether the level of consent obtained from the user is lower than the required level of consent associated with the requested data, or whether the user has not previously authorized disclosure of the requested information to the third-party system , as disclosed by Stern, such modification would allow the system to protect the disclosure of sensitive personal data to unauthorized third parties.
Claims 29-30 is rejected under 35 U.S.C. 103 as being unpatentable over Nishijima, Xiong, Wright, Cona, and further in view of Kaczmarek
Regarding claim 29:
The combination of Nishijima, Xiong, Wright and Cona discloses the data protection broker node of claim 16, but does not explicitly disclose the following limitation taught by Kaczmarek:
wherein the user's data includes personal information of the user that is used during the user transaction (Kaczmarek, ¶33: “… the customer provides at least personal information, such as the customer's name and address, and preferably, financial information, such as the customer's bank account or financial instrument (i.e. credit card, social security, etc.) information to a third party entity … for assisting the customer in completing a purchase from a vender …”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Nishijima, Xiong, Wright and Cona to incorporate the functionality of the method for enabling anonymous shipment of a package purchased by a customer from a vendor for delivery to the customer at an address unknown to the vendor, whereby the customer can select the shipper, as disclosed by Kaczmarek, such modification would allow the system to provide the user to pick a shipper of the user’s preference.
Regarding claim 30:
The combination of Nishijima, Xiong, Wright, Cona and Kaczmarek discloses:
The data protection broker node of Claim 29, wherein the personal information includes at least one of a first name, a last name, a physical address, an email address, a telephone number, a social security number, bank account information, credit card information, a driver's license number and a health insurance number (Kaczmarek, ¶33: “… the customer provides at least personal information, such as the customer's name and address, and preferably, financial information, such as the customer's bank account or financial instrument (i.e. credit card, social security, etc.) information …”).
The same motivation which is applied to claim 29 with respect to Kaczmarek applies to claim 30.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Bender et al. (US 20020099824-A1)- disclosed a method and system for sharing online user information in an anonymous manner. The system associates an identifier with anonymized information of the user, and sends the anonymized user information to a receiving party.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHIAS HABTEGEORGIS whose telephone number is (571)272-1916. The examiner can normally be reached M-F 8am-5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, William R. Korzuch can be reached at (571)272-7589. 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.
/MATTHIAS HABTEGEORGIS/Examiner, Art Unit 2491