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 .
DETAILED ACTION
The following is a Final Office Action in response to communications received March 27, 2026. Claims 1-20 are pending and examined.
Response to Amendments and Arguments
As to the rejection of Claims 1-20 under 35 U.S.C. § 101, Applicant’s arguments and amendments have been fully considered but are not persuasive. Applicant’s amendment “wherein the structured encrypted information comprises…” merely further narrows the limitation “structured encrypted information. Applicant’s amendment “enabling the one or more sources to access the stored structured encrypted information and the stored approval status for retrieval and verification” is an extra solution activity, akin to data gathering and data transmitting. In response to Applicant’s arguments that the claims are not directed to any abstract idea, Examiner disagrees. The present claims are directed to certain methods of organizing human activity. Examiner argues that the claims do not amount to significantly more because the limitations, in effect, merely add the words “apply it” to the “the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea” - see MPEP 2106.05(f). The additional elements do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. And simply relying on a computer to perform routine tasks or calculations more quickly or more accurately is insufficient to render a claim patent eligible. See Alice, 134 S. Ct. at 2359 (“use of a computer to create electronic records, track multiple transactions, and issue simultaneous instructions” is not an inventive concept); Bancorp Servs., L.L.C. v. Sun Life Assur. Co. of Can. (U.S.), 687 F.3d 1266, 1278 (Fed. Cir. 2012) (a computer “employed only for its most basic function . . . does not impose meaningful limits on the scope of those claims”); cf. DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258–59 (Fed. Cir. 2014) (finding a computer-implemented method patent eligible where the claims recite a specific manipulation of a general-purpose computer such that the claims do not rely on a “computer network operating in its normal, expected manner”). The rejection is thereby maintained.
As to the rejection of claims 1-20 under 35 U.S.C. § 103, Applicant's arguments and amendments have been fully considered but are not persuasive.
Applicant argues that Anderson does not disclose “enabling sources to access stored structured encrypted authorization information and approval status form the blockchain for retrieval and verification”. Examiner disagrees. In ¶[0048]-¶[0049], it teaches “the verifier 306 can make a proof request for the patient's eligibility status for a specific Current Procedural Terminology (CPT) code. The proof request also asks for a cryptographic proof, e.g., a storage identifier for a public key of the issuer 302 or the patient 304, which the verifier agent 466 can use to obtain the public key to verify the digital signatures on the credential. [0049] Upon receiving the credential from the patient agent 444 of the patient 304, the verifier agent 466 of the verifier 306 verifies the credential as belonging to the patient 304 and as being issued by issuer 302. In some embodiments, the verification includes the verifier agent 466 obtaining from the public identity ledger 310 the public keys of one or more of the issuer 302 or the patient 304. The verifier agent 466 of the self-sovereign identity 406 of the verifier 306 uses the obtained public keys to read or verify the digital signatures that the issuer agent 426 of the issuer 302 or the patient agent 444 of the patient 304 have attached to the credential. Upon successful verification of the credential, the verifier agent 466 of the verifier 306 communicates with the verifier service 460, e.g., including the verification service 464 and the connector service 462, to route the information contained in the credential into the verifier's local database system, e.g., the existing records system 472 or the existing EMR system 474.”
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, both Anderson and Chiu pertain to using decentralized ledgers for transactions with service providers. The rejection is thereby maintained. The claims are rejected as amended as detailed below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
(Step 1) The claims recite a system and method. For the purposes of this analysis, representative claim 2 is addressed.
(Step 2A, prong 1) Abstract ideas are in bold below, and represents certain methods of organizing human activity, as a method of payment, distribution, and pricing for two users bound by a contractual relationship. Payment, distribution, and pricing for two users bound by a contractual relationship is akin to certain methods of organizing human activity.
A method for automatically validating an authorization request for an episode of service, the method comprising:
receiving information from one or more sources via a network, wherein the information comprises a combination of structured and unstructured information, and wherein the information comprises an authorization request and one or more requirements;
converting the information into structured, encrypted information, wherein the structured encrypted information comprises at least one of a client member number, a client group number, a plan code, a plan type, a prescription group, a prescription identification number, a processor control number, a procedure, an ontology, a service provider location, a practitioner associated the service provider, a recommending/prescribing physician, a service, and a price;
storing the structured[[,]] encrypted format using a blockchain;
automatically determining an approval status of the authorization request based on the one or more requirements;
storing the approval status, in an encrypted format, using the blockchain;
enabling the one or more sources to access the stored structured encrypted information and the stored approval status for retrieval and verification;
automatically generating a message containing the approval status; and
transmitting the message to the one or more sources.
(Step 2A prong 2) The additional elements are considered as follows:
“receiving information from one or more sources via a network”. This is an extra solution activity, akin to data gathering.
“converting the information into structured, encrypted information”. This is an extra solution activity, akin to data gathering and data processing.
“storing the structured, encrypted format using a blockchain”. This is merely “apply it” this blockchain is claimed at a high level of generality, it receives the information, performs the abstract idea, and outputs the results.
“storing the approval status, in an encrypted format, using the blockchain”. This is merely “apply it” this blockchain is claimed at a high level of generality, it receives the information, performs the abstract idea, and outputs the results.
“enabling the one or more sources to access the stored structured encrypted information and the stored approval status for retrieval and verification” This is an extra solution activity, akin to data gathering and data transmitting.
“automatically generating a message containing the approval status;”. This is merely “apply it” this sever is claimed at a high level of generality, it receives the information, performs the abstract idea, and outputs the results.
“transmitting the message to the one or more sources”. This is an extra solution activity, akin to data gathering and data transmitting.
(Step 2B) The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount to no more than mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of payment, distribution, and pricing for two users bound by a contractual relationship, over a generic computer network with generic computing elements, and generic hardware. The additional elements do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment (i.e. blockchain).
Analysis of dependent claims 2-10, recited additional details which only further narrow the abstract idea and do not add any additional features, alone or in combination, that would provide a practical application or provide significantly more. For example, Claim 2 further narrows the limitation “automatically determining an approval status” by “collecting a plurality of authorization requests and requirements” which is extra solution activity, akin to data gathering, and “creating a training set…training a natural language processor…and verifying the approval status” which is “apply it”. Claims 3-5 further narrow the limitation “automatically determining an approval status” of Claim 1 by “validating”, “validating”, or “reconciling”, which are “apply it”. Claim 6 further narrows the limitation “one or more requirements” of Claim 1. Claim 7 further narrows the limitation “one or more sources” of Claim 1. Claim 8 further narrows the limitation “one or more sources” of Claim 7. Claim 9 further narrows the limitation of “the requirements” of Claim 1. Claim 10 further narrows the limitation of “the episode of service” of Claim 1. Method Claim 1 and system Claim 11 are similarly rejected as are the corresponding dependent claims 12-20.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 3-5, 9-11, 13-15, 19, and 20 is/are rejected under 35 U.S.C. 102 as being anticipated by Anderson et al. (Publication No.: US 2021/0287770 A1).
As to Claim 1, Anderson teaches a method for automatically validating an authorization request for an episode of service, the method comprising:
receiving information from one or more sources via a network, wherein the information comprises a combination of structured and unstructured information, and wherein the information comprises an authorization request and one or more requirements (see ¶[0024] – “A client of an issuer (“issuer client”) receives identification of a user, e.g., a patient, from a wallet applicant deployed on a user terminal of the user. Upon verifying the authenticity of the user identification information, the issuer client performs a data binding step by retrieving information of the user, e.g., medical record, from a data system of the issuer, e.g., an electronic medical record system, by mapping the verified user identification into the data system. The issuer client assembles the retrieved information into a credential template having a standardized data structure and format and provides the assembled credential information to the user.”, and ¶[0025] – “In some embodiments, the issuer client establishes a trusted, private, and cryptographically secured connection with the wallet application of the user through an agent, e.g., a cloud-based agent, and provides the credential information to the wallet application via the private connection. For example, when the issuer client registers the wallet application with the cloud-based agent for the private connection, a pair of cryptographic keys “communication key pair” are generated or identified for the secured communication between the cloud-based agent and the wallet application. For example, the cloud-based agent encrypts the credential information using a public key of the communication key pair before sending the credential information to the wallet application. Upon receiving the encrypted credential information, the wallet application decrypts it using the private key of the communication key pair to obtain the credential information.”);
converting the information into structured[[,]] encrypted information, wherein the structured encrypted information comprises at least one of a client member number, a client group number, a plan code, a plan type, a prescription group, a prescription identification number, a processor control number, a procedure, an ontology, a service provider location, a practitioner associated the service provider, a recommending/prescribing physician, a service, and a price; storing the structured[[,]] encrypted format using a blockchain (see ¶[0033] – “In some embodiments, the issuer 302, through agents in the credential platform 308, attaches a digital signature to a credential using a private key of the issuer 302 before sending the credential to the patient 304. The respective agents in the credential platform 308 also causes to store a public key of the issuer 302 in a public identity ledger 310, e.g., a distributed ledger or a blockchain. The verifier 306 receives the signed credentials, obtains the public key of the issuer 302, and verifies the authenticity of the digital signature using the public key of the issuer 302, all through the respective agent in the credential platform 308.”, and ¶[0036] - ;
automatically determining an approval status of the authorization request based on the one or more requirements (see ¶[0038] – “Specifically, issuers 302 and verifiers 306 have the means, e.g., through the credential platform 308, to add standardized digital identity markers, referred to as decentralized identifiers or DIDs, to the identity ledger 310, making those decentralized identifiers immutable and secure. These decentralized identifiers contain information on where and how to communicate with the issuers 302, verifiers 306 as identity owners, also referred to as “digital endpoints”, as well as public cryptographic keys to communicate with the identity owners. With this information, any network participant can establish a secondary, unique and private line of communication that inherits all of the security and immutability of the participants' decentralized identifiers on the public identity ledger. In the healthcare space, such a ledger can exist independently from a specific healthcare provider or insurance provider, either through existing, public blockchain networks like the Sovrin network, or as consortium-governed healthcare-specific blockchain networks. With such a blockchain network in place, healthcare providers (as issuers 302 and/or verifiers 306), and insurance providers (as issuers 302 and/or verifiers 306), and in some embodiments, even patients (as patients 304) can all act as participants on the network, registering their own unique, secure, and immutable public decentralized identifiers. A participant on the network of the public identity ledger 310 does not necessarily function or have the authority to function as a mining node or as a consensus node to maintain a copy of the public identity ledger and to add a public DID to the public identity ledger 310. Further, a participant does not necessarily interact with the public identity ledger 310 directly. In some embodiments, the issuer 302, verifier 306 and patient 304 each interacts with the identity ledger 310 through respective agents (not shown in FIG. 3) registered on the credential platform 308.”);
storing the approval status, in an encrypted format, using the blockchain (see ¶[0022] – “In some embodiments, the issuer client establishes a trusted, private, and cryptographically secured connection with the wallet application of the user through an agent, e.g., a cloud-based agent, and provides the credential information to the wallet application via the private connection. For example, when the issuer client registers the wallet application with the cloud-based agent for the private connection, a pair of cryptographic keys “communication key pair” are generated or identified for the secured communication between the cloud-based agent and the wallet application. For example, the cloud-based agent encrypts the credential information using a public key of the communication key pair before sending the credential information to the wallet application. Upon receiving the encrypted credential information, the wallet application decrypts it using the private key of the communication key pair to obtain the credential information.”);
enabling the one or more sources to access the stored structured encrypted information and the stored approval status for retrieval and verification (see ¶[0048]-¶[0049] – “the verifier 306 can make a proof request for the patient's eligibility status for a specific Current Procedural Terminology (CPT) code. The proof request also asks for a cryptographic proof, e.g., a storage identifier for a public key of the issuer 302 or the patient 304, which the verifier agent 466 can use to obtain the public key to verify the digital signatures on the credential. [0049] Upon receiving the credential from the patient agent 444 of the patient 304, the verifier agent 466 of the verifier 306 verifies the credential as belonging to the patient 304 and as being issued by issuer 302. In some embodiments, the verification includes the verifier agent 466 obtaining from the public identity ledger 310 the public keys of one or more of the issuer 302 or the patient 304. The verifier agent 466 of the self-sovereign identity 406 of the verifier 306 uses the obtained public keys to read or verify the digital signatures that the issuer agent 426 of the issuer 302 or the patient agent 444 of the patient 304 have attached to the credential. Upon successful verification of the credential, the verifier agent 466 of the verifier 306 communicates with the verifier service 460, e.g., including the verification service 464 and the connector service 462, to route the information contained in the credential into the verifier's local database system, e.g., the existing records system 472 or the existing EMR system 474.”);
automatically generating a message containing the approval status (see ¶[0086]-[0089] – “the communications of data in the processes 600, 700, do not necessarily follow the directions of the communication, e.g., the sending or the receiving of information, as described herein. For example, the connection request of the process 600 can be achieved by the issuer service 420 sending the private DID of the issuer service 420 to the wallet 442. The proof request of the process 700 can be achieved by the verifier service 460 sending the private DID of the verifier service 460 to the wallet 442. The self-sovereign identity 404 of the patient 304 can have a cloud-based agent 444 that operates all the time and is coupled to the wallet 442 in a similar manner as those between the issuer service 420 and the issuer agent 426 or as those between the verifier service 460 and the verifier agent 466.”); and
transmitting the message to the one or more sources (see ¶[0086]-[0089]).
As to Claim 3, Anderson teaches the method of claim 1, wherein automatically determining an approval status comprises validating an insured status of a user associated with the authorization request (see ¶[0088] – “By performing in some or all of the ways described above, the facility 502 substantially improves the efficiency in the healthcare industry in handling patient credential information. By creating private, trusted, and cryptographically secured connections with insurance providers and with healthcare providers, patients can thus present their information in a portable, trustable and verifiable way as desired herein. Pre-registration, prior authorization, identification, and even day-of registration can be replaced by a simple, digital interaction between the healthcare providers and the patients. For example, in the weeks before care, a patient can receive a notification that a provider is requesting specific identity and coverage information. By accepting that request, the patient supplies the provider with the detailed information the provider needs to confirm the patient identity, establish eligibility, access coverage details, and gain prior authorization if needed. On the day of care the patient can receive a notification upon arrival through the wallet application, or scan a QR code at the portal application at the registration desk establishing secured connections for presenting the credential information of the patient. All of these transactions present the needed data to the healthcare provider in a way that is trustworthy, secure, and convenient. Further, the digital nature of the credential enables the unlimited amount of information contained in a credential as compared to the limited information represented by a physical credential nowadays.”).
As to Claim 4, Anderson teaches the method of claim 1, wherein automatically determining an approval status comprises validating coverage of a service request associated with the authorization request (see ¶[0044] – “A digital credential is a list of claims specific to a patient 304. A claim is a piece of information attested to by the issuer 302. A simple example of a claim in this scenario can be the patient's member ID stored in the member records system 430. A more complicated claim can be the entirety of the eligibility information of the patient 304. The credential contain claims that encompass that patient's full coverage, eligibility, prior authorization, and medical guidelines information, as well as her/his personal information such as name and member ID. Depending on the issuer 302 and the issuer's local database 430, the credential can also contain the medical or health record information of a patient 304 or other information.”).
As to Claim 5, Anderson teaches the method of claim 1, wherein automatically determining an approval status comprises reconciling insurance pre-requisites associated with the authorization request (see ¶[0088]).
As to Claim 9, Anderson teaches the method of claim 1, wherein the requirements comprise at least one of: national, regional, and state payer requirements (see ¶[0003] – “ the credentials in some cases include information related to identifying the subject of the credential, for example, a photo, name, or identification number; information related to the issuing authority, for example, a city government, national agency, or certification body; information related to the type of credential, for example, a Dutch passport, an American driving license, or a health insurance card; and information related to attributes or properties being asserted by the issuing authority about the subject, for example, nationality, the classes of vehicle entitled to drive, or date of birth; and other credentials.”, and ¶[0079] – “In some embodiments, in the connection request, the wallet 442 presents an identification credential containing the demographic information of the patient 304. This identification credential can come from a number of sources, including the government as a participant of the diagram 300 or an issuer 302. For example, the issuer 302 can issue an identification credential after verifying the authenticity of the demographic information of the patient 304 in a similar way as issuing the vaccination credential as described in the process 600 of FIG. 6. The identification credential can be verified by the verifier service 460 in a similar way as verifying a vaccination credential as described herein.”).
As to Claim 10, Anderson teaches the method of claim 1, wherein the episode of service comprises at least one of: a medical diagnosis, a car repair estimate, a home repair estimate, or a life insurance summary (see ¶[0036], and ¶[0071]).
Claim 11 is the system comprising: a processor; and a non-transitory, processor-readable storage medium, wherein the non-transitory, processor-readable storage medium comprises one or more programming instructions that, when executed, cause the processor to perform the method of Claim 1 and is rejected under the same reasoning as Claim 1.
Claim 13 is the system comprising: a processor; and a non-transitory, processor-readable storage medium, wherein the non-transitory, processor-readable storage medium comprises one or more programming instructions that, when executed, cause the processor to perform the method of Claim 3 and is rejected under the same reasoning as Claim 3.
Claim 14 is the system comprising: a processor; and a non-transitory, processor-readable storage medium, wherein the non-transitory, processor-readable storage medium comprises one or more programming instructions that, when executed, cause the processor to perform the method of Claim 4 and is rejected under the same reasoning as Claim 4.
Claim 15 is the system comprising: a processor; and a non-transitory, processor-readable storage medium, wherein the non-transitory, processor-readable storage medium comprises one or more programming instructions that, when executed, cause the processor to perform the method of Claim 5 and is rejected under the same reasoning as Claim 5.
Claim 19 is the system comprising: a processor; and a non-transitory, processor-readable storage medium, wherein the non-transitory, processor-readable storage medium comprises one or more programming instructions that, when executed, cause the processor to perform the method of Claim 9 and is rejected under the same reasoning as Claim 9.
Claim 20 is the system comprising: a processor; and a non-transitory, processor-readable storage medium, wherein the non-transitory, processor-readable storage medium comprises one or more programming instructions that, when executed, cause the processor to perform the method of Claim 10 and is rejected under the same reasoning as Claim 10.
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 2, 6, 7, 8, 12, 16, 17, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Anderson et al. (Publication No.: US 2021/0287770 A1) in view of Chiu et al. (Publication No.: US 2024/0161072 A1).
As to Claim 2, although Anderson substantially teaches the invention of Claim 2, it does not explicitly teach the method of claim 1, wherein automatically determining an approval status comprises: collecting a plurality of authorization requests and requirements; creating a training set based on the plurality of authorization requests and requirements; training a natural language processor on the training set; and verifying the approval status using the natural language processor. Chiu teaches the method of claim 1, wherein automatically determining an approval status comprises: collecting a plurality of authorization requests and requirements; creating a training set based on the plurality of authorization requests and requirements; training a natural language processor on the training set; and verifying the approval status using the natural language processor (see ¶[0082] – “In another example, a machine-learning model 514 is implemented as part of the entity data and control logic 132 of the decentralized identity 130. The machine-learning model 514 is configurable, for instance, to resolve ambiguities in requests to access the decentralized identity data 506, e.g., through natural language understanding. The machine-learning model 514 is also usable to control what decentralized identity data 506 is shared and how the decentralized identity data 506 is shared. The decentralized identity data 506, for instance, may include health information and opt to share portions of the data that pertain to sleep tracking yet restrict access to other portions that are not relevant to a particular third-party service provider system. In this instance, the machine-learning model 514 is usable to intelligently respond to particular requests made to access the decentralized identity data 506 by providing decentralized identity data 506 that is pertinent to the request and yet is not personally identifiable information or otherwise considered sensitive to the first entity 108. A variety of other examples are also contemplated.”). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to use the training of a natural language processor in Chiu in the prior authorization transmission and storage of Anderson as both the inventions are using blockchain to increase the efficiency of insurance prior authorizations.
As to Claim 6, Chiu teaches the method of claim 1, wherein the one or more requirements comprise one or more natural language questions (see ¶[0230] – “The computer-readable media 2010 can be used to store and maintain any number of functional components that are executable by the processor(s) 2008. In some implementations, these functional components comprise instructions or programs that are executable by the processor(s) 2008 and that, when executed, implement operational logic for performing the actions and services attributed above to the user device 2002. Functional components stored in the computer-readable media 2010 can include a user interface 2020 to enable users to interact with the user device 2002, and thus the server(s) 2004 and/or other networked devices. In at least one example, the user interface 2020 can be presented via a web browser, or the like. In other examples, the user interface 2020 can be presented via an application, such as a mobile application or desktop application, which can be provided by a service provider associated with the server(s) 2004, or which can be an otherwise dedicated application. In some examples, the user interface 2020 can be a user interface as shown in FIGS. 5 and 6. In at least one example, a user can interact with the user interface via touch input, spoken input, gesture, or any other type of input. The word “input” is also used to describe “contextual” input that may not be directly provided by the user via the user interface 2020. For example, user's interactions with the user interface 2020 are analyzed using, e.g., natural language processing techniques, to determine context or intent of the user, which may be treated in a manner similar to “direct” user input.”).
As to Claim 7, Chiu teaches the method of claim 1, wherein each of the one or more sources has real-time access to the encrypted blockchain (see ¶[0167] – “In some examples, the service provider can enable conversational commerce via conversational commerce services, which can use one or more machine learning mechanisms to analyze messages exchanged between two or more users 1614, voice inputs into a virtual assistant or the like, to determine intents of user(s) 1614. In some examples, the service provider can utilize determined intents to automate customer service, offer promotions, provide recommendations, or otherwise interact with customers in real-time. In at least one example, the service provider can integrate products and services, and payment mechanisms into a communication platform (e.g., messaging, etc.) to enable customers to make purchases, or otherwise transact, without having to call, email, or visit a web page or other channel of a merchant. That is, conversational commerce alleviates the need for customers to toggle back and forth between conversations and web pages to gather information and make purchases.”).
As to Claim 8, Anderson teaches the method of claim 7, wherein each of the one or more sources has a private key for decrypting at least a portion of the blockchain (see ¶[0025] – “the cloud-based agent encrypts the credential information using a public key of the communication key pair before sending the credential information to the wallet application. Upon receiving the encrypted credential information, the wallet application decrypts it using the private key of the communication key pair to obtain the credential information.”).
Claim 12 is the system comprising: a processor; and a non-transitory, processor-readable storage medium, wherein the non-transitory, processor-readable storage medium comprises one or more programming instructions that, when executed, cause the processor to perform the method of Claim 2 and is rejected under the same reasoning as Claim 2.
Claim 16 is the system comprising: a processor; and a non-transitory, processor-readable storage medium, wherein the non-transitory, processor-readable storage medium comprises one or more programming instructions that, when executed, cause the processor to perform the method of Claim 6 and is rejected under the same reasoning as Claim 6.
Claim 17 is the system comprising: a processor; and a non-transitory, processor-readable storage medium, wherein the non-transitory, processor-readable storage medium comprises one or more programming instructions that, when executed, cause the processor to perform the method of Claim 7 and is rejected under the same reasoning as Claim 7.
Claim 18 is the system comprising: a processor; and a non-transitory, processor-readable storage medium, wherein the non-transitory, processor-readable storage medium comprises one or more programming instructions that, when executed, cause the processor to perform the method of Claim 8 and is rejected under the same reasoning as Claim 8.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IRENE S KANG whose telephone number is (571)270-3611. The examiner can normally be reached on Monday through Friday between M-F 10am-2pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Matt Gart may be reached at (571)-273-3955. 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.
/IRENE KANG/
Examiner, Art Unit 3695
6/1/2026
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696
Prosecution Insights