Jump to content

Patent Application 17344655 - SYSTEMS AND METHODS FOR PROVIDING DIGITAL - Rejection

From WikiPatents

Patent Application 17344655 - SYSTEMS AND METHODS FOR PROVIDING DIGITAL

Title: SYSTEMS AND METHODS FOR PROVIDING DIGITAL AUTHENTICATION AS A SERVICE

Application Information

  • Invention Title: SYSTEMS AND METHODS FOR PROVIDING DIGITAL AUTHENTICATION AS A SERVICE
  • Application Number: 17344655
  • Submission Date: 2025-05-23T00:00:00.000Z
  • Effective Filing Date: 2021-06-10T00:00:00.000Z
  • Filing Date: 2021-06-10T00:00:00.000Z
  • National Class: 726
  • National Sub-Class: 004000
  • Examiner Employee Number: 87325
  • Art Unit: 2437
  • Tech Center: 2400

Rejection Summary

  • 102 Rejections: 0
  • 103 Rejections: 4

Cited Patents

No patents were cited in this rejection.

Office Action Text


    
DETAILED ACTION
This action is responsive to RCE filed on 04/22/2025. Claims 1, 6 and 11 are independents. Claims 1, 6 and 11 are amended. Claims 1-12 are currently pending.

Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection.  Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114.  Applicant's submission filed on 04/22/2025 has been entered.
 

Response To Argument
Applicant’s arguments with respect to the amended new feature " enrollment as a service computer program provides enrollment as a service for the plurality of entities" in the Remark filed on 03/21/2025 has been fully considered and they are not persuasive. However, a new rejection is made in view of newly found priory art Kumar et al. (IS 20210160231 A1), hereinafter Kumar.



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
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.

Claims 1-2, 5-7 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Gassner et al. (US 20180218121 A1), hereinafter Gassner, in view of Pattar et al. (US 20190334921 A1), hereinafter Pattar, further in view of Pakin et al. (JP 2017162129 A), hereinafter Pakin, additionally, in view of Kumar et al. (IS 20210160231 A1), hereinafter Kumar. 

Regarding claim 1, Gassner teaches a method for providing enrollment as a service, comprising:
	receiving, at an enrollment as a service computer program and from an entity website for one of a plurality of entities, comprising a customer identifier and customer information for a validated customer, wherein the enrollment as a service computer program is in communication with a plurality of entities (FIG. 4, identity management module 1119; FIG. 3, web application 1209; para. 0061, The verification process may be integrated directly into the registration process. Once an account is created, the HCP is offered the opportunity to verify himself. The system may capture the country in which the HCP is practicing, and support two options for HCP verification: verify as a licensed HCP via HCP-entered address and license information; or verify as a licensed or non-licensed HCP via a call center; para. 0055, ... a verification check may be performed against the HCP data management system 130 ... ; and para. 0030, ... The system 130 may store customer master data, which may be many types of data used by the enterprise, e.g., accounts, addresses and reference data ... ; para. 0101, an access token that can be sent to the system's API, an ID token that contains identity information about the user which is digitally signed by the system using JSON Web Signature ("JWS") and adheres to the OpenID Connect token standard, and the remaining lifetime for the access token; modern computer program is always designed to be multi-threading, handling multiple entities at the same time; modern computer program is always designed to be multi-threading, handling multiple entities at the same time).
	receiving, at the enrollment as a service computer program and from the entity website, an authentication as a service request (para. 0075, Functioning as a trusted Identity Provider (IdP), the identity management system 110 may authenticate HCPs and provide identity assertions using widely used protocols, e.g., Security Assertion Markup Language ("SAML") v2.0 and OpenID Connect 1.0. An identity assertion is in the form of a token and is used by a service provider (including third party service providers) to grant access to various services; para. 0078, At 601, a user (HCP) visits a service provider web portal and selects to log in using the identity management system 110 as the identity provider);
	presenting, by the enrollment as a service computer program, a login page at the entity website (para. 0079, At 603, the service provider web server 140 may redirect the HCP's (user's) browser to a URL owned by the identity management system 110; para. 0076, The process begins when the service provider website ( e.g., customer.com) redirects the HCP browser to a login page URL hosted by the identity management system 110. URL query parameters indicate the type of access token returned after authentication. The login page captures the username and password, and enforces authentication protections, such as limiting the number of failed password attempts. Once the HCP is authenticated, the identity management system 110 may begin authentication token flow following a token exchange protocol, e.g., OpenID Connect 1.0 Provider or SAML 2.0 Identity Provider);
	receiving, by the enrollment as a service computer program and from the login page, the username and password (para. 0080, the identity management system 110 may capture credentials via the web browser; para. 0076, The process begins when the service provider website ( e.g., customer.com) redirects the HCP browser to a login page URL hosted by the identity management system 110. URL query parameters indicate the type of access token returned after authentication. The login page captures the username and password, and enforces authentication protections, such as limiting the number of failed password attempts. Once the HCP is authenticated, the identity management system 110 may begin authentication token flow following a token exchange protocol, e.g., OpenID Connect 1.0 Provider or SAML 2.0 Identity Provider);
	authenticating, by the enrollment as a service computer program, the username and password (para. 0081, The identity management system 110 may authenticate the HCP (user) with data in the identity data storage device 112; para. 0076, The process begins when the service provider website ( e.g., customer.com) redirects the HCP browser to a login page URL hosted by the identity management system 110. URL query parameters indicate the type of access token returned after authentication. The login page captures the username and password, and enforces authentication protections, such as limiting the number of failed password attempts. Once the HCP is authenticated, the identity management system 110 may begin authentication token flow following a token exchange protocol, e.g., OpenID Connect 1.0 Provider or SAML 2.0 Identity Provider); and
	returning, by the enrollment as a service computer program, an authentication status to the entity website (para. 0082, the identity management system 110 may use HTTP POST (HTTP-POST Binding) to return a SAML response with a digitally signed assertion to the browser).
Gassner does not explicitly teach wherein the entity website validates an identity of the customer; and enrolling, by the enrollment as a service computer program, the username and password for the customer. However, in an analogous art, Pattar teaches wherein the entity website validates an identity of the customer (para. 0034, when a user is trying to access a “BankAccount” resource, the banking system has to prompt the user for the username and password; para. 0098, the credential for the factor is validated, the validation includes comparing the credential provided by the user to an expected response of the factor (e.g., a user name or password saved in the user profile). When the credential provided by the user matches the expected response of the factor, the credential is valid); and enrolling, by the enrollment as a service computer program, the username and password for the customer (para. 0034, if the user is not enrolled or registered, then the user will be prompted to enroll or register for an account, which may include setting up a username and password for the account; para 0094, the inline enrollment process allows for enrollment or registration in multiple levels of authentication and any associated factor).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Gassner and Pattar. One of ordinary skill in the art would have been motivated to combine Gassner and Pattar because it would overcome the limitations of single level authentication by developing multi-level authentication as a technique that authenticates data at multiple levels (Pattar para. 0004).
The combination of Gassner and Pattar does not explicitly teach receiving, at an enrollment, a Security Assertion Markup Language (SAML) assertion or a JSON Web Token (JWT); creating, by the enrollment as a service computer program, a user profile for the customer identifier and the customer information; and creating, by the enrollment as a service computer program, a username and password for the customer identifier. However, in an analogous art, Pakin teaches receiving, at an enrollment, a Security Assertion Markup Language (SAML) assertion or a JSON Web Token (JWT); creating, by the enrollment as a service computer program, a user profile for the customer identifier and the customer information; and creating, by the enrollment as a service computer program, a username and password for the customer identifier (p. 7/8 (ST1-6), where an account registration request is received with an authentication assertion that can take the form of an SAML assertion; p.8/18 (ST1-10), the user account is generated).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Gassner of using a SAML assertion, Pattar of using username and password and Pakin of generating username and password. One of ordinary skill in the art would have been motivated to combine Gassner, Pattar and Pakin because it the username and password used to login into system can be maintained using same standard.
The combination of Gassner, Pattar, Pakin and Kumar does not explicitly teach enrollment as a service computer program provides enrollment as a service for the plurality of entities. However, in an analogous art, Kumar teaches enrollment as a service computer program provides enrollment as a service for the plurality of entities (para. 0080, using SAML provides identity federation services; para. 0207, securely support multiple tenants; para. 0271 and 0272, using IDCS [enrollment service] to enroll/register users, applications and tenants).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gassner, Pattar, Pakin and Kumar by incorporating Kumer’s teaching of enrollment as a service for the plurality of entities because this provide the ability to deliver a scalable IDCS capability immediately across the enterprise can provide benefits in flexibility, cost, and control.

	Regarding claim 2, the combination of Gassner, Pattar, Pakin and Kumar teaches all of the limitations of claim 1 as described above. Gassner further teaches wherein the customer information comprises a customer name, a customer address, and/or a customer email (para. 0052, The profile data may include the HCP's first name, last name, email, user name, and password).

Regarding claim 5, the combination of Gassner, Pattar, Pakin and Kumar teaches all of the limitations of claim 1 as described above. Gassner further teaches further comprising:
providing, by the enrollment as a service computer program, the user profile to the entity website in response to authenticating the username and password (para. 0023, The identity management server 111 may enable display of an identity management button on a webpage of the service provider website, and enable display of a user interface on a user computing device to allow an HCP user to register for the identity management service and provide profile information and login information. The identity management server 111 may communicate with the service provider web server 140 and the HCP data management system 130 to verity the HCP user and authenticate the HCP user to use the services provided by the service provider website).

Regarding claim 6, Gassner teaches a method for using enrollment as a service, comprising:
	receiving, at an entity website for one of a plurality of entities, customer information for a customer (para. 0096, the following parameters: client ID obtained during client registration, response type set to 'code', scope of 'openid email', and redirect URL endpoint hosted by the relying party that will receive the response from the system 110 specified during registration; para. 0097, the identity management system 110 may capture HCP credentials via the web browser);
	invoking, by the entity website, enrollment as a service by providing a Security Assertion Markup Language (SAML) assertion or a JSON Web Token (JWT) comprising a customer identifier and customer information for the customer to an enrollment and authentication server, wherein the enrollment and authentication server is configured to create a user profile having a username and password for the customer, authenticate the customer, and enroll the username and password for the customer, wherein the enrollment and authentication server is configured to provides enrollment as a service for the plurality of entities (SAML assertion; para. 0101, an access token that can be sent to the system's API, an ID token that contains identity information about the user which is digitally signed by the system using JSON Web Signature ("JWS") and adheres to the OpenID Connect token standard, and the remaining lifetime for the access token; para. 0052, profile data may be captured and stored as a part of the HCP's identity during registration at 522. The profile data may include the HCP's first name, last name, email, user name, and password; modern computer program is always designed to be multi-threading, handling multiple entities at the same time);
	receiving, from the enrollment and authentication server, an authentication status for the customer (para. 0082, the identity management system 110 may use HTTP POST (HTTP-POST Binding) to return a SAML response with a digitally signed assertion to the browser); and
	retrieving, by the entity website and from the enrollment and authentication server, the user profile for the customer (para. 0048, An ID/Access Token Endpoint is an API endpoint used by the service provider application 1401 to ultimately retrieve ID and access tokens in the form of JSON Web Token (JWT); para. HCP Profile attributes, License, National/Regional Identifier, and address data are available from an authoritative source).
Gassner does not explicitly teach validating the customer information; and enroll the username and password for the customer. However, in an analogous art, Pattar teaches validating the customer information (para. 0034, when a user is trying to access a "BankAccount" resource, the banking system has to prompt the user for the username and password: para. 0098. the credential for the factor is validated. the validation includes comparing the credential provided by the user to an expected response of the factor (e.g., a user name or password saved in the user profile). When the credential provided by the user matches the expected response of the factor. the credential is valid); and enroll the username and password for the customer (para. 0034. if the user is not enrolled or registered, then the user will be prompted to enroll or register for an account. which may include setting up a username and password for the account; para. 0094. the inline enrollment process allows for enrollment or registration in multiple levels of authentication and any associated factor).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Gassner and Pattar. One of ordinary skill in the art would have been motivated to combine Gassner and Pattar because it would overcome the limitations of single level authentication by developing multi-level authentication as a technique that authenticates data at multiple levels (Pattar para. 0004).
The combination of Gassner and Pattar does not explicitly teach providing a Security Assertion Markup Language (SAML) assertion or a JSON Web Token (JWT); and creating a user profile having a username and password for the customer. However, in an analogous art, Pakin teaches providing a Security Assertion Markup Language (SAML) assertion or a JSON Web Token (JWT); and creating a user profile having a username and password for the customer (p. 7/8 (ST1-6), where an account registration request is received with an authentication assertion that can take the form of an SAML assertion; p.8/18 (ST1 -10), the user account is generated).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Gassner of using a SAML assertion), Pattar of using username and password and Pakin of generating usemame and password. One of ordinary skill in the art would have been motivated to combine Gassner, Pattar and Pakin because the username and password used to login into system can be maintained using same standard.
The combination of Gassner, Pattar and Pakin does not explicitly teach enrollment as a service computer program provides enrollment as a service for the plurality of entities. However, in an analogous art, Kumar teaches wherein the enrollment and authentication server is configured to provides enrollment as a service for the plurality of entities (para. 0080, using SAML provides identity federation services; para. 0207, securely support multiple tenants; para. 0271 and 0272, using IDCS [enrollment service] to enroll/register users, applications and tenants; para. 0164, OIDC also has the authentication functionality).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gassner, Pattar, Pakin and Kumar by incorporating Kumer’s teaching of enrollment as a service for the plurality of entities because this provide the ability to deliver a scalable IDCS capability immediately across the enterprise can provide benefits in flexibility, cost, and control.

Regarding claim 7, the combination of Gassner, Pattar, Pakin and Kumar teaches all of the limitations of claim 6 as described above. Gassner further teaches wherein the customer information comprises a customer name, a customer address, and/or a customer email (para. 0024 and 0052, first name, last name and email; name; para. 0030 and 0056 addresses; para. 0025 email address).

	Regarding claim 9, the combination of Gassner, Pattar, Pakin and Kumar teaches all of the limitations of claim 6 as described above. Gassner further teaches further comprising: receiving, at the entity website and from the enrollment and authentication server, a login page; and presenting, by the enrollment and authentication server, the login page on the entity website (para. 0076-0077).

Claims 3-4, 8 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Gassner, Pattar and Pakin as applied to claims above, and further in view of Ozzie et al. (US 20100100725 A1), hereinafter, Ozzie.

Regarding claims 3 and 8, the combination of Gassner, Pattar, Pakin and Kumar teaches all of the limitations of claims 1 and 6 respectively as described above.
The combination of Gassner, Pattar, Pakin and Kumar does not explicitly teach wherein the validated customer has been validated by the entity website to be a person. However, in analogous art, Ozzie teaches wherein the validated customer has been validated by the entity website to be a person (para. 0022, verify that the user is human and not an automated Internet bot).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Gassner, Pattar, Pakin, Kumar and Ozzie. One of ordinary skill in the art would have been motivated to combine Gassner, Pattar, Pakin, Kumar and Ozzie because determining the effective permissions is advantageous for customers because the website may wish to verify that the user is human and not an automated Internet bot designed to spam website message boards (e.g., post advertisements on the message boards (Ozzie para. 0022).

Regarding claims 4 and 10, the combination of Gassner, Pattar, Pakin and Kumar teaches all of the limitations of claims 1 and 9 respectively as described above.
The combination of Gassner, Pattar, Pakin and Kumar does not explicitly teach wherein the login page is presented in an inline frame. However, in analogous art, Ozzie teaches wherein the login page is presented in an inline frame (para. 0038, a user interface (UI) is provided in the Iframe in the webpage, for user authentication on the host server, the UI comprising a challenge-response authentication test message, and authentication status information. For example, because the user authentication service can control content in a cross-domain Iframe, the service may initiate a UI in the Iframe on a webpage that a user is accessing. In this example, the UI can display a CAPTCHA image, along with a message informing the user what they can do to complete authentication).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Gassner, Pattar, Pakin, Kumar and Ozzie. One of ordinary skill in the art would have been motivated to combine Gassner, Pattar, Pakin, Kumar and Ozzie because the user authentication service can provide notifications, messages, and codes to a website user using the Iframe and the host website needing to do little else (Ozzie para. 0035).

Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Gassner, in view of Pattar and further in view Kumar.

	Regarding claim 11, Gassner teaches a method for providing authentication as a service, comprising:
	receiving, at an enrollment as a service computer program and from an entity website for an entity of a plurality of entities in communication with the
enrollment as a service computer program invocation of authentication as a
service the invocation comprising a Security Assertion Markup Language (SAML) assertion or a JSON Web Token (JWT) comprising a customer identifier and customer information for the customer (para. 0075, Functioning as a trusted Identity Provider (IdP), the identity management system 110 may authenticate HCPs and provide identity assertions using widely used protocols, e.g., Security Assertion Markup Language ("SAML") v2.0 and OpenID Connect 1.0. An identity assertion is in the form of a token and is used by a service provider (including third party service providers) to grant access to various services; para. 0078, At 601, a user (HCP) visits a service provider web portal and selects to log in using the identity management system 110 as the identity provider);
	presenting, by the enrollment as a service computer program, a login page at the entity website (para. 0079, At 603, the service provider web server 140 may redirect the HCP's (user's) browser to a URL owned by the identity management system 110; para. 0076, The process begins when the service provider website ( e.g., customer.com) redirects the HCP browser to a login page URL hosted by the identity management system 110. URL query parameters indicate the type of access token returned after authentication. The login page captures the username and password, and enforces authentication protections, such as limiting the number of failed password attempts. Once the HCP is authenticated, the identity management system 110 may begin authentication token flow following a token exchange protocol, e.g., OpenID Connect 1.0 Provider or SAML 2.0 Identity Provider);
	receiving, by the enrollment as a service computer program and from the login page, a username and a password for a customer (para. 0080, the identity management system 110 may capture credentials via the web browser; para. 0076, The process begins when the service provider website ( e.g., customer.com) redirects the HCP browser to a login page URL hosted by the identity management system 110. URL query parameters indicate the type of access token returned after authentication. The login page captures the username and password, and enforces authentication protections, such as limiting the number of failed password attempts. Once the HCP is authenticated, the identity management system 110 may begin authentication token flow following a token exchange protocol, e.g., OpenID Connect 1.0 Provider or SAML 2.0 Identity Provider);
	authenticating, by the enrollment as a service computer program, the username and password (para. 0081, The identity management system 110 may authenticate the HCP (user) with data in the identity data storage device 112; para. 0076, The process begins when the service provider website ( e.g., customer.com) redirects the HCP browser to a login page URL hosted by the identity management system 110. URL query parameters indicate the type of access token returned after authentication. The login page captures the username and password, and enforces authentication protections, such as limiting the number of failed password attempts. Once the HCP is authenticated, the identity management system 110 may begin authentication token flow following a token exchange protocol, e.g., OpenID Connect 1.0 Provider or SAML 2.0 Identity Provider); and
	returning, by the enrollment as a service computer program, an authentication status to the entity website (para. 0082, the identity management system 110 may use HTTP POST (HTTP-POST Binding) to return a SAML response with a digitally signed assertion to the browser).
Gassner does not explicitly teach enrolling, by the enrollment as a service computer program, the username and password for the customer. However, in an analogous art, Pattar teaches enrolling, by the enrollment as a service computer program, the username and password for the customer (para. 0034, if the user is not enrolled or registered, then the user will be prompted to enroll or register for an account, which may include setting up a username and password for the account; para 0094, the inline enrollment process allows for enrollment or registration in multiple levels of authentication and any associated factor).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Gassner and Pattar. One of ordinary skill in the art would have been motivated to combine Gassner and Pattar because it would overcome the limitations of single level authentication by developing multi-level authentication as a technique that authenticates data at multiple levels (Pattar para. 0004).
The combination of Gassner and Pattar and Kumar does not explicitly teach wherein the enrollment as a service computer program provides enrollment as a service for the plurality of entities. However, in an analogous art, Kumar teaches wherein the enrollment as a service computer program provides enrollment as a service for the plurality of entities (para. 0080, using SAML provides identity federation services; para. 0207, securely support multiple tenants; para. 0271 and 0272, using IDCS [enrollment service] to enroll/register users, applications and tenants).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gassner, Pattar and Kumar by incorporating Kumer’s teaching of enrollment as a service for the plurality of entities because this provide the ability to deliver a scalable IDCS capability immediately across the enterprise can provide benefits in flexibility, cost, and control.

Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Gassner, Pattar and Kumar, as shown above, further in view of Ozzie.

Regarding claim 12, the combination of Gassner, Pattar and Kumar teaches all of the limitations of claim 11 as described above.
The combination of Gassner, Pattar and Kumar does not explicitly teach wherein the login page is presented in an inline frame. However, in analogous art, Ozzie teaches wherein the login page is presented in an inline frame (para. 0038, a user interface (UI) is provided in the Iframe in the webpage, for user authentication on the host server, the UI comprising a challenge-response authentication test message, and authentication status information. For example, because the user authentication service can control content in a cross-domain Iframe, the service may initiate a UI in the Iframe on a webpage that a user is accessing. In this example, the UI can display a CAPTCHA image, along with a message informing the user what they can do to complete authentication).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Gassner, Pattar, Kumar and Ozzie. One of ordinary skill in the art would have been motivated to combine Gassner, Pattar, Kumar and Ozzie because the user authentication service can provide notifications, messages, and codes to a website user using the Iframe and the host website needing to do little else (Ozzie para. 0035).

Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHU CHUN GAO whose telephone number is (571)270-5999. The examiner can normally be reached on Monday -Thursday 6:00-4:30.
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, ALEXANDER LAGOR can be reached on 571-270-5143. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.

/S. C. G./Examiner, Art Unit 2437 


/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437


Retrieved from "https://wikipatents.org/index.php?title=Patent_Application_17344655_-_SYSTEMS_AND_METHODS_FOR_PROVIDING_DIGITAL_-_Rejection&oldid=615941"
Cookies help us deliver our services. By using our services, you agree to our use of cookies.