DETAILED ACTION
This final Office action is responsive to amendments filed November 11th, 2025. Claims 1-4 have been amended. Claims 5-6 have been added. Claims 1-6 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, see page 5, filed 11/11/25, with respect to claims 1-3 have been fully considered and are persuasive. The claim objections of 8/15/25 has been withdrawn.
Applicant's arguments regarding claim rejections under 35 USC 101 filed 11/11/25 have been fully considered but they are not persuasive.
On pages 5-10 of the provided remarks, Applicant argues that the amended claims represent statutory subject matter. Beginning on page 7 of the provided remarks, Applicant argues “Claims 1-4 are not directed to Judicial exception (abstract idea)”. Specifically, on page 8 of the provided remarks, Applicant cites paragraph [0013] of the as-filed Specification to argue that the claims “address a specific technical challenge of verifying the authenticity of a service agent or caller in a remote communication environment, which cannot be performed mentally and is not a conventional business method.” Examiner respectfully disagrees and asserts that the verification of the authenticity of a service agent or caller can be performed mentally and as an abstract concept of managing personal behavior as the claims fail to recite the active verification of the identity. The claims merely recite “in response to the validation being successful” and do not recite active verification of the authenticity of a service agent or caller. Additionally, the claimed “said authenticating is performed using a corresponding single sign-on (SSO) identifier” again fails to recite the performance of an authentication method or any technical detail as to how the authentication is performed by the system. The argued “use of a single sign-on” is recited with a high-level of generality such that this “use of an identifier” could be a mere observation and judgment of the human mind. Therefore, the claims recite an abstract idea. Applicant’s arguments are not persuasive.
On page 8 of the provided remarks, Applicant argues “the server of the present invention performs multiple interrelated operations that improve upon existing identity and assignment systems by ensuring authentication across roles via SSO mechanisms, preventing premature identity disclosure by gating token generation to post-approval events and additionally, restricting sensitive information display until successful validation.” Examiner respectfully disagrees and begins by asserting, as stated above, the claimed “said authenticating is performed using a corresponding single sign-on (SSO) identifier” again fails to recite the performance of an authentication method or any technical detail as to how the authentication is performed by the system. The argued “use of a single sign-on” is recited with a high-level of generality such that this “use of an identifier” could be a mere observation and judgment of the human mind. Additionally, the argued “gating token generation” is claimed merely as “enabling the third client device associated with the assignment owner to generate an identity token” and “communicating the identity token to a user device”. Examiner asserts that the argued “gating” method is not present within the claim as the cited “enabling the third client device” and “communicating” are recited with a high-level of generality such that these functions can be interpreted under broadest reasonable interpretation to be sending and receiving data over a network. Finally, the argued “restricting sensitive information” is not present within the claim as the recited “in response to the validation being successful” does not include the determination by the system of the validity of the validation request by the server. Similar to the argued SSO mechanisms, the claim fails to include the active restriction of sensitive information by the server. Finally, the argued “server” 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). Applicant’s arguments are not persuasive.
Continuing on page 8 of the provided remarks, Applicant argues “Clearly, the evolved and intelligent system disclosed in the claimed subject matter solves the complex problem of providing a social notification system for identity verification of customer service agents or callers, which allows the users to validate the legitimacy while sharing sensitive information with an agent on phone, thereby protecting the user from frauds.” Examiner respectfully disagrees and asserts, citing MPEP 2106.05(a), “if the specification explicitly sets forth an improvement but in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine the claim improves technology. An indication that the claimed invention provides an improvement can include a discussion in the specification that identifies a technical problem and explains the details of an unconventional technical solution expressed in the claim, or identifies technical improvements realized by the claim over the prior art.” Examiner regards the conclusory manner of the presented argument as not persuasive in proving the improvement to technology. Additionally, Examiner asserts that the argued problem of “providing a social notification system” is not a “technical problem” as the argued method of “identity verification of customer service agents or callers, which allows the users to validate the legitimacy” is not technical but a human ability and mental evaluation. Applicant’s arguments are not persuasive.
On pages 8-9 of the provided remarks, Applicant argues “the subject matter claimed in the amended claims 1-4 provides an improvement in the technical field identity verification, which helps to prevent fraud and protect customer privacy. This can also prevent deceitful persons or entities from posing as legitimate business representatives to extort money or other benefits from customers.” Examiner respectfully disagrees and cites MPEP 2106.05(a) “That is, the claim must include the components or steps of the invention that provide the improvement described in the specification. However, the claim itself does not need to explicitly recite the improvement described in the specification (e.g., "thereby increasing the bandwidth of the channel"). The full scope of the claim under the BRI should be considered to determine if the claim reflects an improvement in technology (e.g., the improvement described in the specification).” As stated above, the claim does not recite the components or steps of the invention that provide the argued improvement as the claim fails to recite the performance of an authentication/verification method or any technical detail as to how the authentication/verification is performed by the system. Therefore, Applicant’s argument regarding an improvement to a technical problem is not persuasive.
On pages 9-10 of the provided remarks, Applicant argues “Claims recite additional element(s) that amount to significantly more than the judicial exception (abstract idea)”. Specifically, Applicant argues “token generation is conditioned on prior approval; identity is not communicated until validation is completed; and all communications are routed through designated client devices associated with specific roles” presents significantly more than a judicial exception by including non-conventional and non-generic arrangements of computing components. Beginning with the argued “token generation is conditioned on prior approval”, as stated above, the claim recites “enabling the third client device associated with the assignment owner to generate an identity token” which does not actively recite the argued “token generation” being performed by the argued server. The argued “identity not communicated until validation is completed” 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. Further, the argued “all communications are routed through designated client devices associated with specific roles” similar to above 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. The argued “designated client devices associated with specific roles” 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). Therefore, Applicant’s argument regarding the claims reciting significantly more is not persuasive.
Continuing on page 10 of the provided remarks, Applicant argues “Applicant submits that the claimed subject matter when taken as a whole, does not simply describe a mere computer program, but describes the use of a server and multiple client devices, each tied to a specific role, interacting via authenticated SSO credentials. Additionally, the claimed subject-matter describes conditional token generation based on assignment approval, which enables token-based secure identity matching. Further, the claimed subject matter include the technique of user-side validation that conditionally exposes the assignment card. These are not generic or conventional steps performed in a routine manner; rather, they are concrete implementations to address real-world problems related to remote verification of caller identity.” Examiner respectfully disagrees and begins by asserting that the argued “use of a server and multiple client devices, each tied to a specific role”, as stated above, 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 argued “conditional token generation based on assignment approval” and “user-side validation”, as stated above, are not present in the claims as being performed by the argued “server” but merely “enabled” to be performed. Further, the “exposure of the assignment card” 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. Therefore, Applicant’s argument regarding the claims reciting significantly more is not persuasive. The 35 USC 101 rejection is maintained.
Applicant’s arguments, see pages 10-14, filed 11/11/25, with respect to the rejection(s) of claim(s) 1-2 under 35 USC 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Elenbaas (U.S 2009/0204471 A1) in view of Silvain (U.S 2007/0174390 A1) in view of Shaffer (U.S 2020/0396221 A1).
Applicant’s arguments, see pages 14-16, filed 11/11/25, with respect to the rejection(s) of claim(s) 2-4 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Elenbaas (U.S 2009/0204471 A1) in view of Silvain (U.S 2007/0174390 A1) in view of Shaffer (U.S 2020/0396221 A1).
Claim Objections
Claim 2 is objected to because of the following informalities: the limitation beginning “upon receiving said approval” recites “associated with the customer” which lacks antecedent basis and should recite “a customer”. 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-6 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.
Step 1: Independent claims 1 (system), 2 (method), and dependent claims 3-6, 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 2 is directed to a method (i.e. process).
Step 2A Prong 1: The independent claims recite identity and assignment verification, the method comprising: authenticating, at a server, a first client device associated with an assignment manager, a second client device associated with an assignment approver, and a third client device associated with an assignment owner, wherein said authenticating is performed using a corresponding single sign-on (SSO) identifier; receiving, by the server, identifying information pertaining to one or more service assignments from the first client device associated with the assignment manager, wherein the identifying information includes at least one of a customer ID, a name of the assignment owner, an employment type, and a purpose of each of the assignment; receiving, by the server from a second client device, an approval of a service assignment of the one or more service assignments from the second client device associated with the assignment approver; upon receiving said approval, at the server, enabling the third client device associated with the assignment owner to generate an identity token and communicating the identity token to a user device associated with the customer requesting identity verification through a selected communication medium; receiving, by the server, a validation request from the user device, said validation request comprising the identity token; in response to the validation being successful, retrieving and presenting, by the server, an assignment card to the user device, wherein the assignment card includes at least one of the name of the assignment owner, the employment type, and the purpose of the assignment (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 performing identity and assignment verification involving authenticating various devices and enabling the creation of an identity token, which is managing personal behavior. The Applicant’s claimed limitations are performing identity and assignment verification, 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 performing identity and assignment verification involving authenticating various devices and enabling the creation of an identity token, which are observations, judgments, and evaluations of the human mind. The Applicant’s claimed limitations are performing identity and assignment verification, which recite the abstract idea of Mental Process.
In addition, dependent claims 3, 5, and 6 further narrow the abstract idea and recite further defining the validation request and session; capturing an outcome of the service assignment, one or more next steps, and feedback from the client; and in response to the validation failing, reporting the assignment to an external agency. 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 behaviors and mental processes. Accordingly, these claim elements do not serve to confer subject matter eligibility to the claims since they recite abstract ideas. Dependent claim 4 will be discussed in Prong 2 analysis below.
Step 2A Prong 2: In this application, the above “receiving, by the server, identifying information pertaining to one or more service assignments from the first client device associated with the assignment manager, wherein the identifying information includes at least one of a customer ID, a name of the assignment owner, an employment type, and a purpose of each of the assignment; receiving, by the server from a second client device, an approval of a service assignment of the one or more service assignments from the second client device associated with the assignment approver; communicating the identity token to a user device associated with the customer requesting identity verification through a selected communication medium; receiving, by the server, a validation request from the user device, said validation request comprising the identity token; in response to the validation being successful, retrieving and presenting, by the server, an assignment card to the user device, wherein the assignment card includes at least one of the name of the assignment owner, the employment type, and the purpose of the assignment” 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, implemented using a server; a first client device associated with an assignment manager; a second client device associated with an assignment approver; a third client device associated with an assignment owner; a user device; A computer” 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).
Independent claims 1-2 recite “wherein said authenticating is performed using a corresponding single sign-on (SSO) identifier”. Notably, the use of “SSO” to authenticate the user, absent the generic server for implementing it, encompasses nothing more than managing personal behavior as acknowledged in Applicant’s Specification (at least Paragraph 0028 “Digital identity validation here represents validation using legal entities/business SSO, government issued IDs, social network verified accounts and any other digital identities.”), which does not amount to an “additional element” or practical application.
In addition, dependent claims 3, 5, and 6 further narrow the abstract idea and dependent claims 3-6 additionally recite “wherein the validation request from the user device is received by the server during a single session performed by the assignment owner”; “wherein the selected communication medium includes at least one of a phone call, a VOIP call, a post mail, an instant messaging app, a SMS, a MMS, and a multimedia message”; “in response to the validation being failed, the server presents a fraud alert to the user device” 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 “server” and “user device” 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, implemented using a server; a first client device associated with an assignment manager; a second client device associated with an assignment approver; a third client device associated with an assignment owner; a user device; A computer” 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 2-6; and system claim 1 recite “A system, implemented using a server; a first client device associated with an assignment manager; a second client device associated with an assignment approver; a third client device associated with an assignment owner; a user device; A computer”; 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 0036-0041 and Figures 1 & 8. 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, by the server, identifying information pertaining to one or more service assignments from the first client device associated with the assignment manager, wherein the identifying information includes at least one of a customer ID, a name of the assignment owner, an employment type, and a purpose of each of the assignment; receiving, by the server from a second client device, an approval of a service assignment of the one or more service assignments from the second client device associated with the assignment approver; communicating the identity token to a user device associated with the customer requesting identity verification through a selected communication medium; receiving, by the server, a validation request from the user device, said validation request comprising the identity token; in response to the validation being successful, retrieving and presenting, by the server, an assignment card to the user device, wherein the assignment card includes at least one of the name of the assignment owner, the employment type, and the purpose of the assignment” 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, the use of single sign-on authorization is well-understood, routine, and conventional in the art. See, e.g., Bowers et al., US 2003/0014519 A1 (par. 0008), noting that “Conventional SSO systems do nothing to solve this problem.” See also, Katsube et al., US 2004/0025056 A1 (Fig. 2-5), noting “operation in the conventional for utilizing an SSO service”. Accordingly, the additional element directed to a single sign-on authorization fails to add significantly more to the claims.
In addition, claims 3, 5, and 6 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-6 additionally recite “wherein the validation request from the user device is received by the server during a single session performed by the assignment owner”; “wherein the selected communication medium includes at least one of a phone call, a VOIP call, a post mail, an instant messaging app, a SMS, a MMS, and a multimedia message”; “in response to the validation being failed, the server presents a fraud alert to the user device” 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 “server” and “user device” 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.
Claim(s) 1-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Elenbaas (U.S 2009/0204471 A1) in view of Silvain (U.S 2007/0174390 A1) in view of Shaffer (U.S 2020/0396221 A1).
Claims 1 and 2
Regarding Claim 1, Elenbaas discloses the following:
A system, implemented using a server, for identity and assignment verification, wherein the server is configured to perform operations comprising [see at least Paragraph 0006 for reference to the system for assigning different levels of trustworthiness of a user accessing an online work management system; Paragraph 0064 for reference to the work management system including a work management server; Paragraph 0071 for reference to the work management system includes emails and voice communication system to facilitate various operations including, among others, job scheduling, notification, and reporting of the results of the tasks; Figure 1 and related text regarding components of a work management system communicating over a network including item 160 ‘work management server’; Figure 2 and related text regarding the work management server; Figure 10 and related text regarding a work management system interacting with partner services]
authenticating, at a server, a first client device associated with an assignment manager, a second client device associated with an assignment approver, and a third client device associated with an assignment owner, wherein said authenticating is performed using a corresponding single sign-on (SSO) identifier [see at least Paragraph 0068 for reference to the users of the work management server including workers, job owners, and intermediators; Paragraph 0068 for reference to these users logging into the work management server; Paragraph 0094 for reference to the one or more modules of Figure 2 being transferred to other user terminals; Paragraph 0137 for reference to the worker profile storing workers authentication information (log-in name and password); Figure 2 and related text regarding item 250 ‘job owner module’ and item 286 ‘intermediator support module’; Figure 20 and related text regarding item 2002 ‘Seng Log-in Information’ and item 2006 ‘Receive Log-in Information’]
receiving, by the server, identifying information pertaining to one or more service assignments from the first client device associated with the assignment manager, wherein the identifying information includes at least one of a customer ID, a name of the assignment owner, an employment type, and a purpose of each of the assignment [see at least Paragraph 0068 for reference to the users of the work management server including workers, job owners, and intermediators; Paragraph 0068 for reference to these users logging into the work management server; Paragraph 0078 for reference to the job owner manually generating the job descriptions; Paragraph 0115 for reference to the job owner defining a task and providing directions to the workers; Paragraph 0117 for reference to the job table including fields such as Job/Task ID, type of job, User ID, PID, user ID provider, comments, status, Sec Clear, Geography, and Subprojects; Paragraph 0211 for reference to the intermediator creating subtasks for the selected tasks based on the intermediator’s expertise; Paragraph 0212 for reference to the intermediator arbitrating between the demands of the job owner and the capabilities of the available workers to design the task template organizing the task into subtasks; Figure 6A and related text regarding data structures for storing job descriptions and task descriptions including item 612 ‘job table’; Figure 15B and related text regarding ‘Create Job/Task Using Template’ and item 1526 ‘Receive Parameters for Initiating Job or Task Creation’]
receiving, by the server from a second client device, an approval of a service assignment of the one or more service assignments from the second client device associated with the assignment approver [see at least Paragraph 0074 for reference to the job owner module approving workers; Paragraph 0094 for reference to the one or more modules of Figure 2 being transferred to other user terminals; Paragraph 0103 for reference to the process determining if the job owner approved the worker; Figure 2 and related text regarding item 250 ‘job owner module’; Figure 4A and related text regarding item 434 ‘Applicant Approved?’; Figure 4B and related text regarding item 468 ‘Job Owner Approves?’]
receiving, by the server, a validation request from the user device, said validation request comprising the identity token [see at least Paragraph 0068 for reference to the users of the work management server including workers, job owners, and intermediators; Paragraph 0068 for reference to these users logging into the work management server; Paragraph 0072 for reference to the communication module communicating with other components of the work management system; Paragraph 0161 for reference to information for accessing the partner services (e.g., a login ID and a password) is obtained from the partner services; Paragraph 0209 for reference to notifications being sent via a variety of communication means including emails, SMS, and instant messages; Paragraph 0252 for reference to the user table providing a unique indexing key; Figure 20 and related text regarding item 2002 ‘Seng Log-in Information’ and item 2006 ‘Receive Log-in Information’]
While Elenbaas discloses the limitations above, it does not disclose upon receiving said approval, at the server, enabling the third client device associated with the assignment owner to generate an identity token and communicating the identity token to a user device associated with the customer requesting identity verification through a selected communication medium; receiving, by the server, a validation request from the user device, said validation request comprising the identity token; and in response to the validation being successful, retrieving and presenting, by the server, an assignment card to the user device, wherein the assignment card includes at least one of the name of the assignment owner, the employment type, and the purpose of the assignment.
However, Silvain discloses the following:
receiving, a validation request from the user device, said validation request comprising the identity token [see at least Paragraph 0275 for reference to the user being provided log-in information following authentication; Paragraph 0276 for reference to a determination being made as to whether the log-in information is valid]
in response to the validation being successful, retrieving and presenting, by the server, an assignment card to the user device, wherein the assignment card includes at least one of the name of the assignment owner, the employment type, and the purpose of the assignment [see at least Paragraph 0078 for reference to case qualifications referring to a collection of information regarding the nature of the case, product, or service; Paragraph 0081 for reference to service level agreements referring to the level of service provided including the type of services to be performed by the CSM provider, time periods of services, and level of expertise; Paragraph 0191 for reference to the case being generated based on the received customer service request including customer context, service context, request context, and knowledge context; Paragraph 0191 for reference to customer context includes information related to one or more of a customer account profile, a customer contact profile, a service contract, a service level agreement (SLA), and a customer history; Paragraph 0202 for reference to the case template including customer context information (e.g., customer/contact identification information, contract/ account information, and any SLA information), and case qualification information; Paragraph 0207 for reference to the self-service portion allowing users to create new cases, view existing cases, view or modify customer context information, and/or view or generate reports or statistics; Paragraph 0275 for reference to the user being provided log-in information following authentication; Paragraph 0277 for reference to the user being presented with a personalized portal screen that is associated with the user; Figure 13 and related text regarding providing access to the CSM system through a self-service portal; Figure 14 and related text regarding case creation through a self-service portal]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the system of Elenbaas to include the customer over the phone verification and assignment display of Silvain. Doing so provides immediate identification of the corresponding context information, which will reduce the time needed to create a case, as stated by Silvain (Paragraph 0232).
While Elenbaas and Silvain disclose the limitations above, they do not disclose upon receiving said approval, at the server, enabling the third client device associated with the assignment owner to generate an identity token and communicating the identity token to a user device associated with the customer requesting identity verification through a selected communication medium.
However, Shaffer discloses the following:
upon receiving said approval, at the server, enabling the third client device associated with the assignment owner to generate an identity token and communicating the identity token to a user device associated with the customer requesting identity verification through a selected communication medium [see at least Paragraph 0205 for reference to an identity token 2310 may be created as soon as the customer 2305 is verified, rating the veracity of the customer verification (e.g., from fully trusted down to completely unverified), and moving the identity token around between apps and agents as the customer is moved from agent to agent; Paragraph 0230 for reference to the persona of a user, and associated privileges or permissions, may be controlled by a third - party entity, such as an organization, company, person, etc., which enables management of the relationship between that user and a second entity (e.g., another user, a call center, etc. ), accordingly; Paragraph 0240 for reference to the techniques herein inquire with the appropriate third-party entity to ensure that the suggested persona of the user is still valid, and any privilege level, permissions, restrictions, and so on associated with the persona and corresponding transactions that may occur during the communication; Figure 23 and related text regarding item 2315 ‘new token’ and item 2310 ‘verification token’]
receiving, by the server, a validation request from the user device, said validation request comprising the identity token [see at least Paragraph 0205 for reference to the AVS client application on the mobile device issuing a new security token on demand in response to any authenticated application that requests it; Figure 23 and related text regarding item 2315 ‘new token’ and item 2310 ‘verification token’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the system of Elenbaas to include the identity token generation and permission distribution of Shaffer. Doing so would allow for greater acceptance of providing verified identity, while alleviating a lot of perceived customer friction such as customers being asked by each different application / agent on a single phone call to be authenticated, as stated by Shaffer (Paragraph 0205).
Regarding claim 2, the claim recites limitations already addressed by the rejection of claim 1. Regarding claim 2, Elenbaas teaches a computer-implemented method [Paragraph 0006]. Therefore, claim 2 is rejected as being unpatentable over the combination of Elenbaas, Silvain, and Shaffer.
Claim 3
While the combination of Elenbaas, Silvain, and Shaffer disclose the limitations above, Elenbaas does not disclose wherein the validation request from the user device is received by the server during a single session performed by the assignment owner, wherein the session comprises a caller introduction, purpose of call and assignment verification.
Regarding Claim 3, Silvain discloses the following:
wherein the validation request from the user device is received by the server during a single session performed by the assignment owner, wherein the session comprises a caller introduction, purpose of call and assignment verification [see at least Paragraph 0190 for reference to the customer service request being received via phone; Paragraph 0231 for reference to an integrated voice response system and/or other automated System to interface with the caller to confirm the customer identity; Paragraph 0234 for reference to the creation of a new customer identification in the CSM system and providing information to the caller; Figure 9 and related text regarding the case creation process]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the system of Elenbaas to include the customer over the phone verification of Silvain. Doing so provides immediate identification of the corresponding context information, which will reduce the time needed to create a case, as stated by Silvain (Paragraph 0232).
Claim 4
While the combination of Elenbaas, Silvain, and Shaffer disclose the limitations above, regarding Claim 4, Elenbaas discloses the following:
wherein the selected communication medium including at least one of a phone call, a VOIP call, a post mail, an instant messaging app, a SMS, a MMS, and a multimedia message [see at least Paragraph 0072 for reference to the communication module communicating with other components of the work management system; Paragraph 0209 for reference to notifications being sent via a variety of communication means including emails, SMS, and instant messages]
Claim 5
While the combination of Elenbaas, Silvain, and Shaffer disclose the limitations above, regarding Claim 5, Elenbaas discloses the following:
capturing, by the server, an outcome of the service assignment, one or more next steps, and feedback from the client [see at least Paragraph 0137 for reference to the task history database storing the workers previous history of tasks and any feedback or reviews of the workers provided by the job owners; Paragraph 0182 for reference to reputation reports being generated and presented to workers and job owners after a job is completed and feedback is provided; Figure 22 and related text regarding item 2204 ‘Receive and Store User’s Response to Evaluation’]
Claim 6
While the combination of Elenbaas, Silvain, and Shaffer disclose the limitations above, regarding Claim 6, Elenbaas discloses the following:
in response to the validation being failed, the server presents a fraud alert to the user device and provides an option to report the assignment to an external agency [see at least Paragraph 0135 for reference to if discrepancies are found between the worker information profile then a discrepancy alert signal will flag the workers identity as possibly fraudulent; Paragraph 0136 for reference to the fraud detection module analyzes not only the worker's profile but other information such as patterns of transaction between job owners and workers, duplicative working hour entries for the same worker in different tasks, and suspicious grouping of workers in similar tasks; Paragraph 0136 for reference toa fraud alert signal being fed to the evaluation engine and further investigation being conducted; Figure 7 and related text regarding item 732 ‘Fraud Detector’]
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
DOCUMENT ID
INVENTOR(S)
TITLE
US 10,893,142 B1
Burton et al.
Contact Center Authentication
US 10,117,098 B1
Naguthanawala et al.
User Authentication Verification Service
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 571-272-6787. 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