DETAILED ACTION
This final Office action is responsive to amendments filed January 27th, 2026. Claims 1-18 and 20 have been amended. Claims 1-20 are presented for examination.
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 arguments regarding claim rejections under 35 USC 101 filed 1/27/26 have been fully considered but they are not persuasive.
On pages 10-12 of the provided remarks, Applicant argues that the amended claims represent statutory subject matter. Beginning on page 10 of the provided remarks, Applicant argues “it is clear that the claims are NOT directed to a method of organizing human behavior as defined in the MPEP, but is instead an approach to process and initiate transfer of tokens using a decentralized authentication framework.” Examiner respectfully disagrees and asserts that the amended claims still recite the generation of a first profile for the first entity and verification of the onboarding of the first entity to onboard the first entity, which is managing relationships and interactions. While Applicant argues “the fact that the amended claims recite that a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on the decentralized authentication framework means that the claimed steps cannot be solely performed in the human brain, but must instead require the usage of a computing system” Examiner respectfully disagrees. Per the as-filed Specification [0064] “the engagement initiation engine 208 may establish, based on the approval, an association between at least a subset of the first plurality of attributes and a corresponding subset of the second plurality of attributes to create an engagement of the first profile and the second profile.” Examiner asserts that “establish, based on the approval, an association between at least a subset of the first plurality of attributes and a corresponding subset of the second plurality of attributes to create an engagement of the first profile and the second profile” recites the management of relationships and interactions. Therefore, the claims recite the abstract idea. Applicant’s arguments are not persuasive.
Applicant continues on page 11 of the provided remarks to argue, “With regard to the claimed subject matter, it is not possible for a human mind by itself to implement the transfer of tokens using a decentralized authentication framework, particularly where a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on the decentralized authentication framework. The human mind simply does not have the concept of a decentralized authentication framework as understood by the claim.” Examiner begins by asserting that the claims recite “initiate the transfer of the one or more tokens having the pre-defined token value”. The amended claims do not limit the performance of the token transfer initiation to the decentralized authentication framework as argued by Applicant. This initiation is merely performed by “a processor”. Per the October 2019 Update, “In evaluating whether a claim that requires a generic computer recites a mental process, examiners should carefully consider the broadest reasonable interpretation of the claim in light of the specification. By way of example, examiners may review the specification to determine if the underlying claimed invention is described as a concept that is performed in the human mind and applicant is merely claiming that concept performed 1) on a generic computer, 2) in a computer environment or 3) is merely using a computer as a tool to perform the concept.” Examiner asserts that the claimed “processor” is merely being used as a tool to perform the initiation, which, as stated above, is establishing association between two entities. Examiner asserts that this is a function of a human mind and therefore recites the abstract idea of mental processes. Applicant’s arguments are not persuasive.
On pages 11-12 of the provided remarks, Applicant argues “Here, the specific implementation recited in the claim refers to both a decentralized authentication framework, and to the recordation of pre-defined token values for the transfer of the tokens as a lookup table on the decentralized authentication framework. These claimed concepts extend far beyond just the simple concept of a general computer.” Examiner respectfully disagrees and asserts, as stated above, the claims recite “initiate the transfer of the one or more tokens having the pre-defined token value”. The amended claims do not limit the performance of the token transfer initiation to the decentralized authentication framework as argued by Applicant. This initiation is merely performed by “a processor” which is analogous to a generic computer component. Therefore, the 35 USC 101 rejection is maintained. Applicant’s arguments are not persuasive.
Applicant's arguments regarding claim rejections under 35 USC 103 filed 1/27/26 have been fully considered but they are not persuasive.
On pages 13-16 of the provided remarks, Applicant argues that the cited prior art does not disclose the amended claim limitations. Beginning on pages 14-15 of the provided remarks, Applicant argues cite Fostiropulo “does not provide any disclosure of the transfer of the one or more tokens having a pre-defined token value between the first entity and the second entity. There is not mention at all ion this paragraph of a “pre-defined token value”. Examiner respectfully disagrees and asserts cited paragraph [0033] recites “every token tracks from creation to release such that each action and transaction is validated, for example for the purpose of accurately tracking the efficiency and return on investment of a sales campaign initiated via the vendor system”. This is analogous to the as-filed Specification [0047] “The pre-defined token value may be associated with each engagement activity and a record of the pre-defined token value for each engagement activity may be stored as a lookup table on the decentralized authentication framework 118.” Therefore, cited Fostiropulo discloses the amended “pre-defined token value”. Applicant’s arguments are not persuasive.
Applicant continues on page 15 of the provided remarks to argued the citations of Fostiropulo “does not provide any mention that a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on the decentralized authentication framework.” Examiner states that this argued amended limitation is now mentioned by cited Barton (U.S 2022/0012770 A1).
Claim Objections
Claims 1 and 8 are objected to because of the following informalities: the limitation beginning “initiate the transfer” recites “the entity of interest” which is a typographical error that should recite “the second entity”. Appropriate correction is required.
Claim 15 is objected to because of the following informalities:
the limitation beginning "receive an onboarding request" recites "the first entity" which lacks antecedent basis and should recite "a first entity";
the limitation beginning “initiate the transfer” recites “the entity of interest” which is a typographical error that should recite “the second entity”.
Appropriate correction is required.
Claim 16 is objected to because of the following informalities:
the limitation beginning “receive an engagement request” recites “an engagement request” which to align with above amendment should recite “a request”; and
the limitation beginning “receive an engagement request” recites “the entity of interest” which is a typographical error that should recite “the second entity”.
Appropriate correction is required.
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 non-statutory subject matter;
When considering subject matter eligibility under 35 U.S.C. 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea), and if so, it must additionally be determined whether the claim is a patent-eligible application of the exception. If an abstract idea is present in the claim, any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself.
Claims 1-14
Step 1: Independent claims 1 (system), 8 (method), and dependent claims 2-7, and 9-14, respectively, fall within at least one of the four statutory categories of 35 U.S.C. 101: (i) process; (ii) machine; (iii) manufacture; or (iv) composition of matter. Claim 1 is directed to a system (i.e. machine) and claim 8 is directed to a method (i.e. process).
Step 2A Prong 1: The independent claims recite a method comprising: receiving an onboarding request from a first entity; generating a first profile for the first entity, the first profile including a first plurality of attributes, a first plurality of attribute values associated with each of the first plurality of attributes, and a first unique identifier associated with the first profile to identify the first entity; verifying the onboarding of first entity by executing pre-defined veracity test sequences, the veracity test sequences being associated with at least a subset of the first plurality of attributes of the first plurality of attribute values; storing the first profile, in response to successfully verifying the first entity, in an immutable form on a decentralized authentication framework, wherein the storing the first profile comprises linking a first unique token repository to the first profile of the first entity, the unique token repository maintaining one or more tokens and each of the one or more tokens having assigned thereto a pre-defined token value; receiving a request, from at least one of the first entity or a second entity, to initiate a transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity, the second entity comprising a second profile associated thereto on the decentralized authentication framework, the second profile including a second plurality of attributes, a second plurality of attribute values associated with each of the second plurality of attributes, and a second unique identifier associated with the second profile to identify the second entity; authenticating the request, the request being authenticated by authenticating the first entity and the second entity; retrieving, upon successful authentication of the request, the first profile and the second profile from the decentralized authentication framework; receiving, from at least one of the first entity and the entity of interest, an approval to initiate the transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity; and initiating the transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity, wherein the processor is to store an indication of an associated of the first entity and the entity of interest in the decentralized authentication framework, wherein a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on decentralized authentication framework (Certain Method of Organizing Human Activity & Mental Process), which are considered to be abstract ideas (See PEG 2019 and MPEP 2106.05). [Examiner notes the underlined limitations above recite the abstract idea].
The steps/functions disclosed above and in the independent claims recite the abstract idea of Certain Methods of Organizing Human Activity because the claimed limitations are generating a first profile for the first entity and initiating transfer of one or more tokens between a first and second entity, which is managing personal behavior, relationships, and interactions. The Applicant’s claimed limitations are generating a first profile for the first entity and initiating transfer of one or more tokens between a first and second entity, which recite the abstract idea of Organizing Human Activity.
The steps/functions disclosed above and in the independent claims recite the abstract idea of Mental Process because the claimed limitations are generating a first profile for the first entity; verifying the onboarding of the first entity; linking a first unique token repository to the first profile; authenticating the request to determine credibility of the request; and initiating transfer of one or more tokens between a first and second entity, which are observations, judgments, and evaluations of the human mind. The Applicant’s claimed limitations are generating a first profile for the first entity; verifying the onboarding of the first entity; linking a first unique token repository to the first profile; authenticating the request to determine credibility of the request; and initiating transfer of one or more tokens between a first and second entity, which recite the abstract idea of Mental Process.
In addition, dependent claims 2-7 and 9-14 further narrow the abstract idea and recite further defining the initiation of engagement between the first and second entities; updating the record of engagements for the first and second entities; analyzing historical data to provide a confidence score; and analyzing the record of engagement to determine performance analytics. These processes are similar to the abstract idea noted in the independent claims because they further the limitations of the independent claims which recite a certain method of organizing human activity which include managing personal behavior as well as mental process. Accordingly, these claim elements do not serve to confer subject matter eligibility to the claims since they recite abstract ideas.
Step 2A Prong 2: In this application, the above “receiving an onboarding request from a first entity; storing the first profile, in response to successfully verifying the first entity, in an immutable form on a decentralized authentication framework, wherein the storing the first profile comprises linking a first unique token repository to the first profile of the first entity, the unique token repository maintaining one or more tokens and each of the one or more tokens having assigned thereto a pre-defined token value; receiving a request, from at least one of the first entity and a second entity, to initiate a transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity, the second entity comprising a second profile associated thereto on the decentralized authentication framework, the second profile including a second plurality of attributes, a second plurality of attribute values associated with each of the second plurality of attributes, and a second unique identifier associated with the second profile to identify the second entity; retrieving, upon successful authentication of the request, the first profile and the second profile from the decentralized authentication framework; receiving, from at least one of the first entity and the second entity, an approval to initiate the transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity; wherein the processor is to store an indication of an associated of the first entity and the entity of interest in the decentralized authentication framework, wherein a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on decentralized authentication framework” steps/functions of the independent claims would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and merely adds the words to apply it with the judicial exception. Also, the claimed “A system for entity engagement, the system comprising: a processor; a decentralized authentication framework; first unique token repository; a second unique token repository” would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05).
In addition, dependent claims 2-7 and 9-14 further narrow the abstract idea and dependent claims 3 and 10 additionally recite “transfer a pre-defined token value from the first unique token repository to a second unique token repository” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and the claimed “processor” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05).
The claimed “A system for entity engagement, the system comprising: a processor; a decentralized authentication framework; first unique token repository; a second unique token repository” are recited so generically (no details whatsoever are provided other than that they are general purpose computing components and regular office supplies) that they represent no more than mere instructions to apply the judicial exception on a computer. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. Even when viewed in combination, the additional elements in the claims do no more than use the computer components as a tool. There is no change to the computers and other technology that is recited in the claim, and thus the claims do not improve computer functionality or other technology (See PEG 2019).
Step 2B: When analyzing the additional element(s) and/or combination of elements in the claim(s) other than the abstract idea per se the claim limitations amount(s) to no more than: a general link of the use of an abstract idea to a particular technological environment and merely amounts to the application or instructions to apply the abstract idea on a computer (See MPEP 2106.05 and PEG 2019). Further, method claims 8-14; and system claims 1-7 recite “A system for entity engagement, the system comprising: a processor; a decentralized authentication framework; first unique token repository; a second unique token repository”; however, these elements merely facilitate the claimed functions at a high level of generality and they perform conventional functions and are considered to be general purpose computer components which is supported by Applicant’s specification in Paragraphs 0037-41 and Figures 1, 2, & 4. The Applicant’s claimed additional elements are mere instructions to implement the abstract idea on a general purpose computer and generally link of the use of an abstract idea to a particular technological environment. Also, the above “receiving an onboarding request from a first entity; storing the first profile, in response to successfully verifying the first entity, in an immutable form on a decentralized authentication framework, wherein the storing the first profile comprises linking a first unique token repository to the first profile of the first entity, the unique token repository maintaining one or more tokens and each of the one or more tokens having assigned thereto a pre-defined token value; receiving a request, from at least one of the first entity and a second entity, to initiate a transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity, the second entity comprising a second profile associated thereto on the decentralized authentication framework, the second profile including a second plurality of attributes, a second plurality of attribute values associated with each of the second plurality of attributes, and a second unique identifier associated with the second profile to identify the second entity; retrieving, upon successful authentication of the request, the first profile and the second profile from the decentralized authentication framework; receiving, from at least one of the first entity and the second entity, an approval to initiate the transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity; wherein the processor is to store an indication of an associated of the first entity and the entity of interest in the decentralized authentication framework, wherein a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on decentralized authentication framework” steps/functions of the independent claims would not account for significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art. When viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
In addition, claims 2-7 and 9-14 further narrow the abstract idea identified in the independent claims. The Examiner notes that the dependent claims merely further define the data being analyzed and how the data is being analyzed. Similarly, claims 3 and 10 additionally recite “transfer a pre-defined token value from the first unique token repository to a second unique token repository” which do not account for additional elements that amount to significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art and the claimed “processor” which do not account for additional elements that amount to significantly more than the abstract idea because the claimed structure merely amounts to the application or instructions to apply the abstract idea on a computer and does not move beyond a general link of the use of an abstract idea to a particular technological environment (See MPEP 2106.05). The additional limitations of the independent and dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea. The examiner has considered the dependent claims in a full analysis including the additional limitations individually and in combination as analyzed in the independent claim(s). Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claims 15-20
Step 1: Independent claim 15 (non-transitory computer-accessible storage medium) and dependent claims 16-20, respectively, fall within at least one of the four statutory categories of 35 U.S.C. 101: (i) process; (ii) machine; (iii) manufacture; or (iv) composition of matter. Claim 15 is directed to a non-transitory computer-accessible storage medium (i.e. manufacture).
Step 2A Prong 1: The independent claim recites a non-transitory computer-accessible storage medium storing program comprising instructions, the instructions being executable by a processor to: receive an onboarding request from the first entity; generate a first profile for the first entity, the first profile including a first plurality of attributes, a first plurality of attribute values associated with each of the first plurality of attributes, and a first unique identifier associated with the first profile to identify the first entity; verify the onboarding of first entity, wherein the instructions being executable to execute pre-defined veracity test sequences associated with at least a subset of the first plurality of attributes of the first plurality of attribute values to verify the first profile; store the first profile, in response to successfully verifying the first entity, in an immutable form on a decentralized authentication framework, wherein the instructions being executable by the processor to link a first unique token repository to the first profile of the first entity, the first unique token repository maintaining one or more tokens and each of the one or more tokens having assigned thereto a pre-defined token value; and initiate a transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity, wherein the processor is to store an indication of an association of the first entity and the entity of interest in the decentralized authentication framework, wherein a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on the decentralized authentication framework (Certain Method of Organizing Human Activity & Mental Process), which are considered to be abstract ideas (See PEG 2019 and MPEP 2106.05). [Examiner notes the underlined limitations above recite the abstract idea].
The steps/functions disclosed above and in the independent claims recite the abstract idea of Certain Methods of Organizing Human Activity because the claimed limitations are generating a first profile for the first entity and initiating transfer of one or more tokens between a first and second entity, which is managing personal behavior, relationships, and interactions. The Applicant’s claimed limitations are generating a first profile for the first entity and initiating transfer of one or more tokens between a first and second entity, which recite the abstract idea of Organizing Human Activity.
The steps/functions disclosed above and in the independent claims recite the abstract idea of Mental Process because the claimed limitations are generating a first profile for the interested entity; verifying the onboarding of first entity and linking a first unique token repository to the first profile, which are observations, judgments, and evaluations of the human mind. The Applicant’s claimed limitations are generating a first profile for the interested entity; verifying the onboarding of first entity and linking a first unique token repository to the first profile, which recite the abstract idea of Mental Process.
In addition, dependent claims 16-20 further narrow the abstract idea and recite further defining authentication of the engagement request to determine credibility of the engagement request; the initiation of engagement between the first and second entities; updating the record of engagements for the first and second entities; and analyzing historical data to provide a confidence score. These processes are similar to the abstract idea noted in the independent claims because they further the limitations of the independent claims which recite a certain method of organizing human activity which include managing personal interactions as well as mental process. Accordingly, these claim elements do not serve to confer subject matter eligibility to the claims since they recite abstract ideas.
Step 2A Prong 2: In this application, the above “receive an onboarding request from the first entity; store the first profile, in response to successfully verifying the first entity, in an immutable form on a decentralized authentication framework, wherein the instructions being executable by the processor to link a first unique token repository to the first profile of the first entity, the first unique token repository maintaining one or more tokens and each of the one or more tokens having assigned thereto a pre-defined token value; wherein the processor is to store an indication of an association of the first entity and the entity of interest in the decentralized authentication framework, wherein a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on the decentralized authentication framework” steps/functions of the independent claims would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and merely adds the words to apply it with the judicial exception. Also, the claimed “A non-transitory computer-accessible storage medium storing program comprising instructions for entity engagement, the instructions being executable by a processor; a decentralized authentication framework; a first unique token repository; a second unique token repository” would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05).
In addition, dependent claims 16-20 further narrow the abstract idea and dependent claims 18 additionally recite “transfer a pre-defined token value from the first unique token repository to a second unique token repository” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and the claimed “processor” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05).
The claimed “A non-transitory computer-accessible storage medium storing program comprising instructions for entity engagement, the instructions being executable by a processor; a decentralized authentication framework; a first unique token repository; a second unique token repository” are recited so generically (no details whatsoever are provided other than that they are general purpose computing components and regular office supplies) that they represent no more than mere instructions to apply the judicial exception on a computer. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. Even when viewed in combination, the additional elements in the claims do no more than use the computer components as a tool. There is no change to the computers and other technology that is recited in the claim, and thus the claims do not improve computer functionality or other technology (See PEG 2019).
Step 2B: When analyzing the additional element(s) and/or combination of elements in the claim(s) other than the abstract idea per se the claim limitations amount(s) to no more than: a general link of the use of an abstract idea to a particular technological environment and merely amounts to the application or instructions to apply the abstract idea on a computer (See MPEP 2106.05 and PEG 2019). Further, non-transitory computer-accessible storage medium claims 15-20 recite “A non-transitory computer-accessible storage medium storing program comprising instructions for entity engagement, the instructions being executable by a processor; a decentralized authentication framework; a first unique token repository; a second unique token repository”; however, these elements merely facilitate the claimed functions at a high level of generality and they perform conventional functions and are considered to be general purpose computer components which is supported by Applicant’s specification in Paragraphs 0037-41 and Figures 1, 2, & 4. The Applicant’s claimed additional elements are mere instructions to implement the abstract idea on a general purpose computer and generally link of the use of an abstract idea to a particular technological environment. Also, the above “receive an onboarding request from the first entity; store the first profile, in response to successfully verifying the first entity, in an immutable form on a decentralized authentication framework, wherein the instructions being executable by the processor to link a first unique token repository to the first profile of the first entity, the first unique token repository maintaining one or more tokens and each of the one or more tokens having assigned thereto a pre-defined token value; wherein the processor is to store an indication of an association of the first entity and the entity of interest in the decentralized authentication framework, wherein a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on the decentralized authentication framework” steps/functions of the independent claims would not account for significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art. When viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
In addition, claims 16-20 further narrow the abstract idea identified in the independent claims. The Examiner notes that the dependent claims merely further define the data being analyzed and how the data is being analyzed. Similarly, claim 18 additionally recites “transfer a pre-defined token value from the first unique token repository to a second unique token repository” which do not account for additional elements that amount to significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art and the claimed “processor” which do not account for additional elements that amount to significantly more than the abstract idea because the claimed structure merely amounts to the application or instructions to apply the abstract idea on a computer and does not move beyond a general link of the use of an abstract idea to a particular technological environment (See MPEP 2106.05). The additional limitations of the independent and dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea. The examiner has considered the dependent claims in a full analysis including the additional limitations individually and in combination as analyzed in the independent claim(s). Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-5, 7-12, and 14-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Booij (U.S 2014/0164256 A1) in view of Fostiropulo (U.S 2020/0134612 A1) in view of Barton (U.S 2022/0012770 A1).
Claims 1 and 8
Regarding Claim 1, Booij discloses the following:
A system, the system comprising: a processor to [see at least Paragraph 0003 for reference to the system for processing interaction requests from a customer; Paragraph 0088 for reference to the servers including one or more processors executing computer program instructions and interacting with other system components; Figure 1A and related text regarding a system supporting a contact center that is configured to provide mobile device support to contact center customers; Figure 1B and related text regarding the mobile server system]
receive an onboarding request from an first entity [see at least Paragraph 0136 for reference to as part of the registration process, the user enters via the settings page, personal information for the user such as, for example, the user’s email address, pin number, and telephone number; Figure 12 and related text regarding the settings page for registering a user with the associated contact center system]
generate a first profile for the first entity, the first profile including a first plurality of attributes, a first plurality of attribute values associated with each of the first plurality of attributes, and a first unique identifier associated with the first profile to identify the first entity [see at least Paragraph 0136 for reference to the mobile server system in turn communicates with associated database servers for generating and/or updating an associated customer record with the submitted information; Paragraph 0136 for reference to customer information including account number, password, address, birthdate, or the like]
verify the onboarding of the first entity to onboard the first entity, wherein the processor is to execute pre-defined veracity test sequences associated with at least a subset of the first plurality of attributes of the first plurality of attribute values to verify the first profile [see at least Paragraph 0136 for reference to the user information input while registering being used for authenticating the user; Paragraph 0193 for reference to if the context data includes a temporary security token provided by the authentication server, the routing strategy may include providing the security token to the authentication server for verifying that the authorized user of the token is the user that has placed the voice call]
store the first profile, in response to successfully verifying the first entity [see at least Paragraph 0087 for reference to the contact center also includes one or more mass storage devices for storing different databases relating to agent data (e.g. agent profiles, schedules, etc.), customer data (e.g. customer profiles), interaction data (e.g. details of each interaction with a customer, including reason for the interaction, disposition data, time on hold, handle time, etc.), and the like; Figure 1A and related text regarding item 30 ‘storage devices’]
receive a request, from at least one of the first entity or a second entity, to initiate between the first entity and the second entity, the second entity comprising a second profile, the second profile including a second plurality of attributes, a second plurality of attribute values associated with each of the second plurality of attributes, and a second unique identifier associated with the second profile to identify the second entity [see at least Paragraph 0094 for reference to when a customer invokes the customer application to transmit a request to be connected to a live agent, the context of the request is sent from the application to the mobile server system over a data channel for storing by the secure call matching module; Paragraph 0105 for reference to the customer application provides along with the chat request, context data about the user (also referred to as case information or session information) for allowing the agent to provide personalized customer service; Paragraph 0115 for reference to if a customer transmits a request for a real time interaction with an agent. such as, for example, voice call or chat, by selecting the appropriate option from the screen displayed in FIG. 3B, the routing server attempts to find an available agent to handle the interaction; Paragraph 0174 for reference to the routing server invokes one or more business rules to identify an agent that may handle the call wherein the agent may be identified, for example, based on routing parameters included in the context data, such as for example, type of service requested (call, callback, and the like), language preferences, transaction type, and/or the like; Paragraph 0211 for reference to the customer application transmits a request for interaction over a data channel, and includes a service request for callback; Paragraph 0226 for reference to agent availability associated with agent ID as well as location, telephone number, and/or extension of the particular device on which the mobile application is executed]
authenticate the request, the request being authenticated by authenticating the at least one of the first entity and the second entity [see at least Paragraph 0177 for reference to the routing strategy to invoke a third party authentication service for automatically authenticating the called based on unique keys provided by the authentication service to the caller; Paragraph 0183 for reference to a security token or key that may have been provided to the mobile application upon authenticating to an external authentication server may also be transmitted with the request as context data]
receive, from at least one of the first entity and the second entity, an approval between the first entity and the second entity [see at least Paragraph 0223 for reference to context data is displayed by the agent application along with call management options, including options to accept or decline the interaction; Figures 34, 35, and 36 and related text regarding the exemplary screen displayed by the agent application of various media channels in which an incoming interaction may be accepted]
initiate between the first entity and the second entity, wherein the processor is to store an indication of an association of the first entity and the second entity [see at least Paragraph 0071 for reference to the customer application allowing customers to initiate contact with a contact center; Paragraph 0165 for reference to the system allowing the customer to initiate calls that are routed to service request owners; Paragraph 0174 for reference to the routing server generating a session ID for the data session between customer and agent; Paragraph 0175 for reference to the routing server transmits the data session ID with any agent availability information to the mobile server system; Paragraph 0185 for reference to data may be stored in association with a unique data session ID requested and assigned by the routing server]
While Booj discloses the limitations above, it does not disclose store the first profile, in response to successfully verifying the first entity, in an immutable form on a decentralized authentication framework, wherein the processor is to link a first unique token repository to the first profile of the first entity, the first unique token repository maintaining one or more tokens and each of the one or more tokens having assigned thereto a pre-defined token value; receive a request, from at least one of the first entity or a second entity, to initiate a transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity, the second entity comprising a second profile associated thereto on the decentralized authentication framework; retrieve, upon successful authentication of the request, the first profile and the second profile from the decentralized authentication framework; receive, from at least one of the first entity and the second entity, an approval to initiate the transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity; initiate the transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity, wherein the processor is to store an indication of an association of the first entity and the second entity in the decentralized authentication framework, wherein a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on the decentralized authentication framework.
However, Fostiropulo discloses the following:
store the first profile, in response to successfully verifying the first entity, in an immutable form on a decentralized authentication framework, wherein the processor is to link a first unique token repository to the first profile of the interested entity, the first unique token repository maintaining one or more tokens and each of the one or more tokens having assigned thereto a pre-defined token value [see at least Paragraph 0032 for reference to the system server communicating to a database cloud for storing public information to a blockchain; Paragraph 0033 for reference to electronic content being created in token format using the blockchain; Figure 2 and related text regarding item 240 ‘database cloud’ and item 260 ‘blockchain’; Figure 7 and related text regarding item 704 ‘ASSOCIATE CONTENT WITH TOKEN USING BLOCKCHAIN’]
receive a request, from at least one of the first entity or a second entity, to initiate a transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity, the second entity comprising a second profile associated thereto on the decentralized authentication framework, the second entity comprising a second profile associated thereto on the decentralized authentication framework [see at least Paragraph 0025 for reference to the system making record on a blockchain with pertinent corresponding information including personal information; Paragraph 0033 for reference to the blockchain storing information about asset owners (e.g., vendors and consumers); Paragraph 0034 for reference to the vendor application enabling the creation of a business profile including an account to power connections with end users; Figure 7 and related text regarding item 708 ‘CREATE 1ST RECORD ON BLOCKCHAIN’]
retrieve, upon successful authentication of the request, the first profile and the second profile from the decentralized authentication framework [see at least Paragraph 0032 for reference to the system server, depending on the type of communication request received, communicating to a database cloud for retrieving public information to a blockchain; Paragraph 0033 for reference to the blockchain storing information about asset owners (e.g., vendors and consumers); Paragraph 0034 for reference to the vendor application enabling the creation of a business profile including an account to power connections with end users]
receive, from at least one of the first entity and the second entity, an approval to initiate the transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity [see at least Paragraph 0026 for reference to blockchain implementation enables tokenizing of communications (e.g., tokenized sales, tokenized offers) to reduce computer bandwidth requirements and increase communication efficiency, thereby reducing communication costs; Paragraph 0043 for reference to system API server receives a request to initiate content delivery to the target group of end users through the vendor UI via the vendor application]
initiate the transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity [see at least Paragraph 0033 for reference to every token tracks from creation to release such that each action and transaction is validated, for example for the purpose of accurately tracking the efficiency and return on investment of a sales campaign initiated via the vendor system; Paragraph 0048 for reference to electronic content and the token is transmitted from the first computing system to the second computing system; Figure 7 and related text regarding item 704 ‘ASSOCIATED CONTENT WITH TOKENS USING BLOCKCHAIN’ & item 706 ‘TRANSMIT CONTENT & TOKEN FROM 1ST SYSTEM TO 2ND SYSTEM’; Figure 9 and related text regarding item 906 ‘TRANSFER 1ST DIGITAL CURRENCY VALUE FROM THE 2ST ENTITY TO THE USER’ and item 908 ‘RECORD TRANSFER OF 1ST DIGITAL CURRENCY VALUE ON BLOCKCHAIN’]
wherein the processor is to store an indication of an association of the first entity and the second entity in the decentralized authentication framework [see at least Paragraph 0041 for reference to interactions by an end user being recorded in the blockchain; Table 1 & Table 2 and related text regarding user interactions tracked by the blockchain]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the engagement system of Booij to include the decentralized authentication framework of Fostiropulo. Doing so enables this validation by storing information about asset owners (e.g., vendors and consumers) and enabling retrieval of true statistical information about transactions, as stated by Fostiropulo (Paragraph 0032).
While the combination of Booij and Fostiropulo disclose the limitations above, they do not disclose wherein a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on the decentralized authentication framework.
However, Barton discloses the following:
wherein a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on the decentralized authentication framework [see at least Paragraph 0043 for reference to tokens are attached to information flowing through the system to inform it about these activities and verify that the operations are valid wherein the data included in such tokens is in the clear; the token signature provides a way to verify that no tampering with the data in the token has occurred; Paragraph 0072 for reference to the unique ID of each entity allowing for rapid lookup of entity data; Paragraph 0115 for reference to the action table being an infinitely long record of all asset/ad serving activity by the service server wherein entities in the system are uniquely identified and those identifiers are recorded in the Action Table along with related events; Paragraph 0117 for reference to the action table being written using cryptographic blockchain techniques; Paragraph 0136 for reference to the action table being used to track token use; Figure 6 and related text regarding item 311 ‘Action Table’ and the ‘Lookup’ capabilities]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the engagement system of Booij to include the action table tracking activity of Barton. Doing so provides reporting on the progress of an asset/ad campaign in near real - time, both to more effectively manage the on-going campaign, and to provide quick detection of attacks on the integrity of the system, as stated by Barton (Paragraph 0040).
Regarding claim 8, the claim recites limitations already addressed by the rejection of claim 1. Regarding claim 8, Booij teaches a method for entity engagement [Paragraph 0023]. Therefore, claim 8 is rejected as being unpatentable over the combination of Booij, Fostiropulo, and Barton.
Claims 2 and 9
While the combination of Booij, Fostiropulo, and Barton disclose the limitations above, regarding Claim 2, Booij discloses the following:
wherein to initiate engagement between the first entity and the second entity, the processor is to: establish, based on the approval, an association between at least a subset of the first plurality of attributes and a corresponding subset of the second plurality of attributes to create an engagement of the first profile and the second profile [see at least Paragraph 0071 for reference to the customer application allowing customers to initiate contact with a contact center; Paragraph 0165 for reference to the system allowing the customer to initiate calls that are routed to service request owners; Paragraph 0174 for reference to the routing server generating a session ID for the data session between customer and agent; Paragraph 0174 for reference to the routing server invokes one or more business rules to identify an agent that may handle the call wherein the agent may be identified, for example, based on routing parameters included in the context data, such as for example, type of service requested (call, callback, and the like), language preferences, transaction type, and/or the like; Paragraph 0175 for reference to the routing server transmits the data session ID with any agent availability information to the mobile server system; Paragraph 0185 for reference to data may be stored in association with a unique data session ID requested and assigned by the routing server]
Regarding claim 9, the claim recites limitations already addressed by the rejection of claim 2.
Claim 3 and 10
While the combination of Booij, Fostiropulo, and Barton disclose the limitations above, Booij does not disclose wherein to initiate engagement between the first entity and the second entity, the processor is to: transfer a pre-defined token value from the first unique token repository to a second unique token repository, the second unique token repository being linked with the second profile and maintaining one or more tokens, each of the one or more tokens having assigned thereto a pre-defined token value.
Regarding Claim 3, Fostiropulo discloses the following:
wherein to initiate engagement between the first entity and the second entity, the processor is to: transfer a pre-defined token value from the first unique token repository to a second unique token repository, the second unique token repository being linked with the second profile and maintaining one or more tokens, each of the one or more tokens having assigned thereto a pre-defined token value [see at least Paragraph 0033 for reference to every token tracks from creation to release such that each action and transaction is validated, for example for the purpose of accurately tracking the efficiency and return on investment of a sales campaign initiated via the vendor system; Paragraph 0048 for reference to electronic content and the token is transmitted from the first computing system to the second computing system; Figure 7 and related text regarding item 704 ‘ASSOCIATED CONTENT WITH TOKENS USING BLOCKCHAIN’ & item 706 ‘TRANSMIT CONTENT & TOKEN FROM 1ST SYSTEM TO 2ND SYSTEM’; Figure 9 and related text regarding item 906 ‘TRANSFER 1ST DIGITAL CURRENCY VALUE FROM THE 2ST ENTITY TO THE USER’ and item 908 ‘RECORD TRANSFER OF 1ST DIGITAL CURRENCY VALUE ON BLOCKCHAIN’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the engagement system of Booij to include the transferring of tokens of Fostiropulo. Doing so would reduce computer bandwidth requirements and increase communication efficiency, thereby reducing communication costs, as stated by Fostiropulo (Paragraph 0026).
Regarding claim 10, the claim recites limitations already addressed by the rejection of claim 3.
Claims 4 and 11
While the combination of Booij, Fostiropulo, and Barton disclose the limitations above, Booij does not disclose wherein to initiate engagement between the first entity and the second entity of interest, the processor is to: execute a smart contract associated with the engagement between the first profile and the second profile, the smart contract being hosted on the decentralized authentication framework.
Regarding Claim 4, Fostiropulo discloses the following:
wherein to initiate engagement between the first entity and the second entity, the processor is to: execute a smart contract associated with the engagement between the first profile and the second profile, the smart contract being hosted on the decentralized authentication framework [see at least Paragraph 0044 for reference to the system API server enabling a user acquisition process wherein a smart contract enabled by the blockchain controls the execution of the user acquisition process; Paragraph 0045 for reference to end user actions include actions by an end user recordable through the smart contract via the blockchain; Figure 6 and related text regarding item 602 ‘SMART CONTRACT’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the engagement initiation of Booij to include the execution of the smart contract of Fostiropulo. Doing so enables this validation by storing information about asset owners (e.g., vendors and consumers) and enabling retrieval of true statistical information about transactions, as stated by Fostiropulo (Paragraph 0032).
Regarding claim 11, the claim recites limitations already addressed by the rejection of claim 4.
Claims 5 and 12
While the combination of Booij, Fostiropulo, and Barton disclose the limitations above, regarding Claim 5, Booij discloses the following:
update a record of engagements for the at least one of the first entity and the second entity, the record of engagements being associated with the at least one of the first unique identifier and the second unique identifier and the record of engagements including information regarding historical engagements of the at least one of the first entity and the second entity [see at least Paragraph 0192 for reference to the mobile server system maintains a history of successful and filed call matches in a database for reporting purposes, and for aiding the troubleshooting of potential; Paragraph 0192 for reference to each call-matching record may contain enough data for identification and troubleshooting purposes, such as, for example, timestamps (request time, call time, and the like), session identifier, mobile capabilities, custom data, and the like; Paragraph 0205 for reference to the customer application transmitting requests for updates associated with a specific session ID]
Regarding claim 12, the claim recites limitations already addressed by the rejection of claim 5.
Claims 7 and 14
While the combination of Booij, Fostiropulo, and Barton disclose the limitations above, regarding Claim 7, Booij discloses the following:
analyze the record of engagements to determine performance analytics for the engagement between the first entity and the second entity [see at least Paragraph 0192 for reference to the mobile server system maintains a history of successful and filed call matches in a database for reporting purposes, and for aiding the troubleshooting or potential issues; Paragraph 0192 for reference to a report being generated based on the call-matching information and statistics about successful and failed matched calls being determined]
Regarding claim 14, the claim recites limitations already addressed by the rejection of claim 7.
Claim 15
Regarding Claim 15, Booij discloses the following:
A non-transitory computer-accessible storage medium storing program comprising instructions, the instructions being executable by a processor to [see at least Paragraph 0088 for reference to computer program instructions are stored in a memory implemented using a standard memory device, such as, for example, a random access memory (RAM); Paragraph 0088 for reference to computer program instructions may also be stored in other non-transitory computer readable media such as, for example, a CD-ROM, flash drive, or the like; Paragraph 0088 for reference to the servers including one or more processors executing computer program instructions and interacting with other system components; Figure 1A and related text regarding a system supporting a contact center that is configured to provide mobile device support to contact center customers; Figure 1B and related text regarding the mobile server system]
receive an onboarding request from the first entity [see at least Paragraph 0136 for reference to as part of the registration process, the user enters via the settings page, personal information for the user such as, for example, the user’s email address, pin number, and telephone number; Figure 12 and related text regarding the settings page for registering a user with the associated contact center system]
generate a first profile for the first entity, the first profile including a first plurality of attributes, a first plurality of attribute values associated with each of the first plurality of attributes, and a first unique identifier associated with the first profile to identify the first entity [see at least Paragraph 0136 for reference to the mobile server system in turn communicates with associated database servers for generating and/or updating an associated customer record with the submitted information; Paragraph 0136 for reference to customer information including account number, password, address, birthdate, or the like]
verify the onboarding of first entity, wherein the instructions being executable to execute pre-defined veracity test sequences associated with at least a subset of the first plurality of attributes of the first plurality of attribute values to verify the first profile [see at least Paragraph 0136 for reference to the user information input while registering being used for authenticating the user; Paragraph 0193 for reference to if the context data includes a temporary security token provided by the authentication server, the routing strategy may include providing the security token to the authentication server for verifying that the authorized user of the token is the user that has placed the voice call]
store the first profile [see at least Paragraph 0087 for reference to the contact center also includes one or more mass storage devices for storing different databases relating to agent data (e.g. agent profiles, schedules, etc.), customer data (e.g. customer profiles), interaction data (e.g. details of each interaction with a customer, including reason for the interaction, disposition data, time on hold, handle time, etc.), and the like; Figure 1A and related text regarding item 30 ‘storage devices’]
While Booj discloses the limitations above, it does not disclose store the first profile, in response to successfully verifying the first entity, in an immutable form on a decentralized authentication framework, wherein the instructions being executable by the processor to link a first unique token repository to the first profile of the first entity, the first unique token repository maintaining one or more tokens and each of the one or more tokens having assigned thereto a pre-defined token value; and initiate a transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity, wherein the processor is to store an indication of an association of the first entity and the entity of interest in the decentralized authentication framework, wherein a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on the decentralized authentication framework.
However, Fostiropulo discloses the following:
store the first profile, in response to successfully verifying the first entity, in an immutable form on a decentralized authentication framework, wherein the processor is to link a first unique token repository to the first profile of the first entity, the first unique token repository maintaining one or more tokens and each of the one or more tokens having assigned thereto a pre-defined token value [see at least Paragraph 0032 for reference to the system server communicating to a database cloud for storing public information to a blockchain; Paragraph 0033 for reference to electronic content being created in token format using the blockchain; Figure 2 and related text regarding item 240 ‘database cloud’ and item 260 ‘blockchain’; Figure 7 and related text regarding item 704 ‘ASSOCIATE CONTENT WITH TOKEN USING BLOCKCHAIN’]
initiate a transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity [see at least Paragraph 0033 for reference to every token tracks from creation to release such that each action and transaction is validated, for example for the purpose of accurately tracking the efficiency and return on investment of a sales campaign initiated via the vendor system; Paragraph 0048 for reference to electronic content and the token is transmitted from the first computing system to the second computing system; Figure 7 and related text regarding item 704 ‘ASSOCIATED CONTENT WITH TOKENS USING BLOCKCHAIN’ & item 706 ‘TRANSMIT CONTENT & TOKEN FROM 1ST SYSTEM TO 2ND SYSTEM’; Figure 9 and related text regarding item 906 ‘TRANSFER 1ST DIGITAL CURRENCY VALUE FROM THE 2ST ENTITY TO THE USER’ and item 908 ‘RECORD TRANSFER OF 1ST DIGITAL CURRENCY VALUE ON BLOCKCHAIN’]
wherein the processor is to store an indication of an association of the first entity and the entity of interest in the decentralized authentication framework [see at least Paragraph 0041 for reference to interactions by an end user being recorded in the blockchain; Table 1 & Table 2 and related text regarding user interactions tracked by the blockchain]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the engagement system of Booij to include the decentralized authentication framework of Fostiropulo. Doing so enables this validation by storing information about asset owners (e.g., vendors and consumers) and enabling retrieval of true statistical information about transactions, as stated by Fostiropulo (Paragraph 0032).
While the combination of Booij and Fostiropulo disclose the limitations above, they do not disclose wherein a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on the decentralized authentication framework.
However, Barton discloses the following:
wherein a record of pre-defined token values for the transfer of tokens between the first entity and the second entity is recorded as a lookup table on the decentralized authentication framework [see at least Paragraph 0043 for reference to tokens are attached to information flowing through the system to inform it about these activities and verify that the operations are valid wherein the data included in such tokens is in the clear; the token signature provides a way to verify that no tampering with the data in the token has occurred; Paragraph 0072 for reference to the unique ID of each entity allowing for rapid lookup of entity data; Paragraph 0115 for reference to the action table being an infinitely long record of all asset/ad serving activity by the service server wherein entities in the system are uniquely identified and those identifiers are recorded in the Action Table along with related events; Paragraph 0117 for reference to the action table being written using cryptographic blockchain techniques; Paragraph 0136 for reference to the action table being used to track token use; Figure 6 and related text regarding item 311 ‘Action Table’ and the ‘Lookup’ capabilities]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the engagement system of Booij to include the action table tracking activity of Barton. Doing so provides reporting on the progress of an asset/ad campaign in near real - time, both to more effectively manage the on-going campaign, and to provide quick detection of attacks on the integrity of the system, as stated by Barton (Paragraph 0040).
Claim 16
While the combination of Booij, Fostiropulo, and Barton disclose the limitations above, regarding Claim 16, Booij discloses the following:
receive an engagement request, from at least one of the first entity and second entity, to initiate a profile engagement between the first entity and the second entity, the second entity comprising a second profile associated thereto, the second profile including a second plurality of attributes, a second plurality of attribute values associated with each of the second plurality of attributes, and a second unique identifier associated with the second profile to identify the second entity [see at least Paragraph 0094 for reference to when a customer invokes the customer application to transmit a request to be connected to a live agent, the context of the request is sent from the application to the mobile server system over a data channel for storing by the secure call matching module; Paragraph 0105 for reference to the customer application provides along with the chat request, context data about the user (also referred to as case information or session information) for allowing the agent to provide personalized customer service; Paragraph 0115 for reference to if a customer transmits a request for a real time interaction with an agent. such as, for example, voice call or chat, by selecting the appropriate option from the screen displayed in FIG. 3B, the routing server attempts to find an available agent to handle the interaction; Paragraph 0174 for reference to the routing server invokes one or more business rules to identify an agent that may handle the call wherein the agent may be identified, for example, based on routing parameters included in the context data, such as for example, type of service requested (call, callback, and the like), language preferences, transaction type, and/or the like; Paragraph 0211 for reference to the customer application transmits a request for interaction over a data channel, and includes a service request for callback; Paragraph 0226 for reference to agent availability associated with agent ID as well as location, telephone number, and/or extension of the particular device on which the mobile application is executed]
authenticate the request, the request being authenticated by authenticating the at least one of the first entity and the second entity [see at least Paragraph 0177 for reference to the routing strategy to invoke a third party authentication service for automatically authenticating the called based on unique keys provided by the authentication service to the caller; Paragraph 0183 for reference to a security token or key that may have been provided to the mobile application upon authenticating to an external authentication server may also be transmitted with the request as context data]
receive, from at least one of the first entity and the second entity, an approval to initiate between the first entity and the second entity [see at least Paragraph 0223 for reference to context data is displayed by the agent application along with call management options, including options to accept or decline the interaction; Figures 34, 35, and 36 and related text regarding the exemplary screen displayed by the agent application of various media channels in which an incoming interaction may be accepted]
While Booij discloses the limitations above, it does not disclose the second entity comprising a second profile associated thereto on the decentralized authentication framework; retrieve, upon successful authentication of the request, the first profile and the second profile from the decentralized authentication framework; and receive, from at least one of the first entity and the second entity, an approval to initiate a transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity.
However, Fostiropulo discloses the following:
the second entity comprising a second profile associated thereto on the decentralized authentication framework [see at least Paragraph 0025 for reference to the system making record on a blockchain with pertinent corresponding information including personal information; Paragraph 0033 for reference to the blockchain storing information about asset owners (e.g., vendors and consumers); Paragraph 0034 for reference to the vendor application enabling the creation of a business profile including an account to power connections with end users; Figure 7 and related text regarding item 708 ‘CREATE 1ST RECORD ON BLOCKCHAIN’]
retrieve, upon successful authentication of the request, the first profile and the second profile from the decentralized authentication framework [see at least Paragraph 0032 for reference to the system server, depending on the type of communication request received, communicating to a database cloud for retrieving public information to a blockchain; Paragraph 0033 for reference to the blockchain storing information about asset owners (e.g., vendors and consumers); Paragraph 0034 for reference to the vendor application enabling the creation of a business profile including an account to power connections with end users]
receive, from at least one of the first entity and the second entity, an approval to initiate a transfer of the one or more tokens having the pre-defined token value between the first entity and the second entity [see at least Paragraph 0026 for reference to blockchain implementation enables tokenizing of communications (e.g., tokenized sales, tokenized offers) to reduce computer bandwidth requirements and increase communication efficiency, thereby reducing communication costs; Paragraph 0043 for reference to system API server receives a request to initiate content delivery to the target group of end users through the vendor UI via the vendor application]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the engagement system of Booij to include the decentralized authentication framework of Fostiropulo. Doing so enables this validation by storing information about asset owners (e.g., vendors and consumers) and enabling retrieval of true statistical information about transactions, as stated by Fostiropulo (Paragraph 0032).
Claim 17
While the combination of Booij, Fostiropulo, and Barton disclose the limitations above, regarding Claim 17, Booij discloses the following:
wherein to initiate the engagement between the first entity and the second entity, the instructions being executable by a processor to: establish, based on the approval, an association between at least a subset of the first plurality of attributes and a corresponding subset of the second plurality of attributes to create an engagement of the first profile and the second profile [see at least Paragraph 0071 for reference to the customer application allowing customers to initiate contact with a contact center; Paragraph 0165 for reference to the system allowing the customer to initiate calls that are routed to service request owners; Paragraph 0174 for reference to the routing server generating a session ID for the data session between customer and agent; Paragraph 0174 for reference to the routing server invokes one or more business rules to identify an agent that may handle the call wherein the agent may be identified, for example, based on routing parameters included in the context data, such as for example, type of service requested (call, callback, and the like), language preferences, transaction type, and/or the like; Paragraph 0175 for reference to the routing server transmits the data session ID with any agent availability information to the mobile server system; Paragraph 0185 for reference to data may be stored in association with a unique data session ID requested and assigned by the routing server]
Claim 18
While the combination of Booij, Fostiropulo, and Barton disclose the limitations above, Booij does not disclose wherein to initiate engagement between the first entity and the second entity, the processor is to: transfer a pre-defined token value from the first unique token repository to a second unique token repository, the second unique token repository being linked with the second profile and maintaining one or more tokens, each of the one or more tokens having assigned thereto a pre-defined token value.
Regarding Claim 18, Fostiropulo discloses the following:
wherein to initiate the engagement between the first entity and the second entity, the instructions being executable by a processor to: transfer a pre-defined token value from the first unique token repository to a second unique token repository, the second unique token repository being linked with the second profile and maintaining one or more tokens, each of the one or more tokens having assigned thereto a pre-defined token value [see at least Paragraph 0033 for reference to every token tracks from creation to release such that each action and transaction is validated, for example for the purpose of accurately tracking the efficiency and return on investment of a sales campaign initiated via the vendor system; Paragraph 0048 for reference to electronic content and the token is transmitted from the first computing system to the second computing system; Figure 7 and related text regarding item 704 ‘ASSOCIATED CONTENT WITH TOKENS USING BLOCKCHAIN’ & item 706 ‘TRANSMIT CONTENT & TOKEN FROM 1ST SYSTEM TO 2ND SYSTEM’; Figure 9 and related text regarding item 906 ‘TRANSFER 1ST DIGITAL CURRENCY VALUE FROM THE 2ST ENTITY TO THE USER’ and item 908 ‘RECORD TRANSFER OF 1ST DIGITAL CURRENCY VALUE ON BLOCKCHAIN’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the engagement system of Booij to include the transferring of tokens of Fostiropulo. Doing so would reduce computer bandwidth requirements and increase communication efficiency, thereby reducing communication costs, as stated by Fostiropulo (Paragraph 0026).
Claim 19
While the combination of Booij, Fostiropulo, and Barton disclose the limitations above, Booij does not disclose wherein to initiate engagement of the first profile and the second profile, the instructions being executable by a processor is to: execute a smart contract associated with the engagement between the first profile and the second profile, the smart contract being hosted on the decentralized authentication framework.
Regarding Claim 19, Fostiropulo discloses the following:
wherein to initiate the engagement of the first profile and the second profile, the instructions being executable by a processor to: execute a smart contract associated with the engagement between the first profile and the second profile, the smart contract being hosted on the decentralized authentication framework [see at least Paragraph 0044 for reference to the system API server enabling a user acquisition process wherein a smart contract enabled by the blockchain controls the execution of the user acquisition process; Paragraph 0045 for reference to end user actions include actions by an end user recordable through the smart contract via the blockchain; Figure 6 and related text regarding item 602 ‘SMART CONTRACT’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the engagement initiation of Booij to include the execution of the smart contract of Fostiropulo. Doing so enables this validation by storing information about asset owners (e.g., vendors and consumers) and enabling retrieval of true statistical information about transactions, as stated by Fostiropulo (Paragraph 0032).
Claim(s) 6, 13, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Booij (U.S 2014/0164256 A1) in view of Fostiropulo (U.S 2020/0134612 A1) in view of Barton (U.S 2022/0012770 A1), as applied in claims 1, 8, and 16, in view of Sethumadhavan (U.S 2022/0129905 A1).
Claims 6 and 13
While the combination of Booij, Fostiropulo, and Barton disclose the limitations above, they do not disclose wherein to execute pre-defined veracity test sequences, the processor is to: analyze historical data associated with the first entity to provide a confidence score to an attribute of the subset of the first plurality of attributes, the attribute being verified when the confidence score is above a pre-defined confidence score threshold value.
Regarding Claim 6, Sethumadhavan discloses the following:
wherein to execute pre-defined veracity test sequences, the processor is to: analyze historical data associated with the first entity to provide a confidence score to an attribute of the subset of the first plurality of attributes, the attribute being verified when the confidence score is above a pre-defined confidence score threshold value [see at least Paragraph 0048 for reference to the system analyzing the confidence score against a predefined threshold; Claim 5 and related text regarding determining the confidence score comprising analyzing at least one or previous interactions with the customer device]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the test sequences of Booij to include the evaluation of historical data against a confidence score threshold of Sethumadhavan. Doing so would provide interaction context and facilitating intent-driven engagement to better assist the customers, as stated by Sethumadhavan (Paragraph 0009).
Regarding claim 13, the claim recites limitations already addressed by the rejection of claim 6.
Claim 20
While the combination of Booij, Fostiropulo, and Barton disclose the limitations above, they do not disclose wherein to execute one of the pre-defined veracity test sequences, the instructions being executable by a processor to: analyze historical data associated with the first entity to provide a confidence score to an attribute of the subset of the first plurality of attributes, the attribute being verified when the confidence score is above a pre-defined confidence score threshold value.
Regarding Claim 20, Sethumadhavan discloses the following:
wherein to execute one of the pre-defined veracity test sequences, the instructions being executable by a processor to: analyze historical data associated with the first entity to provide a confidence score to an attribute of the subset of the first plurality of attributes, the attribute being verified when the confidence score is above a pre-defined confidence score threshold value [see at least Paragraph 0048 for reference to the system analyzing the confidence score against a predefined threshold; Claim 5 and related text regarding determining the confidence score comprising analyzing at least one or previous interactions with the customer device]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the test sequences of Booij to include the evaluation of historical data against a confidence score threshold of Sethumadhavan. Doing so would provide interaction context and facilitating intent-driven engagement to better assist the customers, as stated by Sethumadhavan (Paragraph 0009).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bruschi, Francesco, et al. "A decentralized system for fair token distribution and seamless users onboarding." 2020 IEEE Symposium on Computers and Communications (ISCC). IEEE, 2020.
DOCUMENT ID
INVENTOR(S)
TITLE
US 12,333,560 B1
Bhan, Vaibhav
Method and system of sentiment-based selective user engagement
US 2024/0362735 A1
Lombard et al.
Apparatus and a method for automatically generating a profile evaluation
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 KRISTIN ELIZABETH GAVIN whose telephone number is (571)270-7019. The examiner can normally be reached M-F 7:30-4:30 PM EST.
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, Jerry O'Connor can be reached at 5712726787. 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.
/KRISTIN E GAVIN/Primary Examiner, Art Unit 3624