DETAILED ACTION
Acknowledgements
This Final Office Action is in reply to Applicant’s response filed January 7, 2026.
Claims 1-20 are currently amended.
Claims 1-20 are currently pending.
Claims 1-20 have been examined.
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 Objections
Claims 1, 9, 17 are objected to because of the following informalities:
“service access provider information” should be “service provider access information”, claim 1 line 5, claim 9 line 12, claim 17 line 13
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 2, 7-10, 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Devopedia in view of Yu (English translation of CN 106303593 B).
Regarding claims 9, 1, 17
Devopedia teaches:
A method, comprising: {Figure 5}
PNG
media_image1.png
376
692
media_image1.png
Greyscale
transmitting a validation profile to a registry, wherein: {Fig. 5 step 1}
Username/password reads on validation profile.
the validation profile indicates a plurality of credentials associated with accessing a virtual reality (VR)-enhanced environment;
The username/password reads on plurality of credentials. Devopedia does not teach a VR-enhanced environment. However, this is merely an intended use and is not given patentable weight. The credentials being associated with a VR-enhanced environment does not affect the steps of transmitting or confirming the credentials.
at the registry, each credential of the plurality of credentials is confirmed as belonging to a digital entity in the VR-enhanced environment; and {Fig. 5 step 2}
the digital entity is configured to interact with one or more virtual objects in the VR-enhanced environment;
The configuration of the digital entity is not given patentable weight because it is not a step and does not affect the steps of transmitting or confirming the credentials.
generating a service token indicating service provider access information for the digital entity in the VR-enhanced environment, wherein: {Fig. 5 step 3, page 2 “An authenticated client is issued a JWT [service token].”; page 3 “The payload of a JWT has a set of claims. A claim is a name-value pair. It states a fact about the token and its subject such as username or email address.”}
the service [provider access] information indicates instructions to access one or more services from a service provider; {page 2 “Once authenticated successfully, the client should be able to access any of the services without further authentication.”}
The service provider access information is not given patentable weight because it is non-functional descriptive material because it is data which serves no functional purpose in the claim. The claimed instructions are not used in the claimed method and serve only to convey a meaning to a person.
the service token comprises a plurality of token parameters indicating characteristics of the digital entity in the VR-enhanced environment; and {Fig. 5 step 3, page 2 “An authenticated client is issued a JWT.”; page 3 “The payload of a JWT has a set of claims [parameters]. A claim is a name-value pair. It states a fact about the token and its subject such as username or email address.”}
a first token parameter of the plurality of token parameters references access to […] the service provider; { page 2 “Once authenticated successfully, the client should be able to access any of the services without further authentication.”}
determining whether a value of the first token parameter is inside a predefined threshold range; {page 7 “For example, verify that token has not expired [inside a predefined threshold range].”}
in response to determining that the value of the first token parameter is inside the predefined threshold range, enabling access to allocated bandwidth slice associated with the service provider via the service token; {Fig. 5 step 3; page 2 “An authenticated client is issued a JWT [service token].”; page 2 “The common use case of JWTs is authorization. For example, APIs often require an access token and this could be a JWT. Systems implementing Single Sign-On (SSO) can issue JWTs to allow the user to access various services.”}
Devopedia teaches the JWT allows the user to access various services. Therefore, providing the JWT to the user/client reads on enabling access.
transmitting the service token to the digital entity in the VR-enhanced environment, the digital entity accessing the at least one service from the service provider via the service token; {Fig. 5 step 3; page 2 “An authenticated client is issued [transmitting] a JWT [service token].”; page 2 “The common use case of JWTs is authorization. For example, APIs often require an access token and this could be a JWT. Systems implementing Single Sign-On (SSO) can issue JWTs to allow the user to access various services.”}
sharing the access […] with the digital entity; {page 2 “Whenever the client makes an API request, it presents this token. The API gateway validates the token before allowing [sharing the access] the client [digital entity] to access the requested service.”}
monitoring the value of the first token parameter associated with the digital entity in the VR-enhanced environment; {Fig. 5 step 5; page 3 “The payload of a JWT has a set of claims. A claim [parameter] is a name-value pair. It states a fact about the token and its subject such as username or email address.”; page 4 “Some registered claim names are of datetime type: "exp" (token expires at this time), "nbf" (token can't be used before this time), and "iat" (time when token was issued). For example, "exp":1300819380 says that the token expires at the specified timestamp.”; page 7 “It's a good practice to verify applicable claims. For example, verify that token has not expired.”}
Validating the token at step 5 and verifying whether it is expired reads on monitoring a value.
determining whether the value of the first token parameter is outside a predefined threshold range; and {page 7 “For example, verify that token has not expired [outside a predefined threshold range].”}
in response to determining that the value of the first token parameter is outside the predefined threshold range, disabling the access to […] the service provider via the service token. {Fig. 5 step 5; page 3 “The payload of a JWT has a set of claims. A claim [parameter] is a name-value pair. It states a fact about the token and its subject such as username or email address.”; page 4 “Some registered claim names are of datetime type: "exp" (token expires at this time), "nbf" (token can't be used before this time), and "iat" (time when token was issued). For example, "exp":1300819380 says that the token expires at the specified timestamp.”; page 7 “It's a good practice to verify applicable claims. For example, verify that token has not expired.”}
Devopedia does not explicitly teach disabling access if the token is expired. However, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention that disabling the access is implied because Devopedia teaches, by way of example, verifying that the token has not expired.
Devopedia does not teach, however Yu teaches:
an allocated bandwidth slice associated with the service provider
the allocated bandwidth slice
restricting bandwidth usage of the digital entity in accordance with a threshold of the allocated bandwidth slice;
{Abstract “The invention claims a security authentication method and system for cloud storage service ”; page 3 “According to another aspect of the present invention, there is provided a security authentication system of cloud storage service.”; page 3 “Preferably, the server further comprises: a second sending module, used for sending instruction to the one or more key device, capacity grant information, wherein instruction for obtaining each key device to the one or more key device are stored, a receiving module for receiving capacity grant information one or more returned by the key device, a first calculating module, used for calculating the authorized capacity limit according to the capacity grant information.”}
Devopedia teaches an authorization process to access services, but does not teach the service being a “bandwidth slice”. It is noted that this application uses the term “bandwidth” in a nonstandard way. See specification Background section, “second predefined bandwidth of 1 GB”. The term bandwidth thus refers to an amount of data, rather than a data rate. Yu teaches a cloud storage service, where the user is authenticated to use the service and authorized a certain “capacity limit”. This is a service where access to the service constitutes access to an amount of data (a bandwidth slice). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to apply the authentication method of Devopedia to the service of Yu because Devopedia is completely agnostic with respect to what type of service it can be used for, and Yu teaches a service that requires a form of authentication. Claims 1 and 17 are similar in scope to claim 9 and are treated the same with respect to prior art rejections.
Regarding claims 10, 2, 18
The method of claim 9, wherein:
the plurality of token parameters comprises service provider information, access information, time information, area information, and proximity information;
the service provider information comprises instructions to establish a communication link between the digital entity and the service provider;
the access information comprises instructions for the digital entity to access the allocated bandwidth slice via the communication link;
the time information comprises a time period in which the digital entity is permitted to access the allocated bandwidth slice associated with the service provider via the service token;
the area information comprises a virtual area in a virtual sub-environment of the VR-enhanced environment in which the digital entity is permitted to access the allocated bandwidth slice via the service token; and
the proximity information comprises a digital proximity distance between a reference point and the digital entity in the VR-enhanced environment in which the digital entity is permitted to access the allocated bandwidth slice via the service token.
The above limitations all claim the content of data which has no functional relationship to the claimed method and therefore is considered non-functional descriptive material / printed matter not given patentable weight.
Claims 2 and 18 are similar in scope to claim 10 and are treated the same with respect to prior art rejections.
Regarding claims 15, 7
Devopedia teaches:
The method of claim 9, further comprising:
in conjunction with monitoring the value of the first token parameter, monitoring a value of a second token parameter associated with the digital entity in the VR-enhanced environment; and {Fig. 5 step 5; page 3 “The payload of a JWT has a set of claims. A claim [parameter] is a name-value pair. It states a fact about the token and its subject such as username or email address.”; page 4 “Some registered claim names are of datetime type: "exp" (token expires at this time), "nbf" (token can't be used before this time), and "iat" (time when token was issued). For example, "exp":1300819380 says that the token expires at the specified timestamp.”; page 7 “It's a good practice to verify applicable claims. For example, verify that token has not expired.”}
Devopedia teaches monitoring the values of multiple parameters (i.e. “exp”, “nbf”) and therefore reads on monitoring an additional token parameter.
in response to determining that the value of the first token parameter is outside the predefined threshold range and that the value of the second token parameter is outside an additional predefined threshold range, disabling the access to the allocated bandwidth slice in the service provider via the service token. {Fig. 5 step 5; page 3 “The payload of a JWT has a set of claims. A claim [parameter] is a name-value pair. It states a fact about the token and its subject such as username or email address.”; page 4 “Some registered claim names are of datetime type: "exp" (token expires at this time), "nbf" (token can't be used before this time), and "iat" (time when token was issued). For example, "exp":1300819380 says that the token expires at the specified timestamp.”
page 7 “It's a good practice to verify applicable claims. For example, verify that token has not expired.”}
Devopedia teaches verifying the values of multiple claims (i.e. “exp”, “nbf”) and therefore implies disabling the access in response to multiple claims (parameters) being outside a threshold range.
Claim 7 is similar in scope to claim 15 and is treated the same with respect to prior art rejections.
Regarding claims 16, 8
Devopedia teaches:
The method of claim 9, further comprising:
transmitting an additional validation profile to the registry in which each credential of an additional plurality of credentials is confirmed as belonging to an additional digital entity in the VR-enhanced environment, the additional digital entity being configured to interact with the one or more virtual objects in the VR-enhanced environment;
This step is merely repeating the claim 9 step of transmitting a validation profile. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to repeat the authentication method of Devopedia to login an additional account.
generating an additional service token indicating additional service provider access information for the additional digital entity in the VR-enhanced environment, the additional service token comprising an additional plurality of token parameters indicating characteristics of the additional digital entity in the VR-enhanced environment;
This step is merely repeating the claim 9 step of generating a service token. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to repeat the authentication method of Devopedia to login an additional account.
enabling access to at least one additional service in the service provider via the additional service token;
This step is merely repeating the step of enabling access of claim 9. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to repeat the authentication method of Devopedia to login an additional account.
transmitting the additional service token to the additional digital entity in the VR-enhanced environment, the additional digital entity accessing the at least one additional service from the service provider via the additional service token;
This step is merely repeating the claim 9 step of transmitting the service token. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to repeat the authentication method of Devopedia to login an additional account.
sharing the access to the at least one additional service with the digital entity;
This step is merely repeating the claim 9 step of sharing the access. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to repeat the authentication method of Devopedia to login an additional account.
monitor a value of a second token parameter associated with the additional digital entity in the VR-enhanced environment; and
This step is merely repeating the claim 9 step of monitoring a value. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to repeat the authentication method of Devopedia to login an additional account.
in response to determining that the value of the second token parameter is outside an additional predefined threshold range, disabling the access to the at least one additional service in the service provider via the additional service token.
This step is merely repeating the claim 9 step of disabling the access. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to repeat the authentication method of Devopedia to login an additional account.
Claims 3-5, 11-13, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Devopedia in view of Yu as applied to claims 2, 10, 18 above, and further in view of Martin (US 20230328311 A1).
Regarding claims 11, 3, 19
Devopedia does not teach, however Martin teaches:
The method of claim 10, further comprising:
in conjunction with monitoring the value of the first token parameter, receiving a request from the digital entity in the VR-enhanced environment to increase the predefined threshold range, the first token parameter being the time information; and {[0024] “the non-location aware device 125 may be configured to monitor a TTL [time to live] [parameter] of access tokens previously received and stored in a memory of the non-location aware device 125 and upon expiration (or near expiration) of a TTL of a stored access token, the non-location aware device [digital entity] 125 may send out a request for another access token [to increase the predefined threshold range].”}
Martin does not explicitly teach receiving a request. However, Martin teaches sending a request. Since sending and receiving are reciprocal actions, Martin implies receiving. “To increase the predefined threshold range…” is not given patentable weight because it merely describes an intention about how the request is interpreted and does not affect the step of receiving.
updating the service token to indicate an update to the service provider access information for the digital entity in the VR-enhanced environment, the update referencing an increase in the time period in which the digital entity accesses the at least one service from the service provider via the service token. {[0024] “the non-location aware device 125 may be configured to monitor a TTL of access tokens previously received and stored in a memory of the non-location aware device 125 and upon expiration (or near expiration) of a TTL of a stored access token, the non-location aware device 125 may send out a request for another [updating] access token [service token].”}
Martin teaches requesting another token, not updating the token. However, the prior alternatively uses the terms “update”, “renew”, and “refresh” to refer to the process of obtaining a new access token with a new expiration, and therefore these terms are all considered to read on updating. See Fryer (US 20220217124 A1) [0035] “the encrypted access token may be refreshed periodically by automatically obtaining a new encrypted access token prior to expiration of the previous encrypted access token.”; Dohmae (US 20220357905 A1) [0164] “‘Please update’ indicates that the access token has expired and the access token is to be renewed.”; Giegerich (US 20230036721 A1) [0005] “the access token expires after a first predetermined period. The access token is to be refreshed after expiration. The refreshed token expires after a second predetermined period.”
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Devopedia to include the token renewing of Martin. One would have been motivated to do so, in order to replace an expired token. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Devopedia evidently discloses an access token authentication method. Martin is merely relied upon to illustrate the functionality of updating the TTL when the token expires in the same or similar context. As best understood by Examiner, since both Devopedia, as well as Martin are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Devopedia, as well as Martin would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Devopedia/Martin.
Claims 3 and 19 are similar in scope to claim 11 and are treated the same with respect to prior art rejections.
Regarding claims 12, 4, 20
Devopedia does not teach, however Martin teaches:
The method of claim 10, further comprising:
in conjunction with monitoring the value of the first token parameter, receiving a request from the digital entity in the VR-enhanced environment to increase the predefined threshold range, wherein:
the first token parameter is the area information; and {[0024] “the non-location aware device 125 may be configured to monitor a TTL [time to live] [parameter] of access tokens previously received and stored in a memory of the non-location aware device 125 and upon expiration (or near expiration) of a TTL of a stored access token, the non-location aware device [digital entity] 125 may send out a request for another access token [to increase the predefined threshold range].”}
Martin does not explicitly teach receiving a request. However, Martin teaches sending a request. Since sending and receiving are reciprocal actions, Martin implies receiving. “To increase the predefined threshold range…” is not given patentable weight because it merely describes an intention about how the request is interpreted and does not affect the step of receiving.
the request increases the virtual space in the virtual sub-environment of the VR-enhanced environment in which the digital entity is permitted to access the allocated bandwidth slice via the service token; and {[0063] “a non-location aware device may collect access tokens from different location aware devices… the content delivery service may consider each of the received access tokens in determining the approximate location of the non-location aware device” [0072] “If it is determined that the content is location restricted, a determination is made as to whether a valid access token is stored in the memory of the non-location aware device” [0029] “As discussed, location restricted content may be restricted such that the content delivery service 121 is only authorized to provide the content for presentation in defined areas (e.g., geographic areas, defined zip codes, postal codes, etc.). For example, location restricted content may be allowed for delivery and presentation into a first defined area but not allowed for delivery and presentation into a second defined area that is different than the first defined area.”}
This limitation is not given patentable weight. It is explicitly written as an intended result because it describes what the request accomplishes, rather than the actions that are performed as part of the method (of claim 13) or by the apparatus (of claim 5).
updating the service token to indicate an update to the service provider access information for the digital entity in the VR-enhanced environment, the update referencing an increase in the virtual area in the virtual sub-environment of the VR-enhanced environment in which the digital entity is permitted to access the allocated bandwidth slice via the service token. {[0024] “the non-location aware device 125 may be configured to monitor a TTL of access tokens previously received and stored in a memory of the non-location aware device 125 and upon expiration (or near expiration) of a TTL of a stored access token, the non-location aware device 125 may send out a request for another [updating] access token [service token].”}
Martin teaches requesting another token, not updating the token. However, the prior uses the terms “update”, “renew”, and “refresh” interchangeably to refer to the process of obtaining a new access token with a new expiration, and therefore these terms are all considered to read on updating. See Fryer (US 20220217124 A1) [0035] “the encrypted access token may be refreshed periodically by automatically obtaining a new encrypted access token prior to expiration of the previous encrypted access token.”; Dohmae (US 20220357905 A1) [0164] “‘Please update’ indicates that the access token has expired and the access token is to be renewed.”; Giegerich (US 20230036721 A1) [0005] “the access token expires after a first predetermined period. The access token is to be refreshed after expiration. The refreshed token expires after a second predetermined period.”
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Devopedia to include the token renewing of Martin. One would have been motivated to do so, in order to replace an expired token. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Devopedia evidently discloses an access token authentication method. Martin is merely relied upon to illustrate the functionality of updating the TTL when the token expires in the same or similar context. As best understood by Examiner, since both Devopedia, as well as Martin are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Devopedia, as well as Martin would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Devopedia/Martin.
Claims 4 and 20 are similar in scope to claim 12 and are treated the same with respect to prior art rejections.
Regarding claims 13, 5
Devopedia does not teach, however Martin teaches:
The method of claim 10, further comprising:
in conjunction with monitoring the value of the first token parameter, receiving a request from the digital entity in the VR-enhanced environment to increase the predefined threshold range, wherein:
the first token parameter is the digital proximity information; and {[0024] “the non-location aware device 125 may be configured to monitor a TTL [time to live] [parameter] of access tokens previously received and stored in a memory of the non-location aware device 125 and upon expiration (or near expiration) of a TTL of a stored access token, the non-location aware device [digital entity] 125 may send out a request for another access token [to increase the predefined threshold range].”}
Martin does not explicitly teach receiving a request. However, Martin teaches sending a request. Since sending and receiving are reciprocal actions, Martin implies receiving. “To increase the predefined threshold range…” is not given patentable weight because it merely describes an intention about how the request is interpreted and does not affect the step of receiving.
the request increases the digital proximity distance between the reference point and the digital entity in the VR-enhanced environment in which the digital entity is permitted to access the allocated bandwidth slice via the service token; and {[0063] “a non-location aware device may collect access tokens from different location aware devices… the content delivery service may consider each of the received access tokens in determining the approximate location of the non-location aware device” [0072] “If it is determined that the content is location restricted, a determination is made as to whether a valid access token is stored in the memory of the non-location aware device” [0029] “As discussed, location restricted content may be restricted such that the content delivery service 121 is only authorized to provide the content for presentation in defined areas (e.g., geographic areas, defined zip codes, postal codes, etc.). For example, location restricted content may be allowed for delivery and presentation into a first defined area but not allowed for delivery and presentation into a second defined area that is different than the first defined area.”}
This limitation is not given patentable weight. It is explicitly written as an intended result because it describes what the request accomplishes, rather than the actions that are performed as part of the method (of claim 13) or by the apparatus (of claim 5).
updating the service token to indicate an update to the service provider access information for the digital entity in the VR-enhanced environment, the update referencing an increase in the digital proximity distance between the reference point and the digital entity in the VR-enhanced environment in which the digital entity is permitted to access the allocated bandwidth slice via the service token. {[0024] “the non-location aware device 125 may be configured to monitor a TTL of access tokens previously received and stored in a memory of the non-location aware device 125 and upon expiration (or near expiration) of a TTL of a stored access token, the non-location aware device 125 may send out a request for another [updating] access token [service token].”}
Martin teaches requesting another token, not updating the token. However, the prior alternatively uses the terms “update”, “renew”, and “refresh” to refer to the process of obtaining a new access token with a new expiration, and therefore these terms are all considered to read on updating. See Fryer (US 20220217124 A1) [0035] “the encrypted access token may be refreshed periodically by automatically obtaining a new encrypted access token prior to expiration of the previous encrypted access token.”; Dohmae (US 20220357905 A1) [0164] “‘Please update’ indicates that the access token has expired and the access token is to be renewed.”; Giegerich (US 20230036721 A1) [0005] “the access token expires after a first predetermined period. The access token is to be refreshed after expiration. The refreshed token expires after a second predetermined period.”
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Devopedia to include the token renewing of Martin. One would have been motivated to do so, in order to replace an expired token. Furthermore, the Supreme Court has supported that combining well known prior art elements, in a well-known manner, to obtain predictable results is sufficient to determine an invention obvious over such combination (see KSR International Co. v. Teleflex Inc. (KSR), 550 U.S.,82 USPQ2d 1385 (2007) & MPEP 2143). In the instant case, Devopedia evidently discloses an access token authentication method. Martin is merely relied upon to illustrate the functionality of updating the TTL when the token expires in the same or similar context. As best understood by Examiner, since both Devopedia, as well as Martin are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Devopedia, as well as Martin would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Devopedia/Martin.
Claim 13 is similar in scope to claim 5 and is treated the same with respect to prior art rejections.
Claims 6, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Devopedia in view of Yu as applied to claims 1, 9 above, and further in view of Lightwidget.com.
Regarding claims 14, 6
Devopedia does not teach, however LightWidget teaches:
The method of claim 9, further comprising:
presenting at least a portion of the VR-enhanced environment via a display; and {page 1 “The access token is a string of characters generated by Instagram API when you connect your Instagram account to LightWidget. It authorizes our app to access the data about your posts and convert them into widgets.”}
LightWidget teaches a specific service (Instagram) which uses an access token. Since Devopedia teaches a specific access token protocol, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to apply the protocol of Devopedia to the Instagram service of LightWidget because it is applying a known technique (an access token) to a known service (LightWidget) where the art teaches such technique is applicable.
in response to the processor determining that the value of the first token parameter is outside the predefined threshold range, presenting an alert to the user in the VR-enhanced environment. {Figure on page 4 shown below; page 1 “Don't let expired access tokens break your Instagram widget. Our new feature allows you to receive email notifications when the connection between LightWidget and your Instagram account expires. Learn more about this essential feature today.”; page 2 “Suppose the access token (the connection) breaks. In that case, we can no longer get the information from the official Instagram API and update the content of your widgets. It often results in the not loading images in our Instagram plugin after a while.”}
PNG
media_image2.png
408
598
media_image2.png
Greyscale
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to add the alert of LightWidget to the access token method of Devopedia to avoid losing access.
Claim 14 is similar in scope to claim 6 and is treated the same with respect to prior art rejections.
Response to Arguments
Claim Objections
Applicant has not addressed the claim objections. The independent claims still contain the phrase “service access provider information” which appears to be an unintentional transposition of “service provider access information”.
35 USC § 103
Applicant argues Devopedia fails to teach “generating a service token indicating service provider access information… wherein: the service token comprises a plurality of token parameters indicating characteristics of the digital entity in the VR-enhanced environment; and a first token parameter… references access to an allocated bandwidth slice”, “determining whether a value of the first token parameter is inside a predefined threshold range” and “in response… enabling access to allocated bandwidth slice.” Specifically, Applicant argues Devopedia does not teach a virtual reality environment and is silent regarding using JWTs to provide communication and/or bandwidth control.
However, there is no patentable weight given to the virtual reality environment aspect of the claims. The claims merely state that the credentials are associated with accessing a virtual reality environment and the service token indicates instructions for accessing a virtual reality environment. The claims are directed towards a method/system for creating a token which provides access and the virtual reality environment serves only as a field of use designation.
Regarding the claimed “bandwidth slice”, it is first noted that the term “bandwidth” in this application is given a non-standard meaning. See specification Background section, “second predefined bandwidth of 1 GB”. The term bandwidth refers to an amount of data, rather than a data rate. Therefore, “enabling access to allocated bandwidth slice” is also a field of use designation, merely requiring that the claimed token be used for accessing a service with a data limit. This is not taught by Devopedia. However, such services are well-known in the art and the rejection has been updated to address this.
Applicant further argues Devopedia fails to teach “share [access] to [an] allocated bandwidth slice [referenced in a first token parameter and associated with the service provider] with [a] digital entity,” “monitor [a] value of [a] first token parameter associated with [a] digital entity in [a] VR-enhanced environment,” “restrict bandwidth usage of the digital entity in accordance with a threshold of the allocated bandwidth slice,” “determine whether the value of the first token parameter is outside a predefined threshold range,” and “in response to determining that the value of the first token parameter is outside the predefined threshold range, disable the access to the allocated bandwidth slice in the service provider via the service token.” Applicant states Devopedia is only concerned with using JWTs to share username and e-mail information, and that Devopedia is silent regarding involvement of JWTs in control operations in the manner recited above.
However, Devopedia is not as narrow as stated by Applicant. See page 3 “The payload of a JWT has a set of claims. A claim is a name-value pair. It states a fact about the token and its
subject such as username or email address. Claims are not mandatory since It's up to applications to include claims that matter.” Username and email are merely given as examples, and Devopedia explicitly states they can include other information, and further gives an expiration as an example, and explicitly teaches “It's a good practice to verify applicable claims” i.e. determining whether the value is within a threshold range.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is listed in the enclosed PTO-892.
SvenWal teaches incorporating a custom claim into a JWT token which comprises a request rate limit. This is considered relevant to the claim 1 limitation regarding the token parameter referencing access to an allocated bandwidth slice. See page 1 “JWT claims and rate limiting with Kong Enterprise” and page 2 “our goal is to have a rate-limiting counter on a per user base”.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT MICHAEL DIROMA whose telephone number is (571)272-6430. The examiner can normally be reached Monday - Friday 12:30 pm - 8:30 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, Patrick McAtee can be reached on (571) 272-7575. 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.
/S.M.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights