DETAILED ACTION
Acknowledgements
This Non-Final Office Action is in reply to Applicant’s RCE filed September 2, 2026.
Claims 1, 2, 5, 7-10, 13, 15-18 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 .
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 September 2, 2026 has been entered.
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 16, claim 17 line 17
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.
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) in view of Marimuthu (US 20150381826 A1) in view of Scheffler.
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}
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 the 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 and that the current digital proximity distance between the digital entity and […], enabling access to the 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 and […], 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 the predefined threshold range; {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 and that the current digital proximity distance between the digital entity and […], 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.
dynamically modifying the predefined threshold range associated with the first token parameter such that the service token is individually enabled or disabled based at least in part upon the dynamically modified predefined threshold range; {[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 [modifying] access token [service token].”}
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;
a service provider agreement indicates a predefined bandwidth associated with a service provider;
{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.
Devopedia in view of Yu does not teach, however Marimuthu teaches:
dividing the predefined bandwidth into a plurality of bandwidth slices, each bandwidth slice of the plurality of bandwidth slices comprising a portion of the predefined bandwidth;
the allocated bandwidth slice being one bandwidth slice of the plurality of bandwidth slices {[0062] “splits the remaining data of the total user budgeted amount”}
recording, in a connectivity ledger, bandwidth allocation information associated with the digital entity, the bandwidth allocation information comprising at least a user device identifier, a service provider identifier, and a session time associated with the allocated bandwidth slice, the allocated bandwidth slice enabling the digital entity to maintain operations in the VR-enhanced environment by providing the digital entity with access to network resources of the service provider while the digital entity interacts with the one or more virtual objects in the VR-enhanced environment; {[0011] “the data plan defines the total amount of bandwidth available to a subscribed user of a service provider network”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the authorization-token-using cloud storage system of Devopedia in view of Yu to incorporate Marimuthu’s division of data allowance into separately allocated portions for respective users/services because assigning and enforcing individual portions would permit multiple authorized users to share the available allowance while preventing one user’s consumption from depleting the portions allocated to others, thereby increasing the usability of the allotted data.
Devopedia in view of Yu in view of Marimuthu does not teach, however Scheffler teaches the following bolded language:
configuring the digital entity to interact with one or more virtual objects in the VR-enhanced environment; {Page 7 “form a virtual actor that can communicate with its surroundings”}
storing, in a second token parameter of the service token, proximity information indicating a permitted digital proximity distance between the digital entity and another 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 other digital entity being associated with the allocated bandwidth slice; {Abstract “Resource access may not only depend on prior authorization, but also on context of usage such as distance or position in the scene graph hierarchy. In virtual worlds that allow user-created content, participants must be able to define and exchange access rights to control the usage of their creations.”; Page 5 “In virtual environments, as in real life, access to an object may not only depend on prior authorization, but also on a number of other conditions. […] By communicating capabilities along different channels, different conditions can be checked before granting access. […] Capabilities exchanged by collision can only be used by those actors that are within each other’s proximity.”}
monitoring […] the current digital proximity distance between the digital entity and the other digital entity, associated with the digital entity in the VR-enhanced environment; {Page 2 “The spatial model of interaction uses the properties of space and distance as the basis for mediating interaction [3]. Each virtual object is enclosed by a bounding volume called aura. Only objects whose auras collide are able to interact. Objects can adjust the amount of awareness information they offer and receive dependent on distance.”}
determining whether a current digital proximity distance between the digital entity and the other digital entity is within the permitted digital proximity distance; {Abstract “Resource access may not only depend on prior authorization, but also on context of usage such as distance or position in the scene graph hierarchy. In virtual worlds that allow user-created content, participants must be able to define and exchange access rights to control the usage of their creations.”}
determining whether the current digital proximity distance between the digital entity and the other digital entity is outside the permitted digital proximity distance; and {Abstract “Resource access may not only depend on prior authorization, but also on context of usage such as distance or position in the scene graph hierarchy. In virtual worlds that allow user-created content, participants must be able to define and exchange access rights to control the usage of their creations.”}
in response to determining that […] the other digital entity is within the permitted digital proximity distance, enabling access to the allocated bandwidth slice associated with the service provider via the service token; {Page 6 “Access rights are granted dependent on conditions of distance”}
in response to determining that […] the current digital proximity distance between the digital entity and the other digital entity is outside the permitted digital proximity distance, disabling the access {Page 6 “Access rights are granted dependent on conditions of distance”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use the authorization token of Devopedia in view of Yu in view of Marimuthu in Scheffler’s virtual environment where access is determined in part based on distances in the virtual environment because Devopedia is completely agnostic with respect to what type of service it can be used for, and Scheffler teaches a service that requires a form of authentication for access control. It is further noted that Devopedia explicitly teaches an access token being used for multiple services (Page 2 “We certainly don't want clients to authenticate with each service. Authentication is done by a specific service or server. Once authenticated successfully, the client should be able to access any of the services without further 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 the 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 the digital proximity distance between a reference point associated with the other digital entity 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 third 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 third 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.
monitoring a value of a third 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 third 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 in view of Marimuthu in view of Scheffler as applied to claims 2, 10, 18 above, and further in view of Martin (US 20230328311 A1).
Regarding claims 11, 3, 19
Devopedia in view of Yu in view of Marimuthu in view of Scheffler 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 in view of Yu in view of Marimuthu in view of Scheffler 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 in view of Yu in view of Marimuthu, however Scheffler teaches:
The method of claim 10, further comprising:
[…] the digital proximity distance between the reference point and the digital entity in the VR-enhanced environment […]
[…] for the digital entity in the VR-enhanced environment […]
[…] digital proximity distance […]
{Page 1 “access can be made dependent on spatial properties such as distance”; Page 6 “Access rights are granted dependent on conditions of distance”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use the authorization token of Devopedia in view of Yu in view of Marimuthu in Scheffler’s virtual environment where access is determined in part based on distances in the virtual environment for the same reasons as given above with respect to claim 9.
Devopedia in view of Yu in view of Marimuthu in view of Scheffler does not teach, however Martin teaches the following bolded language:
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 digital proximity distance, wherein:
the second token parameter comprises the 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 digital proximity distance].”}
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 where the access token contains “claims” (containing restrictions on token validity). Scheffler further teaches the restriction being based on the proximity distance of objects in a virtual environment. Martin is merely relied upon to illustrate the functionality of updating the restrictions. 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/Yu/Marimuthu/Scheffler/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 in view of Marimuthu in view of Scheffler as applied to claims 1, 9 above, and further in view of Lightwidget.com.
Regarding claims 14, 6
Devopedia in view of Yu in view of Marimuthu in view of Scheffler 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 in view of Yu in view of Marimuthu in view of Scheffler 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
Contrary to Applicant’s remarks, 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
The proposed Devopedia-Yu combination is improper
Applicant argues that the rejection’s statement that Devopedia is service agnostic and Yu requires authentication does not provide sufficient reason to combine the references. Applicant further argues that Devopedia concerns JWT-based API authorization whereas Yu concerns authorization and capacity management for cloud storage. Applicant states that describing both as involving authentication improperly dismisses their technical differences.
However, the rejection does not allege any similarity between the references. Devopedia teaches a general purpose authentication process which Devopedia teaches is used to control access to “services,” such as APIs. Yu teaches a cloud storage service which requires authentication to access. The authentication method of Devopedia provides advantages such as statelessness and the ability to authenticate only once for multiple services and a person of ordinary skill in the art would have been motivated to use the authentication method of Devopedia for the cloud storage service of Yu in order to realize those advantages.
Applicant further argues the proposed combination would change the principle of operation of Devopedia because Devopedia uses JWT tokens and Yu does not. However, nothing in the proposed combination suggests changing the authentication process of Devopedia. The proposed combination merely uses the authentication process of Devopedia for users to authenticate themselves to use the cloud storage service of Yu. Neither the JWT authentication of Devopedia nor the cloud storage system of Yu is proposed to be changed, but rather they are used together and both function the same in the proposed combination as they do separately.
Yu teaches away from the proposed combination
Applicant argues Yu teaches away from the JWT authentication process of Devopedia because Yu teaches using a hardware-based authentication method for use with the cloud storage service. Applicant states that Yu specifically teaches that software-based authorization is inadequate. However, Yu is actually acknowledging that such authorization can be used with its cloud storage service (see page 2 “in the related art generally adopts the system
authorization mode of soft authentication (license) to realize authentication and authorization control”), but then points out some advantages of a hardware-based authorization.
Not only does this not constitute teaching away, but Devopedia also teaches advantages to using its authorization method, such as statelessness and the ability to authenticate once for multiple services. Yu does not suggest that there is anything about its cloud storage service specifically, as opposed to any other service, that would cause it to prefer a particular authentication method.
The proposed Devopedia-Yu combination does not disclose, teach, or suggest each and every element of amended Claim 1
Applicant has added several new limitations to the independent claims and argues they are not taught by Devopedia in view of Yu. In response, the rejection has been updated to incorporate references Marimuthu and Scheffler. Marimuthu teaches the concept of subdividing a data limit into a plurality of slices. Scheffler teaches the concept of configuring a digital entity to interact with objects in a virtual environment and to monitor/determine its distance from other entities and control access based on this distance. The independent claims are therefore deemed obvious over Devopedia in view of Yu in view of Marimuthu in view of Scheffler.
Conclusion
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