DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20130208893 A1 (Shablygin et al.) (hereinafter Shablygin) in view of US 20150087265 A1 (Disraeli et al.)
In re claims 1 and 14, Shablygin discloses a system and a method of verifying that incoming telephone calls to respective customers originate from a business entity known to the customers (Fig. 1A:32, [0004], “The methods also include the actions of subsequent to receiving the request, verifying the service provider is authorized to request verification that the user has membership in the group”), the method comprising the steps of: transmitting, from one or more servers associated with the business entity, a customer application to a customer device of each of the customers for installation on the customer device ([0006], “The methods may also include the actions of receiving, at a computer system associated with the service provider, the ticket, and sending, from the computer system associated with the service provider, the ticket to a client device associated with the user. Verifying the service provider is authorized to verify that the user has membership in the group may include obtaining an access control list associated with the group”), wherein the customer application identifies the business entity associated therewith and is configured to: determine an occurrence of a triggering event signaling an authentication attempt for authenticating a telephone call to a one of the customers (Fig. 17, [0067], “Prior to retrieval of the data from storage, the service provider is also authenticated 37. The service provider can be authenticated via a secure method such as the authentication methods described herein”); generate, in response to determining the occurrence of the triggering event, a customer-side version of a verification code for use in each authentication attempt ([0069], “The authentication system authenticates not only the user 26 but also the service provider 20 before allowing access to the secured data in the data container 10. While the user ID 28 and the service provider ID 22 become known to the authentication system during the authentication process, they are retained in the authentication system for a limited length of time. After authentication of the service provider and the user, the user ID 28 and the service provider ID 22 are combined to generate the unique data container identifier 14 that identifies the location of the data container 10”. [0070], “For example, the user ID 28 and the service provider ID 22 can each be a sting of alphanumeric characters (e.g., a string of 64 digits). In the example to follow the user ID 28 and the service provider ID 22 are described as a string of eight numeric digits for simplicity”); and generate a user interface on the customer device that displays the generated customer-side version of a verification code (Fig. 18, [0283], “As seen in the example of FIG. 18, a token owner can begin the token creation process by selecting the link labeled "Make a Key". The token management service receives the request for authentication and activation of the token (block 338) and sends a request for two-factor authentication to an authentication service (block 340). The token management service sends the request to the authentication service rather than performing the authentication itself to protect the secrecy of the information stored on the token and the token owner's passcode which are used to activate the token”); performing an authentication process in relation to each authentication attempt ([0288], “The mobile device displays the message to the human user; e.g., "Token Manager wants to activate your token. Please enter your passcode." The human owner enters the passcode on the mobile device's keyboard”), wherein, when described in relation to an exemplary first authentication attempt related to authenticating that a first telephone call initiated from a first agent device by an agent to a first customer device associated with a first customer originates from a first business entity, the authentication process comprises the steps of: receiving, by a verification module disposed within the one or more servers, data transmitted from the customer application on the first customer device that notifies of the triggering event occurring ([0279], “The activation process begins with a token owner 325 in possession of an inactive token (e.g., token 326). The token owner 325 submits a request to a token management service 324 to activate the token 326 (arrow 328). Upon receiving the request, the token management service 324 sends a request to an authentication service 320 to authenticate the token (arrow 330) with two factors--token authentication and passcode authentication”); generating, by the verification module, a business-side version of the verification code for use in association with the first authentication attempt; generating, by the customer application on the first customer device, the customer-side version of the verification code for use in association with the first authentication attempt; generating, by the customer application on the first customer device for display on the first customer device, the user interface showing the customer-side version of the verification code ([0127], “For applications of a token requiring high security, the token--or the token in combination with an input/output element--may include the following components: a keypad (alphanumeric), interactive display, or other type of data entry mechanism (collectively referred to herein as "user interface") that allows a user to compose or modify a message; a user interface for inputting data representing a secret”); transmitting, by the one or more servers, the generated business-side version of the verification code to the first agent device for authenticating that the first telephone call originates from the first business entity by enabling a comparison verifying that the customer-side version of the verification code and the business-side version of the verification code are equal ([0069], “The authentication system authenticates not only the user 26 but also the service provider 20 before allowing access to the secured data in the data container 10. While the user ID 28 and the service provider ID 22 become known to the authentication system during the authentication process, they are retained in the authentication system for a limited length of time. After authentication of the service provider and the user, the user ID 28 and the service provider ID 22 are combined to generate the unique data container identifier 14 that identifies the location of the data container 10”).
Shablygin does not explicitly disclose generating, by the verification module, a business-side version of the verification code for use in association with the first authentication attempt; generating, by the customer application on the first customer device, the customer-side version of the verification code for use in association with the first authentication attempt; transmitting, by the one or more servers, the generated business-side version of the verification code to the first agent device for authenticating that the first telephone call originates from the first business entity by enabling a comparison verifying that the customer-side version of the verification code and the business-side version of the verification code are equal.
Disraeli discloses generating, by the verification module, a business-side version of the verification code for use in association with the first authentication attempt (Fig. 4:450, [0047], “Referring again to FIG. 6, after the verification code has been sent to the service user's mobile device, the service user then relays the verification code back to the service provider representative during the ongoing service call, at block 625. To compare the transmitted verification code and the relayed verification code, the service provider enters the code into the system, at block 635”); generating, by the customer application on the first customer device, the customer-side version of the verification code for use in association with the first authentication attempt ([0046], “If the account information is valid, the system transmits a verification code to the service user's mobile device for the second stage of verification, at block 620. The transmitted verification code is not disclosed to the service provider representative and is sent directly to the service user by the system”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shablygin with Disraeli to provide a method to authenticate the merchant or business vendor calls received with whom the customer does business with. The advantage of doing so is to avoid spams and verify calls from trusted entities the customer does business with such as banks retails etc.
In re claims 2 and 15, the combination discloses the method of claim 1 and the system of claim 14, wherein Shablygin discloses wherein the customer application comprises a software token ([0052], “An application or service provider also has a token that is unique and registered with the Authentication System”. [0147], “If the service provider uses a hosting service as its service provider agent 220, then this information can be provided as, for example, a software token to the hosting service. Any necessary software is then installed at the service provider agent 220 for enabling this kind of third-party identification/authentication”), and the customer device comprises a smart phone ([0242], “If the token is an application that runs on the customer's smart phone or personal data assistant, the token application is downloaded to the device by the customer”).
In re claims 3 and 16, the combination discloses the method of claim 2 and the system of claim 15, wherein Shablygin discloses wherein the customer-side version of the verification code comprises a one-time password generated by the software token (Fig. 20, [0288], “As seen in the example of FIG. 20, the request for the passcode can include a user entry mechanism where the token owner can type the passcode. While in this example the passcode is entered via a user interface, other passcode entry methods can be used. For example, the passcode can be entered on a mobile device containing the token. In such examples, the request for the passcode is forwarded to the mobile device. The mobile device displays the message to the human user; e.g., "Token Manager wants to activate your token. Please enter your passcode." The human owner enters the passcode on the mobile device's keyboard”).
In re claims 4 and 17, the combination discloses the method of claim 2 and the system of claim 16, wherein Shablygin discloses wherein the software token of the customer application and the verification module on the one or more servers associated with the business entity each comprises a shared secret key that is used by the software token of the customer application and the verification module to generate the customer-side version of the verification code and the business-side version of the verification code, respectively ([0075], “the token generates a unique file encryption key which the secure data storage application uses to encrypt the file. The file encryption key is encrypted with the user encryption key in the token and stored (in the encrypted form) with the file”. [0123], “Sixth, in embodiments, data containers are ciphered (e.g., encrypted) by secret keys, which become known as a result of user authentication. In addition, data containers may be ciphered (e.g., encrypted) by the service provider secret keys”).
In re claim 5, the combination discloses the method of claim 4, wherein Shablygin discloses wherein the customer application is further configured to: generate a user interface on the customer device that displays a selectable portion that instructs the customer to select the selectable portion when the customer wants to generate the customer-side version of the verification code for authenticating a given telephone call (Fig. 8C, [0141, “The token 224B has a user interface including a screen or display 229 and input buttons 231. The token 224B also includes a wireless communications interface (illustrated by wireless communications 233), such as an Infrared Data Association interface, contactless NFC interface, or Bluetooth interface”. [0127], “For applications of a token requiring high security, the token--or the token in combination with an input/output element--may include the following components: a keypad (alphanumeric), interactive display, or other type of data entry mechanism (collectively referred to herein as "user interface") that allows a user to compose or modify a message; a user interface for inputting data representing a secret (it should be noted that the user interface for generating or modifying a message may, but does not have to, be the same as the user interface for the entry of the data representing a secret); a display for showing the message and/or secret to the user”).
In re claim 6, the combination discloses the method of claim 5, wherein Shablygin discloses wherein the triggering event comprises receiving input indicating selection of the selectable portion (Fig. 16, [0243], “The on-line retailer then adds an icon or other selectable link on its website”. [0279], “During the authentication, the authentication service 320 requests that the token owner 325 enter his previously-assigned passcode. The token owner 325 enters his passcode and the passcode is transmitted to the authentication service 320” (triggering event of activation)).
In re claim 18, the combination discloses the system of claim 17, wherein Shablygin discloses wherein the customer application is further configured to: generate a user interface on the customer device that displays a selectable portion that instructs the customer to select the selectable portion when the customer wants to generate the customer-side version of the verification code for authenticating a given telephone call (Fig. 8C, [0141, “The token 224B has a user interface including a screen or display 229 and input buttons 231. The token 224B also includes a wireless communications interface (illustrated by wireless communications 233), such as an Infrared Data Association interface, contactless NFC interface, or Bluetooth interface”. [0127], “For applications of a token requiring high security, the token--or the token in combination with an input/output element--may include the following components: a keypad (alphanumeric), interactive display, or other type of data entry mechanism (collectively referred to herein as "user interface") that allows a user to compose or modify a message; a user interface for inputting data representing a secret (it should be noted that the user interface for generating or modifying a message may, but does not have to, be the same as the user interface for the entry of the data representing a secret); a display for showing the message and/or secret to the user”); wherein the triggering event comprises receiving input indicating selection of the selectable portion (Fig. 16, [0243], “The on-line retailer then adds an icon or other selectable link on its website”. [0279], “During the authentication, the authentication service 320 requests that the token owner 325 enter his previously-assigned passcode. The token owner 325 enters his passcode and the passcode is transmitted to the authentication service 320” (triggering event of activation)).
In re claims 7 and 19, the combination discloses the method of claim 4 and the system of claim 17, wherein Shablygin discloses wherein the triggering event comprises an expiration of a recurring countdown such that the verification code is generated periodically and usable until a current one of the recurring countdown expires ([0314], “The one-time code can be a string of numbers and/or characters used to identify the ticket. The recovery agent at location A communicates the one-time code to the token owner at a second location separate from the first location (e.g., Location B). This communication can be in various forms including by telephone, text message, e-mail, etc. For additional security the ticket and its identifier may have a limited time window (start and finish time) during which it can be used”. [0315], “By passing a one-time code between the holder of the recovery key (e.g., the recovery agent at location A) and the user attempting to generate a new token (e.g., the token owner at location B), the sensitive information of the user ID and the data encryption key/algorithm identifier does not have to be transferred outside of the tokens and the authentication service”).
In re claim 8, the combination discloses the method of claim 4, wherein Shablygin discloses wherein the triggering event comprises an activation of the customer application (Fig. 16, [0279], “The activation process begins with a token owner 325 in possession of an inactive token (e.g., token 326). The token owner 325 submits a request to a token management service 324 to activate the token 326 (arrow 328). Upon receiving the request, the token management service 324 sends a request to an authentication service 320 to authenticate the token (arrow 330) with two factors--token authentication and passcode authentication. The authentication service 320 performs an authentication process to authenticate the token (arrow 332). During the authentication, the authentication service 320 requests that the token owner 325 enter his previously-assigned passcode. The token owner 325 enters his passcode and the passcode is transmitted to the authentication service 320”).
In re claim 9, the combination discloses the method of claim 4, wherein Shablygin discloses wherein the data transmitted from the customer application on the first customer device that notifies of the triggering event occurring further includes a customer identifier for the first customer (Fig. 32, [0386], “Each entry includes a public user ID 3308, a membership type 3310, file rights 3312, and may include an encrypted group key, the group key being used to encrypt file encryption keys. key 3316”. [0383], “As described above, generally, a user device accessing the secure distributed data storage environment generates a user interface representing a hierarchy of directories and files defined by data containers. A user selects a file ID from the user interface by selecting a graphical representation (e.g. an icon, a label, or both) of the file. As described above with respect to FIG. 2A-B, the service provider agent combines the file ID with the service provider ID using a one-way function to arrive at the data container identifier data control identifier. The data container identifier data control identifier locates a file container 3210 in distributed data storage 3208. The service provider agent 3206 compares the PUID of the user of the user device to the access control list 3212 of the file container 3210”).
In re claim 10, the combination discloses the method of claim 9, wherein Shablygin discloses wherein the authentication process further comprises the step of: identifying, based on the customer identifier, the first agent device from among a plurality of such agent devices as being the particular agent device that is conducting the first telephone call with the first customer. [0213], “The public key for decryption is known to the locations participating in the procedure. The service provider agent 220 also uses a bit-shifted version of the service provider ID. Specifically the service provider agent 220 bit-shifts the service provider ID by the number of bits In the User ID”. [0244], “This data container is identified and retrieved using a data container identifier, which is derived from the service provider ID assigned to the on-line retailer and the unique user ID stored in the token 27 issued to the customer”).
In re claim 11, the combination discloses the method of claim 10, wherein Disraeli discloses wherein the authentication process further comprises the step of: generating, in response to identifying the first agent device as the particular agent device conducting the first telephone call, a user interface on the first agent device displaying the business-side version of the verification code (Fig. 6:625, [0047], “To compare the transmitted verification code and the relayed verification code, the service provider enters the code into the system, at block 635. Consequently, any possibility of social engineering is eliminated since the system, not the service provider representative, compares the codes”).
In re claim 12, the combination discloses the method of claim 9, wherein Disraeli discloses wherein the authentication process further comprises the steps of: providing, in response to identifying the first agent device as the particular agent device conducting the first telephone call, audio data for generating automated speech communicating the business-side version of the verification code; and generating the automated speech during the first telephone call so to communicate the business-side version of the verification code to the first customer ([0046], “The transmitted verification code is not disclosed to the service provider representative and is sent directly to the service user by the system. The verification code may be transmitted as a SMS or voice message”).
In re claim 13, the combination discloses the method of claim 4, wherein Shablygin discloses wherein the customer application is further configured to place an order for a product or service offered by the business entity ([0239], “A typical service provider/user interaction would be between a vendor (e.g., on-line bookstore) and a user who has an account with the vendor. This application relieves the user of the need to carry multiple loyalty cards for multiple vendors”. [0244], “Over time, the on-line retailer can supplement this information with historical information such as the customer's purchase history, trends and preferences, loyalty status, etc. The on-line retailer provides this information to the third-party authenticator as a data container for storage in the dispersed data storage system 216”).
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SWATI JAIN whose telephone number is (571)270-0699. The examiner can normally be reached Mon - Fri (830 am - 530 pm).
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, Pan Yuwen can be reached on 5712727855. 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.
/SWATI JAIN/Examiner, Art Unit 2649 /YUWEN PAN/Supervisory Patent Examiner, Art Unit 2649
Prosecution Insights