DETAILED ACTION
This Office Action is in response to the application 19/206,855 filed on 05/13/2025.
Claims 1-20 have been examined and are pending.
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 . This Action is made Non-FINAL.
Priority
This application is a continuation of U.S. Application No. 18/109,134, filed February 13, 2023, now U.S. Patent No. 12299106, which is a continuation of U.S. Application No. 16/784,225, filed February 6, 2020, now U.S. Patent No. 11,580,206, which claims the benefit under 35 U.S.C. § 119(e) of United States Provisional Application Number 62/912,530, filed October 8, 2019.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 05/13/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1, 8, and 15 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1, 8 and 15 of the U.S. Patent No 12299106 in view of Doloff (“Doloff,” US 10505925, filed Sept. 6, 2017) and further in view of DePue et al. (“DePue,” US 11050691, filed July 12, 2019).
Instant Application 19206855
U.S. Patent No.: 12,299,106
Claim 1.
A computer-implemented method, implemented by a computing system, the method comprising:
receiving, from a client device associated with a user or from a service, a job associated with one or more data sources;
determining first permissions corresponding to the client device or the service and second permissions corresponding to a second client device or a second service, wherein:
each of the first permissions or the second permissions corresponds to an operation on a data source;
generating a token associated with the job, the token encoding the first permissions or the second permissions;
receiving a request from the client device or the service for the token;
determining whether the client device or the service is authorized to execute the job based on the first permissions;
in response to determining that the client device or the service is authorized to execute the job, granting the token to the client device or the service to enable the client device or the service to execute the job;
in response to determining that authorization for the client device or the service to execute the job has expired, revoking access to the token; and
in response to determining that the second device or the second service is authorized to execute the job, linking the token to the second device or the second service to enable the second client device or the second service to execute the job or generating a second token and granting the second token to the second device.
Claim 9.
Claim 9 is directed to a system associated with the system of claim 1. Claim 9 is similar in scope to claim 1 and is therefore rejected on the ground of non-statutory type double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,299,106.
Claim 17.
Claim 17 is directed to a non-transitory computer readable medium associated with the system of claim 1. Claim 9 is similar in scope to claim 1 and is therefore rejected on the ground of non-statutory type double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,299,106.
Claim 1.
A computer-implemented method, implemented by a computing system, the method comprising:
receiving, from a client device associated with a user or from a service, a job associated with a project, wherein the project is associated with one or more data sources;
determining first permissions corresponding to the client device or the service and second permissions corresponding to a second client device or a second service, wherein:
each of the first permissions comprises an operation on a data source;
generating a token associated with the job, the token encoding the first permissions or the second permissions;
receiving a request from the client device or the service for the token;
determining whether the client device or the service is authorized to execute the job based on the first permissions;
in response to determining that the client device or the service is authorized to execute the job, granting the token to the client device or the service to enable the client device or the service to execute the job; and
in response to executing the job, selectively transmitting a result of the execution of the job to a different client device or a different service based on whether the different client device or the different service is authorized to access the result, based on the second permissions.
Claim 9.
Claim 9 is directed to a system associated with the method of claim 1. Claim 9 is similar in scope to claim 1.
Claim 17.
Claim 17 is directed to a non-transitory computer readable medium associated with the method of claim 1. Claim 17 is similar in scope to claim 1.
U.S. Patent No.: 12,299,106 does not explicitly disclose:
in response to determining that authorization for the client device or the service to execute the job has expired, revoking access to the token; and
in response to determining that the second device or the second service is authorized to execute the job, linking the token to the second device or the second service to enable the second client device or the second service to execute the job or generating a second token and granting the second token to the second device.
However, in an analogous art, DePue et al. discloses a method, comprising the step of: in response to determining that authorization for the client device or the service to execute the job has expired, revoking access to the token (DePue col. 11: 13-21. The messaging client application 104 can revoke or expire any given authentication token 207 when a user instructs the messaging client application 104 to disconnect an associated third party application 105. The messaging client application 104 can revoke or expire any given authentication token 207 when an expiration time is reached and / or when fraud is detected, causing the messaging client application 104 to 20 disconnect an associated third-party application 105.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention was made to combine the teachings of DePue with the method of the U.S. Patent No.: 12,299,106 to include the step of: in response to determining that authorization for the client device or the service to execute the job has expired, revoking access to the token. One would have been motivated to provider users with a means to restrict token validity to a designed period and commensurate with the scope of access. (See DePue col. 11: 13-21.)
Furthermore, in an analogous art, Doloff discloses a method, comprising the step of:
in response to determining that the second device or the second service is authorized to execute the job, linking the token to the second device or the second service to enable the second client device or the second service to execute the job or generating a second token and granting the second token to the second device (Doloff col. 3: 61-67; col. 7: 8-10; col. 8: 8-16. If the user does not have a valid account with the provider, the user account does not enable access to the type of resources specified in the request, or another such reason is preventing the user from obtaining access to such resources, a communication can be sent to the user to enable the user to create or modify an account, or change the resources specified in the request, among other such options. In the initial portion 200 of FIG. 2A, an authentication request (or other request requiring authentication) is transmitted by a client device 202 and received to an external authentication service 204. If the request is authenticated by the internal authentication service, a response can be sent to the client device 202 indicating that access has been granted, which can enable the client device to communicate directly (over the public network, etc.) with the service provider environment 206 as illustrated in the flow portion 240 of FIG. 2C. In this example, an authentication token 242 may be provided to the client device that can be submitted with future requests or communications to the service provider environment, which can indicate that the requests correspond to an authenticated user or device. This can be the same token 222 that was issued by the external authentication service, although potentially updated, or a new token issued by the internal authentication service 208, among other such options.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention was made to combine the teachings of Doloff, DePue with the method of the U.S. Patent No.: 12,299,106 to include the step of: in response to determining that the second device or the second service is authorized to execute the job, linking the token to the second device or the second service to enable the second client device or the second service to execute the job or generating a second token and granting the second token to the second device . One would have been motivated to provider users with a means to provide an access token accordance with a uder or user device’s scope of authentication and permission for accessing a service. (See Doloff col. 8: 8-16.)
Claims 2-7, 9-14 and 16 -20 are rejected as being dependent on claims 1 ,9 and 17, respectively.
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 discloses as set forth in section 102 of this title, 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-3, 8-10, 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Doloff (“Doloff,” US 10505925, filed Sept.6, 2017) in view of DePue et al., (“DePue,” US 11050691, filed June 12, 2019.).
Regarding claim 1, Doloff discloses A computer-implemented method, implemented by a computing system, the method comprising:
receiving, from a client device associated with a user or from a service, a job associated with one or more data sources (Doloff col. 2: 23-29, col. 3: 53-60. Examples of such client devices include personal computers, tablet computers, smart phones, notebook computers, and the like. The resource manager can determine whether there are adequate resources available to suit the user's request, and if so can provision the resources or otherwise grant access to the corresponding portion of those resources for use by the user for an amount specified by the request. This amount can include, for example, capacity to process a single request or perform a single task, a specified period of time, or a recurring/renewable period, among other such values.);
determining first permissions corresponding to the client device or the service and second permissions corresponding to a second client device or a second service, wherein (Doloff col. 3: 46-53, 61-67; col. 5: 31-40. If the user has an account with the appropriate permissions, status, etc., and the provided information and credentials match those stored for the account, then the authentication service provide authentication of the request, such as by issuing a token or ticket that can be passed with requests for that user, device, or session to obtain access to various resources in the provider environment 106. If the user does not have a valid account with the provider, the user account does not enable access to the type of resources specified in the request, or another such reason is preventing the user from obtaining access to such resources, a communication can be sent to the user to enable the user to create or modify an account, or change the resources specified in the request, among other such options. These steps can include a first step to authenticate with the VPN server, in order to obtain a VPN connection. A second step involves a client device, having established a VPN connection, authenticating with an internal service. As mentioned, the authentication for internal services, as may provide websites or other content access, can involve an authentication mechanism that provides tokens that identifies the users associated with requests, where those tokens can only be obtained from a specific service, such as a corporate token granting service.):
each of the first permissions or the second permissions corresponds to an operation on a data source (Doloff col. 4: 1-8; col. 5: 31-40. In the case of a VPN request, the resource manager can allocate and configure a VPN connection such that VPN software 122 executing on the client device 102 can access the resources in the provider environment 106 as if the client were directly connected to those resources inside the provider environment. The token or ticket can be passed with requests on the VPN session in order to indicate authentication and obtain permitted access to the resources. These steps can include a first step to authenticate with the VPN server, in order to obtain a VPN connection. A second step involves a client device, having established a VPN connection, authenticating with an internal service. As mentioned, the authentication for internal services, as may provide websites or other content access, can involve an authentication mechanism that provides tokens that identifies the users associated with requests, where those tokens can only be obtained from a specific service, such as a corporate token granting service.);
generating a token associated with the job, the token encoding the first permissions or the second permissions (Doloff col. 8: 12-16. This can be the same token 222 that was issued by the external authentication service, although potentially updated, or a new token issued by the internal authentication service 208, among other such options.);
receiving a request from the client device or the service for the token (Doloff col. 7: 7-11. In the initial portion 200 of FIG. 2A, an authentication request (or other request requiring authentication) is transmitted by a client device 202 and received to an external authentication service 204.);
determining whether the client device or the service is authorized to execute the job based on the first permissions (Doloff col. 8: 2-8. If the request is authenticated by the internal authentication service, a response can be sent to the client device 202 indicating that access has been granted, which can enable the client device to communicate directly (over the public network, etc.) with the service provider environment 206 as illustrated in the flow portion 240 of FIG. 2C.);
in response to determining that the client device or the service is authorized to execute the job, granting the token to the client device or the service to enable the client device or the service to execute the job (Doloff col. 8: 8-16. In this example, an authentication token 242 may be provided to the client device that can be submitted with future requests or communications to the service provider environment, which can indicate that the requests correspond to an authenticated user or device. This can be the same token 222 that was issued by the external authentication service, although potentially updated, or a new token issued by the internal authentication service 208, among other such options.);
and in response to determining that the second device or the second service is authorized to execute the job, linking the token to the second device or the second service to enable the second client device or the second service to execute the job or generating a second token and granting the second token to the second device (Doloff col. 3: 61-67; col. 7: 8-10; col. 8: 8-16. If the user does not have a valid account with the provider, the user account does not enable access to the type of resources specified in the request, or another such reason is preventing the user from obtaining access to such resources, a communication can be sent to the user to enable the user to create or modify an account, or change the resources specified in the request, among other such options. In the initial portion 200 of FIG. 2A, an authentication request (or other request requiring authentication) is transmitted by a client device 202 and received to an external authentication service 204. If the request is authenticated by the internal authentication service, a response can be sent to the client device 202 indicating that access has been granted, which can enable the client device to communicate directly (over the public network, etc.) with the service provider environment 206 as illustrated in the flow portion 240 of FIG. 2C. In this example, an authentication token 242 may be provided to the client device that can be submitted with future requests or communications to the service provider environment, which can indicate that the requests correspond to an authenticated user or device. This can be the same token 222 that was issued by the external authentication service, although potentially updated, or a new token issued by the internal authentication service 208, among other such options.).
Doloff does not explicitly disclose: in response to determining that authorization for the client device or the service to execute the job has expired, revoking access to the token.
However, in an analogous art, DePue discloses a method, comprising the step of: in response to determining that authorization for the client device or the service to execute the job has expired, revoking access to the token (DePue col. 11: 13-21. The messaging client application 104 can revoke or expire any given authentication token 207 when a user instructs the messaging client application 104 to disconnect an associated third party application 105. The messaging client application 104 can revoke or expire any given authentication token 207 when an expiration time is reached and / or when fraud is detected, causing the messaging client application 104 to 20 disconnect an associated third-party application 105.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention was made to combine the teachings of DePue with Doloff to include the step of: in response to determining that authorization for the client device or the service to execute the job has expired, revoking access to the token. One would have been motivated to provider users with a means to restrict token validity to a designed period and commensurate with the scope of access. (See DePue col. 11: 13-21.)
Regarding claim 2, Doloff and DePue disclose the method of claim 1. DePue further discloses wherein the token encodes one or more permissions or restrictions on child data sources of the data source (DePue col. 9-11. The authentication token may include information from a user account for, or corresponding to, the messaging client application 104. The authentication token may uniquely identify the third-party application 105 and be associated with an expiration time.).
The motivation is the same as that of claim 1 above.
Regarding claim 3, Doloff and DePue disclose the method of claim 1. DePue further discloses wherein the token permits access to the data source and restricts access to the child data sources (DePue col. 9-11; col. 11: 1-5. The authentication token may include information from a user account for, or corresponding to, the messaging client application 104. The authentication token may uniquely identify the third-party application 105 and be associated with an expiration time. Each token may include a list of permissions associated with a given third-party application 105, an identity (e.g., a name) of the third-party application 105, user information provided by the messaging client application 104, an expiration time, and any other suitable information.).
The motivation is the same as that of claim 1 above.
Regarding claim 8, claim 8 is directed to a system corresponding to the method of claim 1. Claim 8 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 9, claim 9 is directed to a system corresponding to the method of claim 2. Claim 9 is similar to claim 2 and is therefore rejected under similar rationale.
Regarding claim 10, claim 10 is directed to a system corresponding to the method of claim 3. Claim 10 is similar to claim 3 and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed to a non-transitory computer readable medium corresponding to the method of claim 1. Claim 15 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 16, claim 16 is directed to a non-transitory computer readable medium corresponding to the method of claim 2. Claim 16 is similar to claim 2 and is therefore rejected under similar rationale.
Regarding claim 17, claim 17 is directed to a non-transitory computer readable medium corresponding to the method of claim 3. Claim 17 is similar to claim 3 and is therefore rejected under similar rationale.
Claims 4, 11, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Doloff (“Doloff,” US 10505925, filed Sept.6, 2017) in view of DePue et al., (“DePue,” US 11050691, filed June 12, 2019.) and Su (“Su,” US 20180262510, published Sept. 13, 2018).
Regarding claim 4, Doloff and DePue disclose the method of claim 1. Doloff and DePue do not explicitly disclose: wherein the token encoding the first permissions or the second permissions based on a resource graph, the graph comprising nodes identifying different data resources.
However, in an analogous art, Su discloses a method, comprising the step of:
wherein the token encoding the first permissions or the second permissions based on a resource graph, the graph comprising nodes identifying different data resources (Su [0059], [0066]. The access token may comprise one or more of a unique user identifier, such as user ID 506 for the user making the request, one or more unique resource identifiers corresponding to the one or more resources that the user is attempting to request, such as resource identifier 508, an authorization identifier, such as authorization ID 510, and a clearance level identifier associated with the user making the request, such as clearance level ID 513. If credentials corresponding to user identifier 606 which meet permission requirements 638 for accessing Set 616 are determined to be associated with graph data storage set type 1, a user access token, such as access token 640 may be generated by graph data storage set type 1 and/or a related caller application, and that access token 640 may be provided to Set 616 such that one or more resources in set 616 (e.g., node 618 associated with resource identifier 789) may be accessible to the user that generated permission request 604.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention was made to combine the teachings of Su with DePue and Doloff to include the step of: wherein the token encoding the first permissions or the second permissions based on a resource graph, the graph comprising nodes identifying different data resources. One would have been motivated to provider users with a means for creating an access token based on graph relationships of data sources and resource nodes. (See Su [0066].)
Regarding claim 11, claim 11 is directed to a system corresponding to the method of claim 4. Claim 11 is similar to claim 4 and is therefore rejected under similar rationale.
Regarding claim 18, claim 18 is directed to a non-transitory computer readable medium corresponding to the method of claim 4. Claim 18 is similar to claim 4 and is therefore rejected under similar rationale.
Claims 5-6, 12-13, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Doloff (“Doloff,” US 10505925, filed Sept.6, 2017) in view of DePue et al., (“DePue,” US 11050691, filed June 12, 2019.) and Slupesky et al. (“Slupesky,” US 20180330368, published Nov. 15, 2018).
Regarding claim 5, Doloff and DePue disclose the metho of claim 1. Doloff and DePue do not explicitly disclose: in response to executing the job, selectively transmitting a result of the execution of the job to a different client device or a different service based on whether the different client device or the different service is authorized to access the result, based on third permissions.
However, in an analogous art, Slupesky discloses a method, comprising the step of:
in response to executing the job, selectively transmitting a result of the execution of the job to a different client device or a different service based on whether the different client device or the different service is authorized to access the result, based on third permissions (Slupesky [0062], [0064], [0069], [0070]. If the passcode received by the resource server 10 is verified, the resource server 10 may generate and/or retrieve an access token. The resource server 10 associates the access token with the specific resource client device 12 that sent the verified passcode (e.g., by associating the access token with the unique client device identifier). The resource server 10 may associate the access token with the specific user device 14 that relayed the passcode to the specific resource client device 12 (e.g., by associating the access token with the unique user device identifier). The resource server 10 may associate the access token with the specific user 16 and/or user device 14 that is accessible at the alternate address via the alternate communication channel 24 (e.g., by associating the access token with the alternate address). In response to receiving the access token from the resource server 10, the resource client device 12 may send (at S9) a user access token (user-token) or another form of a registration/verification success message to the user device 14. The user access token may be a unique value associated with the resource client device 12 and/or the user device 14.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Slupesky, Doloff and DePue to include the step of: in response to executing the job, selectively transmitting a result of the execution of the job to a different client device or a different service based on whether the different client device or the different service is authorized to access the result, based on third permissions. One would have been motivated to provide users with a means for creating access tokens and services designated to particular sets of user devices that have participated in the authentication process. (See Slupesky [0064].)
Regarding claim 6, Doloff, DePue and Slupesky disclose the method of claim 5. Slupesky further discloses encoding, by the token, the third permissions (Slupesky [0063]. The access token may be in the form of a JSON (JavaScript Object Notation) Web Token (JVVT). Additionally or alternatively, a JVVT may incorporate the access token and other identifying information such as the unique client device identifier and/or the unique user device identifier. The access token may be associated with a validity period during which the access token may be used by the resource client device 12 to submit resource requests to the resource server 10.).
The motivation is the same as that of claim 5 above.
Regarding claim 12, claim 12 is directed to a system corresponding to the method of claim 5. Claim 12 is similar to claim 5 and is therefore rejected under similar rationale.
Regarding claim 13, claim 13 is directed to a system corresponding to the method of claim 6. Claim 13 is similar to claim 6 and is therefore rejected under similar rationale.
Regarding claim 19, claim 19 is directed to a non-transitory computer readable medium corresponding to the method of claim 5. Claim 19 is similar to claim 5 and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is directed to a non-transitory computer readable medium corresponding to the method of claim 6. Claim 20 is similar to claim 6 and is therefore rejected under similar rationale.
Claim 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Doloff (“Doloff,” US 10505925, filed Sept.6, 2017) in view of DePue et al., (“DePue,” US 11050691, filed June 12, 2019.) and Sathyadevan et al. (“Sathyadevan,” US 10055607, patenjted Aug. 21, 2018).
Regarding claim 7, Doloff and DePue disclose the method of claim 1. Doloff and DePue do not explicitly disclose: receiving a modification of the first permissions or the second permissions; and in response to receiving the modification, generating a new token, wherein the new token encodes the modified first permissions or the modified second permissions and deactivating the token.
However, in an analogous art, Sathyadevan discloses a method, comprising the step of: receiving a modification of the first permissions or the second permissions; and in response to receiving the modification, generating a new token, wherein the new token encodes the modified first permissions or the modified second permissions and deactivating the token (Sathyadevan col. 8: 40-56. In one embodiment a token is generated from an ad-hoc request for a data operation or operations that were not permitted in the original policy and for which no reusable tokens exist. Such tokens may be generated if both the service provider and tenant agree to permit the new data operation(s). In this embodiment, the token is generated, signed, and used in the same manner as pre-generated tokens. The tenant may elect for the newly generated token to become a reusable token if it is deemed that the operation(s) should become part of regular policy. In this case, the policy is modified to reflect the new data operation(s) that will be permitted regularly in the future. There may also be operations on data permitted by reusable tokens that the tenant desires to delete or eliminate from the policy. In this case, if both parties agree, tokens may be scraped eliminating certain operations from being performed on tenant data.)
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective filing date of the claimed invention to combine the teachings of Sathyadevan, Doloff and DePue to include the step of: receiving a modification of the first permissions or the second permissions; and in response to receiving the modification, generating a new token, wherein the new token encodes the modified first permissions or the modified second permissions and deactivating the token. One would have been motivated to provide users with a means for updating or remove access tokens according to changes in service permission or policy among computing devices. (See Sathyadevan col. 8: 40-56.)
Regarding claim 14, claim 14 is directed to a system corresponding to the method of claim 1. Claim 14 is similar to claim 1 and is therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. 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 http://pair-direct.uspto.gov. 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.
/EDWARD LONG/
Examiner, Art Unit 2439
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights